"100% of our production system is now running Go"(groups.google.com)
groups.google.com
"100% of our production system is now running Go"
https://groups.google.com/d/topic/golang-nuts/hC0aJ8IASi4/discussion
14 comments
I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement.
And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started to see some of its warts. The transition from version 2 -> 3 wasn't exactly a smooth one, either. Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in.
In my case, although I have recently moved from Perl to Racket for larger and/or more complex work, I still use Perl a lot for small, simple scripts (which constitute most of my programming). A couple of the Java guys I know switched from Python to Clojure for scripting tasks (I could never convince them to like Perl..), and have started to take an interest in languages like Scala and now Go for more substantial projects.
For many years now, Python has been the fresh, fun challenger going up against older (and perhaps clunkier) languages, whereas now things seem to be shifting and Python may soon find its role has reversed and it has become the old, crufty language.
And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started to see some of its warts. The transition from version 2 -> 3 wasn't exactly a smooth one, either. Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in.
In my case, although I have recently moved from Perl to Racket for larger and/or more complex work, I still use Perl a lot for small, simple scripts (which constitute most of my programming). A couple of the Java guys I know switched from Python to Clojure for scripting tasks (I could never convince them to like Perl..), and have started to take an interest in languages like Scala and now Go for more substantial projects.
For many years now, Python has been the fresh, fun challenger going up against older (and perhaps clunkier) languages, whereas now things seem to be shifting and Python may soon find its role has reversed and it has become the old, crufty language.
"I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement."
I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally, I'm completely fine with that; different language designs are appropriate for different roles. The huge amount of work that we've done to make non-allocating and manually-memory-managed code easy, predictable, and type-safe is totally overkill for Go's niche, for example, while for games and web browsers this sort of thing is essential.
I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally, I'm completely fine with that; different language designs are appropriate for different roles. The huge amount of work that we've done to make non-allocating and manually-memory-managed code easy, predictable, and type-safe is totally overkill for Go's niche, for example, while for games and web browsers this sort of thing is essential.
The funny thing is Go and Rust compete with C++, but in different niches. C++ manages to cover a lot of ground from high-level to low-level programming.
With C++11 it now has a foot in the concurrency niche. The question is, whether C++ can keep its niches or if lots of different languages will chew away its market share on various levels.
With C++11 it now has a foot in the concurrency niche. The question is, whether C++ can keep its niches or if lots of different languages will chew away its market share on various levels.
As someone who's tried (and failed) to learn Rust in the past:
I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis.
For the love of god make Rust more accessible. I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the frickin' documentation. Digging through the core libs to figure out how to dp fairly common case stuff is obscene.
Part of the reason I like to tinker with Go in my spare time is that it's extremely hygienic, clean, cheap, and cheerful.
Look at the way the "go" binary works, it does everything. It does builds, automatic formatting of code, the works. And it just "works".
On top of that, I'd consider getting somebody more knowledgeable about Rust and get them to team up / pair-document with somebody who is a goddamn dumbass like me and start building tutorials/documentation together.
I can't imagine the language's syntax and features are so nascent that tutorials and docs for core functionality/libs would be out of the question, you're already prototyping that web browser engine.
Documentation is a UX problem, like syntax. Syntax alone crippled Erlang, please don't let obscurity harm a language I am very excited about.
If there's any way I can help (maybe a trail of bread crumbs/notes from me as I try to learn it?), let me know in this thread or via email.
I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis.
For the love of god make Rust more accessible. I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the frickin' documentation. Digging through the core libs to figure out how to dp fairly common case stuff is obscene.
Part of the reason I like to tinker with Go in my spare time is that it's extremely hygienic, clean, cheap, and cheerful.
Look at the way the "go" binary works, it does everything. It does builds, automatic formatting of code, the works. And it just "works".
On top of that, I'd consider getting somebody more knowledgeable about Rust and get them to team up / pair-document with somebody who is a goddamn dumbass like me and start building tutorials/documentation together.
I can't imagine the language's syntax and features are so nascent that tutorials and docs for core functionality/libs would be out of the question, you're already prototyping that web browser engine.
Documentation is a UX problem, like syntax. Syntax alone crippled Erlang, please don't let obscurity harm a language I am very excited about.
If there's any way I can help (maybe a trail of bread crumbs/notes from me as I try to learn it?), let me know in this thread or via email.
Yes, the docs are awful at the moment. It's mostly a question of making sure things are stable before we commit to writing a lot of docs; we absolutely need better ones. The standard library tends to use the bleeding-edge features more than user Rust code (as it contains implementations of core traits and whatnot), so its churn is high. Despite what others have suggested, I don't think it needs a total rewrite, but various names should change.
A "go"-like binary is on the roadmap; it's mostly a question of refactoring. We have a pretty printer, a doc generator, a package manager, and a compiler (all in various stages of completeness); the trick is to just bundle them into one nice package.
A trail of notes would definitely be helpful, to see what the initial hurdles are for beginners.
From what I've seen the biggest problem is that 0.3's syntax is totally different from the unreleased 0.4 (due to be released next week). Most people, understandably, build from the packaged 0.3 and none of the examples in the documentation work. 0.4 contains the syntax we're committing to; most of the changes from then on should be backwards-compatible with it (unless you use the deprecated stuff, which we're adding warnings for).
A "go"-like binary is on the roadmap; it's mostly a question of refactoring. We have a pretty printer, a doc generator, a package manager, and a compiler (all in various stages of completeness); the trick is to just bundle them into one nice package.
A trail of notes would definitely be helpful, to see what the initial hurdles are for beginners.
From what I've seen the biggest problem is that 0.3's syntax is totally different from the unreleased 0.4 (due to be released next week). Most people, understandably, build from the packaged 0.3 and none of the examples in the documentation work. 0.4 contains the syntax we're committing to; most of the changes from then on should be backwards-compatible with it (unless you use the deprecated stuff, which we're adding warnings for).
(due to be released next week).
I will be eagerly looking forward to that!! Is the 0.4 version a step ahead of the past alphas? Is it finally becomming a beta?
I will be eagerly looking forward to that!! Is the 0.4 version a step ahead of the past alphas? Is it finally becomming a beta?
My mistake, it's actually 2 weeks ("mid-September" is the target date). Still close. It's still an alpha, but there are huge changes, and most importantly, syntax becomes "slushy" after 0.4 (not frozen, but massive changes have a high bar to clear).
(Disclaimer: occasional Rust contributor)
I agree, Rust's documentation is really awful at the moment. I mean, there's a reason for it: the syntax and semantics are evolving so fast that any tutorial written right now will be hopelessly out of date in two weeks (note that the official tutorial has been updated regularly, but you can't even tell!), and much of the current stdlib is comprised of quick hacks based on obsolete language features and may very well get near-entirely rewritten before 1.0. Of course, that's no consolation for people who don't consistently lurk in the dev channels.
There's some hope, though. The next release (0.4, due in perhaps a month) has been tentatively designated as the "syntax freeze" release, so at the very least things should cool down after that point (fingers crossed). But until then, I wouldn't advise newcomers to get anywhere near Rust, for fear of the constant breaking changes that are leading up to the syntax freeze.
I agree, Rust's documentation is really awful at the moment. I mean, there's a reason for it: the syntax and semantics are evolving so fast that any tutorial written right now will be hopelessly out of date in two weeks (note that the official tutorial has been updated regularly, but you can't even tell!), and much of the current stdlib is comprised of quick hacks based on obsolete language features and may very well get near-entirely rewritten before 1.0. Of course, that's no consolation for people who don't consistently lurk in the dev channels.
There's some hope, though. The next release (0.4, due in perhaps a month) has been tentatively designated as the "syntax freeze" release, so at the very least things should cool down after that point (fingers crossed). But until then, I wouldn't advise newcomers to get anywhere near Rust, for fear of the constant breaking changes that are leading up to the syntax freeze.
I would be happy to maintain a newbie's guide, syntax changes and all (I've read the meeting notes, I know what you're talking about) if somebody can help me learn enough Rust to know what I'm talking about.
Edit: Fuck it, I'll make a website.
Edit: Fuck it, I'll make a website.
If you do, please post it to the mailing list!
https://mail.mozilla.org/listinfo/rust-dev
https://mail.mozilla.org/listinfo/rust-dev
Sub waiting for mod approval.
Rust is still a nebula.... I expect a beginner freindly tutorial after some more stability in syntax. Now, pc will have a better answer for the availabilty beginner's tutorial... Good Documentation and Tutorial is factually a must....
Having said that, I am enjoying Rust, and I will have it as my primary production language for real software in future.(By next year, as Greydon say, when it is a bit more stable. Till then its just acedemic coding)
And Patrick(reminding), People are asking for a good beginer's tutorial...
And Patrick(reminding), People are asking for a good beginer's tutorial...
+1. I recently tried to get a little bit of file I/O going and it was a PITA.
I'm very interested to know more about your use of racket in production. Could you share your experience?
Well, 'production' may be too grand a term. My programs are usually on the order of a few hundred lines or less.
I'm a geneticist whose (work) code is centered around data processing. I previously used Perl for just about everything (although I've used Python & Ruby also), but started to broaden my programming horizons recently, and after a grand tour of what was on offer I settled on Racket as my language of choice for the more complex end of the scripts I was writing. I'm finding it easier to maintain (and especially refactor) complex scripts in Racket than I did in Perl (or Python or Ruby), and the increase in performance is substantial when processing huge data-sets. One current weakness of Racket here is the relative lack of specific libraries for bioinformatics, but most of my code doesn't need any anyway and when it does I revert to Perl.
I'm also excited about investigating other areas of the language, especially Typed Racket, as static typing is something I haven't really utilized so far.
In general, the more I learn about Racket the more I admire the quality of design that has gone into it; everything seems to be extremely well thought out, not just from a theoretical perspective, but from a practical one too.
I'm a geneticist whose (work) code is centered around data processing. I previously used Perl for just about everything (although I've used Python & Ruby also), but started to broaden my programming horizons recently, and after a grand tour of what was on offer I settled on Racket as my language of choice for the more complex end of the scripts I was writing. I'm finding it easier to maintain (and especially refactor) complex scripts in Racket than I did in Perl (or Python or Ruby), and the increase in performance is substantial when processing huge data-sets. One current weakness of Racket here is the relative lack of specific libraries for bioinformatics, but most of my code doesn't need any anyway and when it does I revert to Perl.
I'm also excited about investigating other areas of the language, especially Typed Racket, as static typing is something I haven't really utilized so far.
In general, the more I learn about Racket the more I admire the quality of design that has gone into it; everything seems to be extremely well thought out, not just from a theoretical perspective, but from a practical one too.
>Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in.
Well, it does excel in scientific computing. Biologists, astronomers and such use it a lot, and it has lots of advanced math/stats/physics etc libs, with fast C implementations underneath.
Well, it does excel in scientific computing. Biologists, astronomers and such use it a lot, and it has lots of advanced math/stats/physics etc libs, with fast C implementations underneath.
Run Python under strace sometime. Laugh as it attempts to open thousands of non-existent files just to start up. Cry when you imagine that happening on a thousand-node scientific computing cluster with an NFS root. IIRC we saw something on the order of 10-20 minutes to get Python started on every node of a Blue Gene allocation.
Ditto for Perl because of BioPerl (used in the Human Genome Project) & PDL (which IIRC was being used somewhere at NASA).
links: http://en.wikipedia.org/wiki/BioPerl | http://pdl.perl.org/
links: http://en.wikipedia.org/wiki/BioPerl | http://pdl.perl.org/
I believe Perl in bioinformatics was a combination of three or four factors. At that time, sequence analysis was mostly equivalent to string processing and executing command-line programs. Perl was a natural fit. Bioinformatics work used Suns running Sybase, so the researchers knew the Unix way of doing things, which is what perl builds on. This was the early days of the web, and bioinformatics people were very much into data sharing. They used perl to write CGI programs (both cgi-lib.pl and CGI.pm were written by bioinformatics people), so they had one language which they could use for sequence research, for system administration, and for data sharing.
Other languages evolved through a different path. Chemistry, for example, tends to be more Python related. (I develop software for that field.) I think it's because the chemical graph data structure is harder to write naturally in Perl. Gene expression analysis uses a lot of R.
Other languages evolved through a different path. Chemistry, for example, tends to be more Python related. (I develop software for that field.) I think it's because the chemical graph data structure is harder to write naturally in Perl. Gene expression analysis uses a lot of R.
In hindsight it doesn't seem so surprising. Go really isn't a good alternative to C++ for the kinds of things that really need the low-level control and direct memory access C++ provides. And if you don't really need those things you probably should have moved on to Java or Ruby/Python/etc already.
And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that were willing to take a risk on Python or Ruby are now into Go. It offers a lot of the expressiveness of either of the former with much better performance, concurrency as a fundamental, and the extra safety of static type checking.
And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that were willing to take a risk on Python or Ruby are now into Go. It offers a lot of the expressiveness of either of the former with much better performance, concurrency as a fundamental, and the extra safety of static type checking.
Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
Python and Ruby programmers come to Go because they don't
have to surrender much expressiveness, but gain
performance and get to play with concurrency.
C++ programmers don't come to Go because they have fought
hard to gain exquisite control of their programming
domain, and don't want to surrender any of it. To them,
software isn't just about getting the job done, it's
about doing it a certain way.
The issue, then, is that Go's success would contradict
their world view.
And we should have realized that from the beginning.
People who are excited about C++11's new features are not
going to care about a language that has so much less.
Even if, in the end, it offers so much more.I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that.
I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could.
Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit.
My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(
I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could.
Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit.
My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(
I think C/C++ programmers have had their reign long enough and have shown us through the amount of utterly horrible security issues that managing memory yourself is a bad idea.
Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS.
I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level.
It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.
Due to my engineering background, I would always sacrifice performance for less risk and more reliability.
I've also spent 20 years writing C and C++ so I know how horrible it is.
Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS.
I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level.
It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.
Due to my engineering background, I would always sacrifice performance for less risk and more reliability.
I've also spent 20 years writing C and C++ so I know how horrible it is.
Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS.
The anything-but-the-OS-niche? I thought we had plenty of languages for that.
It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.
You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?
Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that?
When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)
Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
The anything-but-the-OS-niche? I thought we had plenty of languages for that.
It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.
You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?
Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that?
When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)
Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
The anything-but-the-OS-niche? I thought we had plenty of languages for that.
We have plenty of languages, but most of them are low performance interpreted languages, have major compromises or are not architecturally sound. Go addresses a lot of those issues - more than any other language so far.
You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?
I don't ignore performance. There are many ways to achieve performance. I've worked on embedded systems (military, medical sector) and occasionally need direct hardware access which is where I use C/C++ and that is primarily to manipulate a device and hand off a suitable abstraction to a higher level language (with a garbage collector).
When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)
That is all down to determinism. Determinism can be achieved in various simple ways. If you understand the language, you can write code that pre-allocates and reuses memory in critical sections therefore invoking no garbage collection penalty. Isolating critical sections from each other is still a problem in C/C++ if you consider the threading model that they use.
Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
I'm not a fan of all "those 20 JVM-based languages" - I find them tedious and ugly. I'm the most critical person on the planet when it comes to this sort of thing. Go pretty much hits the mark.
I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism i.e:
We have plenty of languages, but most of them are low performance interpreted languages, have major compromises or are not architecturally sound. Go addresses a lot of those issues - more than any other language so far.
You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?
I don't ignore performance. There are many ways to achieve performance. I've worked on embedded systems (military, medical sector) and occasionally need direct hardware access which is where I use C/C++ and that is primarily to manipulate a device and hand off a suitable abstraction to a higher level language (with a garbage collector).
When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)
That is all down to determinism. Determinism can be achieved in various simple ways. If you understand the language, you can write code that pre-allocates and reuses memory in critical sections therefore invoking no garbage collection penalty. Isolating critical sections from each other is still a problem in C/C++ if you consider the threading model that they use.
Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
I'm not a fan of all "those 20 JVM-based languages" - I find them tedious and ugly. I'm the most critical person on the planet when it comes to this sort of thing. Go pretty much hits the mark.
I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism i.e:
func CriticalFunc() {
defer runtime.ResumeGC()
runtime.PauseGC()
// critical section
}"I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism"
I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC.
These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g. the JVM unless you really know what you're doing. The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.
I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC.
These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g. the JVM unless you really know what you're doing. The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.
GC doesn't have to be global or blocking. If you look at the GC in CLR/.Net 4+ then it can run GC on low priority background threads.
I know Go's GC isn't there yet, but it's easier to centralize a performance improvement under this model i.e. GC improvements will lead to global improvements rather than case by case.
There's more than one way to skin a cat on this one.
I know Go's GC isn't there yet, but it's easier to centralize a performance improvement under this model i.e. GC improvements will lead to global improvements rather than case by case.
There's more than one way to skin a cat on this one.
> The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.
And Go makes it much easier to avoid generating garbage than pretty much every other GC language around, already "by default" Go code tends to generate dramatically less garbage than for example Java, and when you care, you can further fine tune it to produce even less garbage.
And Go makes it much easier to avoid generating garbage than pretty much every other GC language around, already "by default" Go code tends to generate dramatically less garbage than for example Java, and when you care, you can further fine tune it to produce even less garbage.
Genuine question, from ignorance: How does Go create less garbage than Java? I can certainly appreciate that a lot of the common frameworks used in JEE development may be memory-hogs, but the language itself?
You want Rust: http://www.rust-lang.org/
You should look at Ada 2005 (or Ada 2012). Ada is battle-proven and comes with plenty of reliability tools and inbuilt safety. It's also focused on embedded, distributed and real-time systems.
AdaCore provides high quality compilers and tools (GPLed) under http://libre.adacore.com/
Interested fellas might start with reading this article: http://www.adacore.com/adaanswers/gems/gem-30/
EDIT: oops, that should be an answer to eckyptang... anyway, check out Ada. :)
AdaCore provides high quality compilers and tools (GPLed) under http://libre.adacore.com/
Interested fellas might start with reading this article: http://www.adacore.com/adaanswers/gems/gem-30/
EDIT: oops, that should be an answer to eckyptang... anyway, check out Ada. :)
I'll definitely read up more on Rust, thanks.
+1 Rust is a lot closer to systems....
> I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that.
Java believed the same thing. Many did switch. The difference today is that most of the people liable to switch already switched to Java.
If I could guess, I'd guess that Go is doing a better job at picking up Java programmers than C++ ones.
Java believed the same thing. Many did switch. The difference today is that most of the people liable to switch already switched to Java.
If I could guess, I'd guess that Go is doing a better job at picking up Java programmers than C++ ones.
I've been meaning to ask someone that. If you switch from java to go, is it really such an improvement in non-trivial cases ?
In Go, you'll be doing the C thing : you'll be reimplementing every datastructure from scratch (or use void, also known as interface{}), and have the same memory allocation problems as java. The problem with that is obvious : only experienced C library authors stand any chance of getting complicated trees right the first time (and I still only seen one person get red-black trees insert right first time once*, 3 other university professors and several assistants failed).
And the fact that you need to write those things from scratch everytime means you've got to debug that extremely finicky and difficult code every single time ... and then a junior programmer comes in and says "hey I can get to the internal fields easy, why don't I just" and you're in for an 8 hour debugging session because that causes a crash in the normal insert code, not the actually wrong code.
One thing I did in go that really, really bugged me was sorting a list (sorting a list of strings). I was making it as short as I possibly could without violating style rules ... 70 lines of code. That's ... well that's just not reasonable.
ArrayList<String> x = Lists.newArrayList("b", "c", "d", "a"); Collections.sort(x); System.out.println(x);
Give me the Go equivalent, in less than 50 lines of code. Please. That just has got to have a short solution, right ?
As it stands, I believe Go is good at being a fast conduit for nearly-ready data. A way to write asynchronous servers. If you need complicated algorithms or quick ways to change data operations ... maybe I'm wrong but it just looks like Go is really not going to be your friend.
In Go, you'll be doing the C thing : you'll be reimplementing every datastructure from scratch (or use void, also known as interface{}), and have the same memory allocation problems as java. The problem with that is obvious : only experienced C library authors stand any chance of getting complicated trees right the first time (and I still only seen one person get red-black trees insert right first time once*, 3 other university professors and several assistants failed).
And the fact that you need to write those things from scratch everytime means you've got to debug that extremely finicky and difficult code every single time ... and then a junior programmer comes in and says "hey I can get to the internal fields easy, why don't I just" and you're in for an 8 hour debugging session because that causes a crash in the normal insert code, not the actually wrong code.
One thing I did in go that really, really bugged me was sorting a list (sorting a list of strings). I was making it as short as I possibly could without violating style rules ... 70 lines of code. That's ... well that's just not reasonable.
ArrayList<String> x = Lists.newArrayList("b", "c", "d", "a"); Collections.sort(x); System.out.println(x);
Give me the Go equivalent, in less than 50 lines of code. Please. That just has got to have a short solution, right ?
As it stands, I believe Go is good at being a fast conduit for nearly-ready data. A way to write asynchronous servers. If you need complicated algorithms or quick ways to change data operations ... maybe I'm wrong but it just looks like Go is really not going to be your friend.
Nice link. The separate submission and thread is here:
http://news.ycombinator.com/item?id=4158865
http://news.ycombinator.com/item?id=4158865
>The issue, then, is that Go's success would contradict
their world view.
I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.
I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.
If you read this whole subthread, what you basically get is a confirmation of what Rob Pike wrote in his post: a series of objections revolving around things Go doesn't have that C++ does have. Pike's point is that these objections were in hindsight inevitable, because the whole idea behind Go is to simplify the language --- Go is even simpler than ANSI C.
The Go team's idea was, look at languages like C++ and replace groups of individual features with orthogonal components that can be composed to similar effect.
Pike is a little dismissive of C++, as am I, but ultimately he acknowledges the truth of the matter: if you're dead set on writing programs using template generics and inheritance hierarchies, you're going to stick with C++. And that's OK. We don't need to argue about it.
I am very new to Go, have a background in C/C++, am Ruby today, and was Python from '02-'05. My take is that there are definitely still things I would write in C, and I would still write web frontend code in Ruby. But I see a place for Go (backend network code, network clients, things like that) and I personally see no place at all for C++ (but then, the C++ people might not see any place at all for C). Go doesn't have to be all things to all people.
The Go team's idea was, look at languages like C++ and replace groups of individual features with orthogonal components that can be composed to similar effect.
Pike is a little dismissive of C++, as am I, but ultimately he acknowledges the truth of the matter: if you're dead set on writing programs using template generics and inheritance hierarchies, you're going to stick with C++. And that's OK. We don't need to argue about it.
I am very new to Go, have a background in C/C++, am Ruby today, and was Python from '02-'05. My take is that there are definitely still things I would write in C, and I would still write web frontend code in Ruby. But I see a place for Go (backend network code, network clients, things like that) and I personally see no place at all for C++ (but then, the C++ people might not see any place at all for C). Go doesn't have to be all things to all people.
>I personally see no place at all for C++
Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps.
C is too low level for those kinds of things, and Go too high level.
Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters.
E.g you're gonna find more experienced C++ programmers to make you the next, say, Call of Duty or Logic Pro 9, than you're gonna find Go programmers. And far more code and libs to leverage.
Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps.
C is too low level for those kinds of things, and Go too high level.
Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters.
E.g you're gonna find more experienced C++ programmers to make you the next, say, Call of Duty or Logic Pro 9, than you're gonna find Go programmers. And far more code and libs to leverage.
It's true: C++ is probably going to own AAA games for a long time, and, for desktop applications, you're going to tend to use the "golden path" dev environment for each platform (ie, ObjC for Mac apps, C++/Managed C++ for $50 Windows desktop apps. Right now, I'm not sure I know of a desktop app environment where Go fits on the golden path.
And, I'll restate: from the 1000-or-so lines of Go I've written so far, I'm pretty clear that I wouldn't want to use it for frontend web stuff (anything with serverside templates). But I'd probably use it before I would use Node.js for a backend web service, or maybe even for a single-page app.
And, I'll restate: from the 1000-or-so lines of Go I've written so far, I'm pretty clear that I wouldn't want to use it for frontend web stuff (anything with serverside templates). But I'd probably use it before I would use Node.js for a backend web service, or maybe even for a single-page app.
Note that at least Adobe has started to put significant amounts of Lua into their user facing applications, as the glue on top of C++ components.
Outside of the lack of bindings to proper UI frameworks, I couldn't say why you shouldn't write e.g. Word in a higher level language than C++. You might have to be careful with memory usage in some components, maybe even write those in native code, but for the vast majority of interactions something higher level should work, shouldn't it?
After all you can implement something akin to Word in JS + HTML (Google Docs).
Outside of the lack of bindings to proper UI frameworks, I couldn't say why you shouldn't write e.g. Word in a higher level language than C++. You might have to be careful with memory usage in some components, maybe even write those in native code, but for the vast majority of interactions something higher level should work, shouldn't it?
After all you can implement something akin to Word in JS + HTML (Google Docs).
C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance.
Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
http://golang.org/pkg/container/list/
Casting every list element to "interface{}" is not generic.
Casting every list element to "interface{}" is not generic.
Use slices.
Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.
Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.
Slice still restricts you to an array data structure (a continuous block of memory). How would you implement a sorted set in Go? It should be generic and type safe and efficient, please. Compare with the C++ solution.
I think the problem with saying that Go can be used as a C++ replacement is that the statement is too vague. The problem space in which Go is a great tool and the one in which C++ is a great solution have a big overlap. But that does not mean that you will solve a given problem in this overlapping space the same way. Both languages have a different set of trade-offs.
If you need a typesafe, generic sorted set with strict efficiency needs (or things like precise control over memory layout and such) then by all means go for C++, it's been designed for that kind of constraints.
If you need a typesafe, generic sorted set with strict efficiency needs (or things like precise control over memory layout and such) then by all means go for C++, it's been designed for that kind of constraints.
> If you need a typesafe, generic sorted set with strict efficiency needs
When people ask for things like this, I can't help to think that what they want is not generic at all, they want something very specific to the problem they are solving, in those cases just writing custom data structures is the way to go in any language anyway.
It is the way it has been done in C for decades too.
When people ask for things like this, I can't help to think that what they want is not generic at all, they want something very specific to the problem they are solving, in those cases just writing custom data structures is the way to go in any language anyway.
It is the way it has been done in C for decades too.
You may be able to write the custom data structures more easily with the STL than in C.
Go does not have generics per se but that container looks pretty generic to me.
What's your definition of generic programming BTW? I'm looking at several definition right now and cannot find out if, for example, a generic list container in C using void pointers to data would be considered generic programming.
Wikipedia states generic programming is "a computer programming paradigm based on method/functions or classes defined irrespective of the concrete data types used upon instantiation". That reads like "templates" to me.
What's your definition of generic programming BTW? I'm looking at several definition right now and cannot find out if, for example, a generic list container in C using void pointers to data would be considered generic programming.
Wikipedia states generic programming is "a computer programming paradigm based on method/functions or classes defined irrespective of the concrete data types used upon instantiation". That reads like "templates" to me.
To me, generic programming implies preserving all type information, which is something the above Go container does not do (when you get an element out of the container, you cannot tell statically what type it is).
Templates are generic, but so is, e.g. the type inference used in functional languages.
Templates are generic, but so is, e.g. the type inference used in functional languages.
In some sense, you can do generic programming with C by using void*, but this throws out type safety.
I'd say void pointers are more untyped programming than generic programming.
One look at the Go standard library contradicts this. Go is perfectly adequate for abstraction.
I think you may be talking past each other. C++ or D templates allow you to express (in a crude, verbose, error-prone way) some kinds of abstractions that are not expressible in Golang or ML. Not sure about C#.
There are certainly lots of abstractions you can express in Golang.
There are certainly lots of abstractions you can express in Golang.
> Go does not have generics yet,
From all accounts it will never ever get generics.
> and C++ is better for performance.
As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++.
But the big question is, is it really that much slower?
And the fact that it is a GC language means it is a much simpler language than C++.
From all accounts it will never ever get generics.
> and C++ is better for performance.
As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++.
But the big question is, is it really that much slower?
And the fact that it is a GC language means it is a much simpler language than C++.
> As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++.
Actually C malloc, free, C++ new, etc. are really slow functions. Garbage collected languages can typically 'allocate' memory with little more than top of heap pointer increment.
You can implement similar memory pools with C/C++, but it's hard to get right when large allocations are made, compacting is very hard, etc. It does work for limited applications, for example ones that have a lot of short-lived small objects.
Multi-threaded garbage collected languages also don't need locking for freeing objects. With manual memory management you might need to lock the parent object before freeing the child to prevent some other thread from loading a pointer to the free'd child object. Locks are slow, even atomic primitives require slow inter-CPU communication. Garbage collection can avoid that completely. Performance win for gc can be hundreds of percents with 16+ CPUs.
Actually C malloc, free, C++ new, etc. are really slow functions. Garbage collected languages can typically 'allocate' memory with little more than top of heap pointer increment.
You can implement similar memory pools with C/C++, but it's hard to get right when large allocations are made, compacting is very hard, etc. It does work for limited applications, for example ones that have a lot of short-lived small objects.
Multi-threaded garbage collected languages also don't need locking for freeing objects. With manual memory management you might need to lock the parent object before freeing the child to prevent some other thread from loading a pointer to the free'd child object. Locks are slow, even atomic primitives require slow inter-CPU communication. Garbage collection can avoid that completely. Performance win for gc can be hundreds of percents with 16+ CPUs.
>But the big question is, is it really that much slower?
So, there's a pretty good shibboleth/knowledge smell you can use to detect whether somebody's done systems programming and knows what they're talking about or not.
Whether they think relying completely on the heap is a "small" cost or not.
Try writing some code in a real-time constrained environment where non-determinism is unacceptable. See how far malloc and Boehm gets you.
So, there's a pretty good shibboleth/knowledge smell you can use to detect whether somebody's done systems programming and knows what they're talking about or not.
Whether they think relying completely on the heap is a "small" cost or not.
Try writing some code in a real-time constrained environment where non-determinism is unacceptable. See how far malloc and Boehm gets you.
I disagree that the sweet spot of Go is in the same place as the sweet spot of Python. Go has put significantly less emphasis on transparently readable code. Viewed from C++, Go looks like Python, but viewed from Python Go looks like a less crazy Java.
Fast compilation (merely being-interpreted) is surely a very cool feature which makes Go more appealing, but that is not the only productivity feature of Python.
Fast compilation (merely being-interpreted) is surely a very cool feature which makes Go more appealing, but that is not the only productivity feature of Python.
Actually, If you have invested the 15+ years it takes to become a decent C++ programmer, then you won't want to throw that out just because some new language comes by.
Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance.
And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't.
Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.
Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance.
And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't.
Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.
If you have invested the 15+ years it takes to become a decent C++ programmer
I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind.
A language that doesn't affect the way you think about programming, is not worth knowing.
Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.
I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind.
A language that doesn't affect the way you think about programming, is not worth knowing.
Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.
Are you a similar username in reddit?
Yes, fairly similar but not the same.
Are you "full of bullcrap"?
Aw, how did you guess. What did you find full of it? In GC languages you still have to have to manage reference life times so that you don't leak memory by holding on to references too long(Yes I have fixed that bug in someone else's C# code). If you are already doing all the reference tracking what is wrong with making it explicit and typing the delete? Good build tools doing the minimal rebuild thing make builds manageable, sure Go's are faster but it wasn't a pain I was feeling, or have lived with so long I forgot. So for me the differences boil down to type safe generics vs the way interfaces work. Go is a worthwhile experiment(God I hope Google is doing IBM style research on Go's effect on quality, and that they share it) in how to make development better, but I don't currently think I will see enough payoff to justify the effort of switching. That is especially true when you consider all the external tidbits like library support.
Sorry, I was just asking if you were the guy at http://fullof.bs/ which goes by stonecypher on reddit...
Nope, not that guy. stonefarfalle on reddit. I probably am full of BS(after all the mouth is large and rarely closed for business), but a little too proud, and prudish to call myself that in public.
Also, Sorry for forgetting the default shouldn't be snark.
[deleted]
If you're a programmer/developer/hacker, you don't "throw out" what you already know.
Wouldn't learning a new language expand your toolset? Not replace it.
And I think most here agree that Go and C++ are solving different problem spaces. So knowing both would be a win.
Wouldn't learning a new language expand your toolset? Not replace it.
And I think most here agree that Go and C++ are solving different problem spaces. So knowing both would be a win.
I think there's a bit of truth in both
And you can't use go outside of the "PC" (that is, embedded systems).
And you can't use go outside of the "PC" (that is, embedded systems).
> And you can't use go outside of the "PC" (that is, embedded systems).
Why not? It runs on Arm.
Why not? It runs on Arm.
PPC, MIPS, SH?
But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
I suppose it depends on just how "embedded" what you're dealing with is. Clearly, something like Go is bigger and slower than C, so there will be places where it's not useful. I could certainly see it being useful elsewhere though.
I think GCCGO should work for PPC and MIPS, not sure about SH, but is worth a try.
You need a deterministic memory management.
For what? Android does fine without it, if you still consider that embedded. Java is used in a wide variety of embedded systems without trouble.
Sure, there are some places that can't use Go. But there are also places that cant use dynamically allocated memory or recursion. Not all embedded systems are safety critical or need to be absolutely deterministic.
Sure, there are some places that can't use Go. But there are also places that cant use dynamically allocated memory or recursion. Not all embedded systems are safety critical or need to be absolutely deterministic.
Actually, from conversations with the Android team, Android system and apps code goes to great effort to use manual free lists and object recycling to avoid allocations during animations. Manual memory management is necessary to compete with the manually-memory-managed iOS frameworks. And Dalvik has an incremental, generational GC...
I write Go and I have been satisfied with the low-level control and direct memory access. The language has pointers and you can cast between ints and pointers, so you can do anything you can do in C.
If you're writing realtime code, you can avoid triggering the garbage collector simply by not allocating memory on the heap. It is harder to get anything done this way, but writing realtime code in any language is difficult.
If you're writing realtime code, you can avoid triggering the garbage collector simply by not allocating memory on the heap. It is harder to get anything done this way, but writing realtime code in any language is difficult.
I actually haven't gotten this far with Go myself so I'm glad to hear that it's possible.
But there's a huge uphill battle ahead for Go here. For instance, I write C++ code because I'm doing music software and all the APIs and existing code libraries and samples are in C++. It's just so much easier in this environment to put up with C++'s warts than it would be to try to shoehorn Go in there. As John Carmack says, externalities can quickly overwhelm the advantages of any particular language.
But if you're implementing web services from scratch you don't have any of that baggage to carry around so it's much easier to choose Go.
But there's a huge uphill battle ahead for Go here. For instance, I write C++ code because I'm doing music software and all the APIs and existing code libraries and samples are in C++. It's just so much easier in this environment to put up with C++'s warts than it would be to try to shoehorn Go in there. As John Carmack says, externalities can quickly overwhelm the advantages of any particular language.
But if you're implementing web services from scratch you don't have any of that baggage to carry around so it's much easier to choose Go.
Swig can help there?
For my particular application it's not even close to worth it, but in some cases I can imagine it might be worth the hassle.
or cgo? http://golang.org/cmd/cgo/
>you can do anything you can do in C
This is true only for very limited meanings of "anything"; if your point was that you had direct control of memory layout and you can use CGO for those things that C offers but go does not. For instance, the volatile keyword..
This is true only for very limited meanings of "anything"; if your point was that you had direct control of memory layout and you can use CGO for those things that C offers but go does not. For instance, the volatile keyword..
> In hindsight it doesn't seem so surprising.
Most things don't seem surprising in hindsight. That's why you don't judge surprises by it.
If C++ programmers did flock to Go, would you then say that that was surprising? If not, you've just fallen victim to hindsight bias (because a model that predicts everything is useless).
Most things don't seem surprising in hindsight. That's why you don't judge surprises by it.
If C++ programmers did flock to Go, would you then say that that was surprising? If not, you've just fallen victim to hindsight bias (because a model that predicts everything is useless).
Most things don't seem surprising in hindsight. That's why you don't judge surprises by it.
Surprising was GP's original term, not mine.
I don't expect Go or any other language to displace C++ any time soon. But I do think the "scripting" languages are very vulnerable to challenges from languages with static typing systems less primitive than Java's.
Surprising was GP's original term, not mine.
I don't expect Go or any other language to displace C++ any time soon. But I do think the "scripting" languages are very vulnerable to challenges from languages with static typing systems less primitive than Java's.
That's because the GP was surprised. I rather should have said, you don't judge that something wasn't surprising by hindsight.
Hindsight makes things obvious.
Hindsight makes things obvious.
I think a lot of it is that people sort of did want some static type checking, but were not willing to give up on things like garbage collection or some of the other niceties that the dynamic languages provided.
As someone who has been clamoring for a statically-checked Python-esque language, Go looks awesome.
As someone who has been clamoring for a statically-checked Python-esque language, Go looks awesome.
[deleted]
If that's the case, I hope that Haml [and Sass] get properly ported to Go!
I'm aware of gohaml; but last I checked it hasn't been updated to work with Go1 and friends. Namely it's using `gomake` and the packages aren't organized for use with `go build`; those issues alone have stopped me from considering it.
I went for a version of mustache.go instead, and then bolted Lambda support onto it.
I'm aware of gohaml; but last I checked it hasn't been updated to work with Go1 and friends. Namely it's using `gomake` and the packages aren't organized for use with `go build`; those issues alone have stopped me from considering it.
I went for a version of mustache.go instead, and then bolted Lambda support onto it.
I'd be really curious to know what their "800 million requests a month" means. When we actually added up numbers a while back, we were doing around 250 million requests to our Python machines/day, and we only had 200 servers (which included dbs/etc), that was around 3-3.5 billion pageviews a month IIRC. We now have 300 machines and do about 5 billion pageviews, but that completely ignores the huge amounts of requests to our realtime stream servers and our API (which get shit on every "pageview" at least once).
It's really hard to compare different systems without knowing what kind of complexity each pageview engenders in terms of backend processing.
At one end there's flat HTML files, where you could serve 800 million pages/month from maybe a single particularly beefy server; at the other fully-dressed SOAs and CEPs and your uncle's pet dog rover performing multivariate regressions, meaning you need 9,000 servers.
At one end there's flat HTML files, where you could serve 800 million pages/month from maybe a single particularly beefy server; at the other fully-dressed SOAs and CEPs and your uncle's pet dog rover performing multivariate regressions, meaning you need 9,000 servers.
I'm hoping they'll provide some more insight into what the breakdown of tasks are between the machines, and if that 800 million number is actually correct.
It seems extremely high for what my absolutely-no-idea-what-these-sites-could-possible-need-that-many-servers-for thought process can fathom.
It seems extremely high for what my absolutely-no-idea-what-these-sites-could-possible-need-that-many-servers-for thought process can fathom.
200 servers for 800mio requests seems a little nuts.
Two of my customers are doing 500mio and 400mio respectively on ~20 each, on Rails (i.e. as slow as it gets).
Two of my customers are doing 500mio and 400mio respectively on ~20 each, on Rails (i.e. as slow as it gets).
Do you count cache hits as a request?
I don't know about him but we do 1 billion/month using at peak some 12 servers (c1.xlarges and m1.xlarges), including our DB. These are all dynamic requests.
Moovweb creates mobile versions of standard websites on the fly. That sounds pretty expensive, and they probably have a ton of network overhead from distant servers and slow clients.
Moovweb creates mobile versions of standard websites on the fly. That sounds pretty expensive, and they probably have a ton of network overhead from distant servers and slow clients.
I interviewed with moovweb a while back... they basically transcode non-mobile-optimized sites into mobile-optimized sites on the fly by transforming html/css/etc.
The results...aren't great.
I want to try out Go, but the problems exposed by the garbage collector on 32bit systems scared me away.
Is that still the case with the latest version 1.0.2 ?
Also, is there any chance for a precise generational garbage collector to get implemented for Go? As far as I know, pointers make the implementation of precise garbage collectors difficult.
Is that still the case with the latest version 1.0.2 ?
Also, is there any chance for a precise generational garbage collector to get implemented for Go? As far as I know, pointers make the implementation of precise garbage collectors difficult.
Here's a dime, go buy yourself an AMD64.
There is code to make the garbage collector more precise currently in review. A few packages from the stdlib were changed to reduce the chance that package level variables might pin used sections of memory.
Most people have no problems with the garbage collector on 32bit systems.
AFAIK, yes it is still the case (although somewhat slightly improved), but precise collector is officially expected (and being worked on) for version 1.1 . The latter was explicitly said on a Q&A session on Google I/O conference, the video is available somewhere on teh interwebs.
edit: I think it's this one: http://youtu.be/sln-gJaURzk ("Meet the Go team"), but maybe some other from: http://blog.golang.org/2012/07/go-videos-from-google-io-2012... (sorry, don't have time to watch them all again now to make sure ;)
edit: I think it's this one: http://youtu.be/sln-gJaURzk ("Meet the Go team"), but maybe some other from: http://blog.golang.org/2012/07/go-videos-from-google-io-2012... (sorry, don't have time to watch them all again now to make sure ;)
That's good to know, thanks.
> I want to try out Go, but the problems exposed by the garbage collector on 32bit systems scared me away.
If you run a 64 bit server then these problems just goes away.
And from all accounts these issues will also be fixed for 32 bit systems in then next Go release or two.
If you run a 64 bit server then these problems just goes away.
And from all accounts these issues will also be fixed for 32 bit systems in then next Go release or two.
How do you run golang as a server? Can anyone point me to a basic tutorial? Is it still running under something like Apache is golang IS the server somehow? If so Wouldn't each http request have to fire up the compiled executable? Isn't that slow?
>>How do you run golang as a server?
Using the net/http package that comes with Go.
>>Can anyone point me to a basic tutorial?
To learn Go - http://tour.golang.org/
To learn about http http://golang.org/doc/effective_go.html (A list of available functions are found here http://golang.org/pkg/net/http/)
Gorilla is a great web framework that builds upon the net/http package - http://gorilla-web.appspot.com/
>>Is it still running under something like Apache is golang IS the server somehow? If so Wouldn't each http request have to fire up the compiled executable?
What you are describing is CGI (http://en.wikipedia.org/wiki/Common_Gateway_Interface) whilst it could be possible but don't for real severs its really old and slow.
Using the net/http package that comes with Go.
>>Can anyone point me to a basic tutorial?
To learn Go - http://tour.golang.org/
To learn about http http://golang.org/doc/effective_go.html (A list of available functions are found here http://golang.org/pkg/net/http/)
Gorilla is a great web framework that builds upon the net/http package - http://gorilla-web.appspot.com/
>>Is it still running under something like Apache is golang IS the server somehow? If so Wouldn't each http request have to fire up the compiled executable?
What you are describing is CGI (http://en.wikipedia.org/wiki/Common_Gateway_Interface) whilst it could be possible but don't for real severs its really old and slow.
The compiled output will contain your network server. you run the process and it listens on a socket. It is pretty straightforward. Using HTTP as an example, each request will run in a goroutine which is somewhere between a thread and a coroutine.
It is extremely fast.
The main risk is process failure which is very rare but can be mitigated via putting a front end balancer such as nginx or apache mod_proxy. Process recovery and spawning can be managed by another tool such as supervisord.
However, you can run a process happily from init if you desire.
It is extremely fast.
The main risk is process failure which is very rare but can be mitigated via putting a front end balancer such as nginx or apache mod_proxy. Process recovery and spawning can be managed by another tool such as supervisord.
However, you can run a process happily from init if you desire.
I was always taught never to write my own web server since something like Apache has been tested on millions of sites, and you have security experts designing it.
Does writing your own server in Go kind of violate this idea? Are you opening yourself up to re-inventing a web server and repeating decades of mistakes something like Apache has already figured out and fixed?
Does writing your own server in Go kind of violate this idea? Are you opening yourself up to re-inventing a web server and repeating decades of mistakes something like Apache has already figured out and fixed?
You are correct - you should never write your own web server. In this case, you're not writing your own web server. There is one provided with the standard library which will be embedded into your binary.
You are writing a bunch of handlers (as you would with Apache) and plugging them into the compiled in web server from the standard library.
For network servers, there is standard library support for SMTP, HTTP, normal stream based text protocols etc as well as serialization formatters and parsers for JSON, XML, HTML etc. You should never have to re-invent the wheel.
You are writing a bunch of handlers (as you would with Apache) and plugging them into the compiled in web server from the standard library.
For network servers, there is standard library support for SMTP, HTTP, normal stream based text protocols etc as well as serialization formatters and parsers for JSON, XML, HTML etc. You should never have to re-invent the wheel.
That's why you front-end app servers with reverse proxies like nginx and Varnish. In practical reality, most major sites run applications out of app servers that are less well tested than Apache. This is not a real objection.
Writing a (web)server in Go is not so much about reinventing the wheel, as it is about slapping together the existing building blocks into a server specifically tailored to your application.
These building blocks are very complete and are all available in the standard library. This means they are tested, debugged, tested again and have become pretty damn robust.
The point about Apache/NGinx being well established and battle hardened still stands, but Go's library is quickly following suit.
What Go offers over the others in this respect, is that you do not have to settle for a monolithic one-size-fits-all package. The code you write in Go does one thing (serve your application) and does it well without any compromises.
These building blocks are very complete and are all available in the standard library. This means they are tested, debugged, tested again and have become pretty damn robust.
The point about Apache/NGinx being well established and battle hardened still stands, but Go's library is quickly following suit.
What Go offers over the others in this respect, is that you do not have to settle for a monolithic one-size-fits-all package. The code you write in Go does one thing (serve your application) and does it well without any compromises.
It should also be noted, that you're not being encourage to serve static media with your go app. it's more like fastcgi or wsgi. you would have apache or nginx sitting in front of your app listening only on localhost serving dynamic pages only.
Thanks! That's exactly what I was trying to figure out. You're a gem.
So is there anywhere I can see an example of code that runs a server like this?
So is there anywhere I can see an example of code that runs a server like this?
From the tour - I've added comments for clarity:
// this defines the entry point
package main
// import formatting and HTTP server packages
import (
"fmt"
"net/http"
)
// This is your HTTP Server instance
type Hello struct{}
// This is a method on your HTTP server instance that sends hello for all requests
func (h Hello) ServeHTTP(
w http.ResponseWriter,
r *http.Request) {
fmt.Fprint(w, "Hello!")
}
// this is your entry point
func main() {
// create a new HTTP Server instance
var h Hello
// tell the runtime to serve it
http.ListenAndServe("localhost:4000",h)
}"100% of our production system is now running Go as 95% of our application (C being the other bits)"
So... 95% of their production system is running Go.
So... 95% of their production system is running Go.
Like all those people that say they are running 100% python/php/ruby etc.
They've done studies. 65% of the time, it works every time.
the C code is also being run under Go's control via Cgo.
My production system is written in 100% bash and some other code run under Bash's control. :-)
if it was a 95/5% split, that might be a fair (and terrifying) thing to say.
Mine is running under 100% control of grub
grub doesn't control anything, it transfers control to the OS and is never contacted or heard from again. More concretely, in the case of Linux, the init task (first task and parent of every other task) function has a "tail" call to cpu_idle which never turns.
http://lxr.free-electrons.com/source/init/main.c?a=arm#L359
http://lxr.free-electrons.com/source/init/main.c?a=arm#L359
This is a really awkward sentence: "100% of our production system is now running Go as 95% of our
application."
I'm curious what the 5% is that they didn't convert to go.
I'm curious what the 5% is that they didn't convert to go.
Read the whole paragraph. It's C.
"100% of our production system is now running Go as 95% of our application (C being the other bits). Not side bits, but our critical path."
"100% of our production system is now running Go as 95% of our application (C being the other bits). Not side bits, but our critical path."
I meant "what functionality is the remaining 5%." Not "what language is it."
Basically, once you are 95% Go, what parts are hard to convert to Go to make it 100%
Basically, once you are 95% Go, what parts are hard to convert to Go to make it 100%
Probably binding to pre-existing C libs.
It will take some time to replace 40 years of existing accumulated C libraries.
It will take some time to replace 40 years of existing accumulated C libraries.
That would be silly. It's silly to talk about the source language of third party libraries when discussing languages you use. 3rd party library code is all object code or bytecode for all it matters to your project.
It's really annoying to have to log in to read something on google+, or groups for that matter. I just won't do it.
This happens only if you have some Google login cookies already -- if you delete all your Google cookies then you won't be asked to log in.
Rather than suggesting that people delete their cookies, you could suggest checking the article in private browsing mode (or whatever their browser of choice calls the feature).
No it's the usenet remnants, not google+. But yeah, google made usenet worse too.
You have to login? It doesn't do that for me, and I'm not logged into any Google products...
Google has invented a new login state between "logged in" and "not logged in" called "not logged in enough". It's kind of like being logged in, except nothing works and you get asked to login again. Also, you can't logout.
You can log out. You click "log out and log in as a different user", and then bail out. Then you can use Google's public-content products.
When it happened to me, no, I couldn't. I click logout, then the browser redirects, and hey look, I'm still logged in. Kinda.
Same here.
Delete your cookie or sign out. It's just a Google Groups thing for you to refresh your session and I dunno, parallel login or something (they may never have completed the dejanews cutover). Unknown users don't get a login prompt.
How's the garbage collector these days for Go? Is it close to the performance of the Java GC?
It's not as sophisticated, but Go structs are smaller than similar Java objects, so that helps beat the tradeoff
I like Go, but this is total nonsense. It does help that you can embed values in a struct, rather than using pointers. But marking everything that looks like a pointer is not efficient. Not having generations does not help.
Go is still very young, a better GC will come, just give it time. In the meanwhile, let's not pretend that the current sub-par generator is as performant as that of modern JVMs.
Go is still very young, a better GC will come, just give it time. In the meanwhile, let's not pretend that the current sub-par generator is as performant as that of modern JVMs.
Go code does produce considerably less garbage than Java code.
And with Go if you really care, you can be even more careful and produce close to no garbage.
Control over memory layout is really useful.
And with Go if you really care, you can be even more careful and produce close to no garbage.
Control over memory layout is really useful.
AFAIK, Go does not "mark everything that looks like a pointer." My understanding is that in some specific situations, the Go GC is not precise enough to distinguish between a pointer and an integer that happens to have the same value as that pointer, but I don't think it's right to say it does that all the time. Do you have evidence that it does?
No, still the same old one. Improvements are supposedly coming though (though, they were coming 2 years ago also).
There have been many improvements to the GC over the last two years, and many more are coming in Go 1.1.
GC is an area where always there is room for improvement, no matter how much you work at it.
GC is an area where always there is room for improvement, no matter how much you work at it.
To continue shopping on m.macys.com, please enable cookies in your settings.
Really? in 2012?
Really? in 2012?
Yeah, seriously. It's amazing that people are still afraid of cookies in 2012.
Yes, in 2012 there are still people who disable cookies. I know, it's weird.
It's a shopping website. It's sorta hard to do cart management without cookies.
They are a good fallback, I think he is talking about using things such as Local storage, session storage, or global storage. Since the site is their mobile site I see no reason why they aren't using the new technology available to us since most mobile devices would be able to use it. DOM storage seems to be a better fit for shopping carts than cookies anyways.
It's not about the shopping cart. It's about all the session data, especially for authentication. While you could use Dom storage for storing a session ID, you would have to send that through to the server with every request which you get for free with cookies.
Additionally, cookies can be marked as http only or even as secure, making it very hard to lose the token by virtue of a fire sheep like, or even just XSS attack.
For that reason, I personally would prefer a site using (session) cookies to one hacking it via DOM storage any day.
And finally, depending on the store you might want to persist the shopping cart between visits- likely across machines. Thus, the cart should be stored on the server and not in DOM storage.
Additionally, cookies can be marked as http only or even as secure, making it very hard to lose the token by virtue of a fire sheep like, or even just XSS attack.
For that reason, I personally would prefer a site using (session) cookies to one hacking it via DOM storage any day.
And finally, depending on the store you might want to persist the shopping cart between visits- likely across machines. Thus, the cart should be stored on the server and not in DOM storage.
Cookies are stored on the client just like DOM Storage, so nothing is free when it comes to requests and communicating with the server. I understand that both still have their place. Though I generally prefer to use DOM Storage for most things now depending on the use case. I also complete agree about keeping server-side session data.
with "free" I meant without additional effort for the developer.
When you set a cookie with a Set-Cookie header, the client will automatically send the cookie with all further requests.
When you put the session-ID somewhere in DOM storage, you have to manually amend all requests with that session-ID - either by appending it as a get parameter or, when you do nothing but AJAX, as an additional request header - but whatever you do, it's considerably more effort.
Also, looking at our logs, I see way more users with DOM storage disabled than with cookies disabled, but that might just be my user base.
When you set a cookie with a Set-Cookie header, the client will automatically send the cookie with all further requests.
When you put the session-ID somewhere in DOM storage, you have to manually amend all requests with that session-ID - either by appending it as a get parameter or, when you do nothing but AJAX, as an additional request header - but whatever you do, it's considerably more effort.
Also, looking at our logs, I see way more users with DOM storage disabled than with cookies disabled, but that might just be my user base.
Alright, thanks for the clarification on "free", I realized that is what you might have meant after posting.
That last bit about your logs is surprising, thanks for that bit of info. I may need to go do the same. Either way I use a storage wrapper so I am accommodating both types of users.
That last bit about your logs is surprising, thanks for that bit of info. I may need to go do the same. Either way I use a storage wrapper so I am accommodating both types of users.
You cannot even see the front page without cookies.
I suppose it's better than 1990s websites that would go into an endless loop but what about people who are just browsing?
I suppose it's better than 1990s websites that would go into an endless loop but what about people who are just browsing?
It's probably necessary for click tracking. Macy's will pay either a CPC or a CPA for traffic coming into their website, and that includes traffic to their homepage.
The whole site is an ad. It doesn't need ads.
Just put a session id in the URLs.
keeping a session id in the URLs is way less secure as it is susceptible to XSS attacks, it can leak in referer headers, it can be accidentally shared by people copy & pasting the URL and by extension, the session ID might even end up in a search engine and depending on your bad luck, the bots might visit the page just often enough so the session doesn't expire on the server at which point an authenticated session is in the search engines.
Session cookies on the other hand can be marked as http-only, mitigating XSS in many browsers (there are some that still screw this up with XmlHttpRequest) and by not having the session id in the url, the id is much less likely to be shared with others, nor to appear in search engines.
Also, it keeps the URLs nice looking.
So why exactly would one want to disable session cookies?
Because of all of the above reasons, I'd much rather keep users with cookies disabled away from my application than to subject them to the ugly URL fallback which will impact their security much, much more than the perceived privacy loss of session cookies (which go away when you close the browser)
Session cookies on the other hand can be marked as http-only, mitigating XSS in many browsers (there are some that still screw this up with XmlHttpRequest) and by not having the session id in the url, the id is much less likely to be shared with others, nor to appear in search engines.
Also, it keeps the URLs nice looking.
So why exactly would one want to disable session cookies?
Because of all of the above reasons, I'd much rather keep users with cookies disabled away from my application than to subject them to the ugly URL fallback which will impact their security much, much more than the perceived privacy loss of session cookies (which go away when you close the browser)
I agree, but:
>> session cookies (which go away when you close the browser)
They should, but often don't anymore.
http://dalevisser.wordpress.com/2012/07/18/how-to-fix-firefo...
>> session cookies (which go away when you close the browser)
They should, but often don't anymore.
http://dalevisser.wordpress.com/2012/07/18/how-to-fix-firefo...
[deleted]
Yes. It's 2012, cookies are non tin-foil material, get on with the program and enable them.
Or, if you insist, at least do not expect to use any web app / sales page, anything without them.
Or, if you insist, at least do not expect to use any web app / sales page, anything without them.
Whoah, 500 servers to handle an average of ~300 queries per second? Even if you generously assume they have traffic patterns that sometimes go all the way up to sustained say 5K queries per second... 500 servers? Isn't that like ... terribly wasteful?
There was this dart. It somewhat failed, so what they did was, screw up a good systems language so that it sarted looking like dart..
Edit: I just posted 3 minutes ago and I'm already in gray text. Wow.
We search with Google, run our phones with Google, run Google's browser, now they want us to write all our code in Google's language. Why Google? What's wrong with Java? Other than the fact that Oracle owns it, I miss Sun. Scott McNealy tried to make the technology world better. Scott, Gosling. Google...why should everything we do all day and night be about Google?
http://en.wikipedia.org/wiki/Go_(programming_language)
>> The syntax of Go is broadly similar to that of C
C, seriously? C??!? Why? Why would I want to go back to ... C?
>> Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic.
And that is a good thing or a bad thing or what?
>> Go allows a programmer to write functions that can operate on inputs of arbitrary type, provided that the type implements the functions defined by a given interface.
Huh? Oh I can pass interface references, ok.
>> A Go interface is best described as a set of methods, each identified by a name and signature.
That sounds like Microsoft's crappy COM from the 1990's.
The code sample on that page shows there are no braces in the if evaluation statements. A wise man, Peter Van Der Linden formerly of Sun's Compiler Group and author of Deep C Secrets wrote about using more braces if needed as explicitness is always better. I agree with that.
At this point, I think I'd rather program in Groovy or even go to JavaScript if I had to, than use Go.
Oh...the language name sux.
Tip, buy Oracle and fix Java or by Java rights from them and fix it, then programming in a language owned by Google when you own so much of our lives now wouldn't be so bad.
PS How does Guido Van Rossom feel about Go?
We search with Google, run our phones with Google, run Google's browser, now they want us to write all our code in Google's language. Why Google? What's wrong with Java? Other than the fact that Oracle owns it, I miss Sun. Scott McNealy tried to make the technology world better. Scott, Gosling. Google...why should everything we do all day and night be about Google?
http://en.wikipedia.org/wiki/Go_(programming_language)
>> The syntax of Go is broadly similar to that of C
C, seriously? C??!? Why? Why would I want to go back to ... C?
>> Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic.
And that is a good thing or a bad thing or what?
>> Go allows a programmer to write functions that can operate on inputs of arbitrary type, provided that the type implements the functions defined by a given interface.
Huh? Oh I can pass interface references, ok.
>> A Go interface is best described as a set of methods, each identified by a name and signature.
That sounds like Microsoft's crappy COM from the 1990's.
The code sample on that page shows there are no braces in the if evaluation statements. A wise man, Peter Van Der Linden formerly of Sun's Compiler Group and author of Deep C Secrets wrote about using more braces if needed as explicitness is always better. I agree with that.
At this point, I think I'd rather program in Groovy or even go to JavaScript if I had to, than use Go.
Oh...the language name sux.
Tip, buy Oracle and fix Java or by Java rights from them and fix it, then programming in a language owned by Google when you own so much of our lives now wouldn't be so bad.
PS How does Guido Van Rossom feel about Go?
>> C, seriously? C??!?
For those, like myself, that like C and do systems programming. Really never understood why people dislike or fear C so much. It is the foundation for so many systems and libraries.
For those, like myself, that like C and do systems programming. Really never understood why people dislike or fear C so much. It is the foundation for so many systems and libraries.
The main problem people have with C syntax is that it's 'old' and 'old' things are bad because new things are better.
We're an industry built on fashions. Largely the outcome of the massive success programmers can have without any formal education and so just get by knowing the "best" way to do things instead of understanding why.
There are two kinds of fools: the first kind says “it is old, and therefore it is good”; the second kind says “it is new, and therefore it is better.”
>>What's wrong with Java?
Everything is wrong with Java yet the JVM is an amazing feat. Java makes doing the simplest things ten times more convoluted. If you like the JVM then http://code.google.com/p/jgo/
>> The code sample on that page shows there are no braces in the if evaluation statements.
This is just Go's style but look you can still use braces. http://play.golang.org/p/_j7r6GB-ZN
>> The code sample on that page shows there are no braces in the if evaluation statements.
This is just Go's style but look you can still use braces. http://play.golang.org/p/_j7r6GB-ZN
> At this point, I think I'd rather program in Groovy or even go to JavaScript if I had to, than use Go. Oh...the language name sux.
Which language name were you talking about?
Which language name were you talking about?
>We search with Google, run our phones with Google, run Google's browser, now they want us to write all our code in Google's language.
Which is also open source and has a community behind it.
(Plus, you can search with Bing, run an iPhone, and run Safari/Firefox/IE)
>Why Google? What's wrong with Java?
You mean besides the stagnation (no closures? no type inference? no functional goodness? It's 2012 already), the enterprisey vibe and the lawsuits?
>>>The syntax of Go is broadly similar to that of C C, seriously? C??!? Why? Why would I want to go back to ... C?
They don't ask you to go back to C. The SYNTAX is similar. Which is also true for Java.
That said, from reading the rant, you don't seem like the type that ever was in C in the first place, so it wont be "going back" for you.
>>> Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic.
And that is a good thing or a bad thing or what?
That is what it is. Languages have different features, and it's not a spec war.
Java doesn't have tons of features C++ has (e.g operator overloading, pointer arithmetic, hey, even closures, as of the latest standard). But you don't seem to be the type that wants to go to C++, right? So why the double standard?
>>> A Go interface is best described as a set of methods, each identified by a name and signature.
That sounds like Microsoft's crappy COM from the 1990's.
Yes, I can see how you are qualified to make this kind of comparisons: "Interface of methods, with name and signature. Ah, just like COM!"
>The code sample on that page shows there are no braces in the if evaluation statements. A wise man, Peter Van Der Linden formerly of Sun's Compiler Group and author of Deep C Secrets wrote about using more braces if needed as explicitness is always better. I agree with that.
Good for you. You missed the "if needed" part.
>Oh...the language name sux.
And Rob Pike pissed on your cornflakes.
>PS How does Guido Van Rossom feel about Go?
Why should we care?
Which is also open source and has a community behind it.
(Plus, you can search with Bing, run an iPhone, and run Safari/Firefox/IE)
>Why Google? What's wrong with Java?
You mean besides the stagnation (no closures? no type inference? no functional goodness? It's 2012 already), the enterprisey vibe and the lawsuits?
>>>The syntax of Go is broadly similar to that of C C, seriously? C??!? Why? Why would I want to go back to ... C?
They don't ask you to go back to C. The SYNTAX is similar. Which is also true for Java.
That said, from reading the rant, you don't seem like the type that ever was in C in the first place, so it wont be "going back" for you.
>>> Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic.
And that is a good thing or a bad thing or what?
That is what it is. Languages have different features, and it's not a spec war.
Java doesn't have tons of features C++ has (e.g operator overloading, pointer arithmetic, hey, even closures, as of the latest standard). But you don't seem to be the type that wants to go to C++, right? So why the double standard?
>>> A Go interface is best described as a set of methods, each identified by a name and signature.
That sounds like Microsoft's crappy COM from the 1990's.
Yes, I can see how you are qualified to make this kind of comparisons: "Interface of methods, with name and signature. Ah, just like COM!"
>The code sample on that page shows there are no braces in the if evaluation statements. A wise man, Peter Van Der Linden formerly of Sun's Compiler Group and author of Deep C Secrets wrote about using more braces if needed as explicitness is always better. I agree with that.
Good for you. You missed the "if needed" part.
>Oh...the language name sux.
And Rob Pike pissed on your cornflakes.
>PS How does Guido Van Rossom feel about Go?
Why should we care?
Do you hate C syntax or love C syntax? Make up your mind.
When asked about surprising things about Go, its creators have said that they expected to recruit people from c++ communities, instead it seems to be more ruby/python people.