8 ms·

Why Go and Rust are not competitors

85 points by untothebreach 11y ago

coldtea 11y ago
>Rust and Go are both touted as memory safe. While this statement is absolutely true, both languages will not tolerate unsafe memory access, what is more important is that the world will not tolerate any new language which is not memory safe. It just so happens that Go and Rust are the first two languages to emerge after decades of evidence that in the real world, programmers as a whole, cannot safely manage memory manually. This is extremely misleading. Go and Rust are not at all "memory safe" in the same way. And Go and Rust the "first two languages" in this regard? Hardly. Rust maybe, because it uses a novel approach, but there's absolutely nothing special in Go's "memory safety" approach compared to Java (and Scala, Clojure), C#, D, Haskell, etc.
- qznc 11y ago
  It was Java which took non-manual memory management to the mainstream. Lisp takes credit for inventing garbage collection.
  - yummyfajitas 11y ago
    Visual Basic was pretty mainstream before Java. As I recall, it had something along the lines of reference counting for memory management.
  - pjmlp 11y ago
    Basic dialects and Clipper, just to cite two examples with reference counting. Smalltalk was also becoming mainstream before Java entered into the picture.
- infogulch 11y ago
  You took it the wrong way. Dave didn't say that Go's GC was special, of course garbage collectors have been around for decades. The key takeaway: > what is more important is that the world will not tolerate any new language which is not memory safe. Because of that, both Go and Rust, as a new languages, are not memory unsafe. Go's safety is boring, sure, but it's still a feature of the language. So both languages are memory safe in that they are not memory unsafe, big whoop. That's Dave's point. All new languages have this, and even though they're commonly compared with this metric, the metric itself is useless for new languages.
  - gyre007 11y ago
    >Rust and Go are both touted as memory safe. While this statement is absolutely true Duh? >So both languages are memory safe in that they are not memory unsafe This is more accurate statement imo. Saying Go is memory safe [1] is like saying a lamb is safe among a heard of hungry lions. [1] http://www.pl-enthusiast.net/2014/07/21/memory-safety/ http://www.pl-enthusiast.net/2014/07/21/memory-safety/
    - infogulch 11y ago
      From that article, safe Go prevents: buffer overflow, use after free, use of uninitialized memory, illegal free, access to undefined memory. The only thing it misses is null pointer dereference. (OOM errors are not possible to prevent in turing-complete languages.) I don't agree with your analogy. A lamb among lions is clearly very unsafe, but Go isn't unsafe; you just agreed with me on this. Your analogy fits better to C/C++. The lamb could theoretically survive, but it's very unlikely; just as unlikely as a C/C++ program with no memory bugs.
      - gyre007 11y ago
        Yes I do generally agree with you. I went a bit overboard - somewhat HN pushes me over the edge sometimes :-( Lamb metaphore would not do Go the justice indeed. I do like Go, but also do not like some opinion which oversimplify reality.
  - coldtea 11y ago
    Again, how are those "the first" after people stopped tolerating new unsafe languages? We hadn't had a new memory unsafe language catching on (or released from some major vendor) since what? C++? It was pretty much standard by the time Java was out. Heck, there were mainstream Smalltalk in the 90s, with IBM support, IDE's et al. So Smalltalk, Java, VB (up to 6), C# and others all all languages that predated Go and Rust in memory safety, and came out in an era memory safety was de rigeur.
    - pjmlp 11y ago
- tedunangst 11y ago
  Go and Rust are the first two to emerge after decades of evidence. Other languages emerged during those decades. :)
amalcon 11y ago
It seems pretty straightforward to me. Rust fits into more or less the niche of C and C++: a low-level systems programming language with minimal runtime dependencies (no garbage collection, smallish standard library), which happen to also be useful properties for realtime and other perfromance-critical software. Go, on the other hand, fits more into Java's niche: an opinionated mid-level garbage collected language designed for application programming or mid-level systems stuff (i.e. web servers), with concurrency baked into the language design (though Go's concurrency design is much more to my liking than Java's).
- Hytosys 11y ago
  I mostly agree with your analysis. As someone who is doing web development in Rust, what should I fear of missing from a language like Go or Java? Is it just an ecosystem thing? Java is a more popular option for web server development over C++, but I don't know why.
  - jeffasinger 11y ago
    I think with C++ it is much easier to shoot yourself in the foot, but overall, I think it's probably mostly just ecosystem between the C++ and Java. Having tried both Rust and Go, I think I'd much prefer Go for simple web dev stuff because of all the ecosystem around it, but for most other things prefer rust.
    - _pmf_ 11y ago
      > I think with C++ it is much easier to shoot yourself in the foot property Go solves this by not allowing you to have a foot in the first place, instead encouraging you to walk on your hands and write blog posts elaborating why everybody should do this.
  - phn 11y ago
    Is Rust really suitable for web development? I am genuinely asking. For server development I think it might be a good choice, but for application code itself it seems like more of a pain to program in than an advantage.
ExpiredLink 11y ago
Two fringe languages are not competitors. Who would have thought it.
- coldtea 11y ago
  First, being fringe doesn't make you non-competitor automatically. Fringe language can and often DO compete for the same niche. Second, with support from most major shops, and being deployed even in companies such as Apple, Mozilla, Facebook and more, Go is hardly "fringe" at this moment.
  - rockdoe 11y ago
    What's the source for Apple, Mozilla (ok Facebook I'm less surprised) deploying Go?
    - mseepgood 11y ago
      http://www.golangprojects.com/golang-go-job-in-Senior-CDN-DevOps-Software-Engineer-Santa-Clara-Valley-Apple.html http://www.golangprojects.com/golang-go-job-in-Senior-CDN-De... http://daringfireball.net/linked/2015/05/06/applebot http://daringfireball.net/linked/2015/05/06/applebot https://blog.mozilla.org/services/2013/04/30/introducing-heka/ https://blog.mozilla.org/services/2013/04/30/introducing-hek...
    - brianm 11y ago
      Most prominent Mozilla Go usage is Heka ( https://github.com/mozilla-services/heka https://github.com/mozilla-services/heka ). I don't know about Apple, but knowing a number of folks in infra and ops there, and their tendencies, I do not doubt it is in use in places.
    - ifross 11y ago
      Apple have posts for go jobs: http://www.golangprojects.com/golang-go-job-in-Senior-CDN-DevOps-Software-Engineer-Santa-Clara-Valley-Apple.html http://www.golangprojects.com/golang-go-job-in-Senior-CDN-De... There is also some conjecture that someone at Apple is writing a web scraper in Go: https://news.ycombinator.com/item?id=8567205 https://news.ycombinator.com/item?id=8567205 Mozilla have a product called Heka written in Go: https://blog.mozilla.org/services/2013/04/30/introducing-heka/ https://blog.mozilla.org/services/2013/04/30/introducing-hek... Facebook have a load of open source libraries written in Go: https://github.com/facebookgo https://github.com/facebookgo
jasode 11y ago
Go and Rust competes in the narrow space of, "what's The Next Interesting Thing to learn?" In that narrow sense, it doesn't matter that the underlying semantics and runtimes of Go and Rust are targeted for different use cases. They get lumped together in the same conversation because people have a vague sense that something... (newer programming language, newer database engine, newer CSS templating, etc)... will make their project better. In that nebulous cloud of possible future benefits, it's understandable for people to mention both in the same conversation. However once people get past the unspecified idea of "better" and actually analyze (i.e. write concrete programs) the real costs & benefits, the differences of Go & Rust will reveal themselves. People will realize that Go is inappropriate to write a 60 fps graphics rendering engine and likewise, Rust is inappropriate to write quick scripts for Google-scale cloud orchestrations. One other reason that Go is mentioned along with Rust is that Google used the adjective "systems" to describe it. "Go is intended as a systems language". Unfortunately, a lot of folks didn't realize that Google was using an idiosyncratic definition of "systems" to mean a programming language to help the management of their datacenters. To others, "systems language" means writing operating systems, device drivers, embedded chips, etc. There was a nuance that got lost and it ended up muddying the discussion. The phrases, "Go is a systems language", and "Rust is a systems language" look the same but they mean different things.
- cwyers 11y ago
  No, they meant Go was intended as a systems language. Rob Pike: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 http://commandcenter.blogspot.com/2012/06/less-is-exponentia... > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. > We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care. Read the whole thing if you have time - Pike talks about how they were trying to write a language that filled a role similar to C and C++. So they came up with a compiled, statically typed language.
alexatkeplar 11y ago
> Go competes for mindshare [with those who] have lost patience with the high deployment costs of JVM based languages This is repeated so often, but I genuinely don't understand the underlying point. At Snowplow we have to deploy Scala, Java, JRuby and Go, amongst other things. Scala/Java: build a fatjar containing all dependencies using sbt-assembly, upload to Bintray and then deploy onto servers which have a recent JVM. JRuby: build a fatjar containing all dependencies using warble, upload to Bintray and then deploy onto servers which have a recent JVM. Go: build a binary containing all dependencies with godep for each relevant server architecture, upload to Bintray and then deploy onto servers. Yes, Go doesn't need a JVM installed, but on the flipside I have to build a version for each relevant server architecture. And then there's the software where I have to export GOMAXPROCS=`nproc` in a wrapper script...
- threeseed 11y ago
  Talking about deployment is ridiculous to me with languages that in most cases are going to be long running server side applications. How often are you going to install JVM/Ruby/Python ? Once. How often are you going to deploy ? Thousands. So the important part is how well the overall process works e.g dependency management, build scripts, automation, tooling etc.
  - kasey_junk 11y ago
    That makes an assumption about deployment. It assumes that you only provision a server once and you deploy many times. There are operational models where the provisioning of the server themselves is the deployment step.
- commentzorro 11y ago
  The JVM, CLR, Frameworks, Runtimes, app servers, configurations, etc. _ARE_ the problem. We're tired of all that crap all the time. Compile to an executable and xcopy the executable to an arbitrary server. Ideally, nothing to configure outside of the application itself. Go fits that bill nicely, but it's an annoyingly austere language. With all the languages in this last wave, I just don't know why nobody hit on a full featured Go level language yet. No memory management, not deployment dependencies, full of nice sugary high level abstractions, and cross platform Windows/Linux. Something solid and ready for production use, not an alpha or beta.
pjmlp 11y ago
Go is only a competitor for Java 1.0 like languages. It is not a competitor to Rust, because it lives in enterprise mindset of 90's language design. It is not a competitor to the JVM languages, because all of them are more feature rich and any knowledgeable JVM developer is aware there are plenty of options to deploy, including static binaries.
- kasey_junk 11y ago
  I have a lot of experience in the JVM and understand how to deploy, build, etc. JVM based solutions including those built on "next generation" JVM languages like Scala. Go absolutely is a competitor to that environment because writing web services across large teams is something Go has a compelling story around. This has been the domain of the JVM for a long time and many people have bad experiences with it (many people have good experiences as well I'd add).
  - aikah 11y ago
    > the JVM for a long time and many people have bad experiences with it And the only reason for this is that people don't have to maintain 15 yo Go code bases yet. But Go is verbose and will be a hell to maintain just like any other language that becomes 'enterprisey', just like big nodejs code bases, big rails code bases or big JEE code bases give people 'bad experiences'.
    - kasey_junk 11y ago
      I dont disagree at all. The one thing I would say might mitigate this, is that the golang community and leaders are very much rooted in the Unix philosophy of doing one thing well. They push back very hard on things that enable code bases to get big. Its possible that golang will simply not be viable in use cases that require big code bases, and therefore won't deal with those problems. Its also possible that over time the focus on keeping things small will drift, and golang will just be Java.
deleted 11y ago
[deleted]
Cshelton 11y ago
So I've written a few things in Rust, none in Go, but I've looked through Go's syntax. Everything that can be written in Go can be written in Rust. However, Go would be much more simpler for things, ie. right now, a web server. On the other end, some critical performance things or microprocessors, etc., written in Rust cannot be written in Go. They each have a purpose, and while there is some overlap, the purpose is very different. Go is geared more towards developer simplicity. Inevitably, Go will be a more popular language because of the simplicity. Similar to Ruby and Python. I also see Rust becoming a much more mature language that will take many C and c++ programmers over the next few years. It takes time, 1.0 was only released 7 weeks ago. In the end, I see both of these languages growing more and sticking around for awhile. Especially with large corporate backings (Google, Mozilla) and growing communities. I think I will probably learn both eventually.
mands 11y ago
I certainly see the need for Rust, a better, stricter and more modern C designed for low-level tasks where both performance and correctness matter, e.g. layout engines, game engines, OS kernels. On the other hand Go seems more suited to system/server tools where good-enough perfmance and quick startup matters more. I've noticed that people have been converting Python and Ruby code-bases to Go, and its use in system tools such as Docker, CoreOS, and Kuberentes. We're working in this area and have considered jumping on the bandwagon and rewriting our Python prototype in Go for the same reasons - performance, minimal runtime, strong ecosystem, some 'typing'. (Python made/makes sense atm as we're still very exploratory so doesn't get in our way). However upon investigation I was a bit disappointed with Go, although it has an incredible ecosystem and active community. Perhaps its simplicity is also an advantage although I found it counter-intuitive at times. However I can see why it found use in a way that 'better' (IMHO) tools such as OCaml were unable to. We're still undecided as to what to use when/if rewriting our code. Funnily enough I'm wondering if maybe C#/F# would work, now .NET has been open-sourced and has a native compiler. A good language/runtime, stronger type-system, lots of libraries, and potentially good performance with quick startup. I guess it would be quite amusing if MS's tooling ended up as the best way to write Linux system/server tools within those particular constraints.
jaegerpicker 11y ago
Yeah I think of go as an upgraded scripting language in a lot of ways. In a lot of ways I think go or scala are going to become the standard "oh crap we need to scale and preform better" web application languages. I think in most cases if I'm building a green field web application on the server side I'd be hard pressed to not choose go or scala at the beginning. Nearly as quick a development cycle and a MUCH better scaling story. Rust is too my a language aimed squarely at what I mentally model at tight loop applications, web browser engines, game engines, real time network servers etc... Go has amazing performance compared to python or ruby or even node.js but the GC is still too unpredictable to work well enough for those type of apps IMO.
copsarebastards 11y ago
Why are we still talking about this? Every language that's vaguely close to a multi-purpose language is a competitor with every other language. There are people who write websites in X86 assembler and people who write embedded systems in Python. Rust and Go are competitors. Yes, they were intended for different things, but who cares? Any reasonable metric of language success is going to show one language pulling numbers from the other. Pick your metric: users? There are plenty of people who aren't using Rust because they're using Go, and vice-versa. Successful projects? There are plenty of projects which aren't being written in Go because they're being written in Rust, and vice-versa. Reliability and safety? Maybe Go would have a reasonable type system if Rust hadn't snapped up so many of the good thinkers in that field. Arguing about whether languages are competing based on what they were intended for is a pointless argument: there's no metric for success, no way to validate who's right or wrong. Are we really going to spend time arguing over what Google devs meant when they used the word "systems"? Seriously?
BuckRogers 11y ago
Cheney sounds on the money to me. Even with this ending- "Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages." I agree. If you're a large company that has a lot of product which is backend webservices and you have huge amounts of Ruby, Python (dunno who has large amounts of Node, but that has to be sad)- then Go needs to be looked at pretty hard. While some of Go's deployment advantages are nullified a bit thanks to things like Docker and UbuntuCore, it's probably going to win on maintainability with large codebases over time with new programmers coming in the door over time. I wouldn't put up much argument against that. If running a business and the choice was a 500KLOC codebase in Python, Go or Java.. I'd prefer that is in Go. And no one starts out with 500KLOC, so the decision for a new business would need to be taken seriously from the start. It's cliche but if your problems match Google's, then Go is a great solution. I think Go will be and already is wildly successful in this domain. The killer feature that ensures this is the simplicity. I think anyone coming from any language could pickup one of the "simple is better" languages like Go. That's going to ensure the prophecy continues IMO. Doesn't mean I'm onboard as 1 guy. I wouldn't have a problem with doing it for a job though. It'd be on my short list of acceptable technologies I'd work with. Doxsey in his response though with his Go for everything stance, is a bit overzealous for me. I'd agree if it seemed right, but it doesn't seem right. I don't see it. Fortunately for Go, he doesn't have to be right. I think what I described as being Go's sweet spot in the industry will be more than enough. That religiosity reads as someone who's overly excited and maybe trying to keep Go in the news.

85 points by untothebreach 11y ago

>Rust and Go are both touted as memory safe. While this statement is absolutely true, both languages will not tolerate unsafe memory access, what is more important is that the world will not tolerate any new language which is not memory safe. It just so happens that Go and Rust are the first two languages to emerge after decades of evidence that in the real world, programmers as a whole, cannot safely manage memory manually. This is extremely misleading. Go and Rust are not at all "memory safe" in the same way. And Go and Rust the "first two languages" in this regard? Hardly. Rust maybe, because it uses a novel approach, but there's absolutely nothing special in Go's "memory safety" approach compared to Java (and Scala, Clojure), C#, D, Haskell, etc.

qznc 11y ago
It was Java which took non-manual memory management to the mainstream. Lisp takes credit for inventing garbage collection.
- yummyfajitas 11y ago
  Visual Basic was pretty mainstream before Java. As I recall, it had something along the lines of reference counting for memory management.
- pjmlp 11y ago
  Basic dialects and Clipper, just to cite two examples with reference counting. Smalltalk was also becoming mainstream before Java entered into the picture.
infogulch 11y ago
You took it the wrong way. Dave didn't say that Go's GC was special, of course garbage collectors have been around for decades. The key takeaway: > what is more important is that the world will not tolerate any new language which is not memory safe. Because of that, both Go and Rust, as a new languages, are not memory unsafe. Go's safety is boring, sure, but it's still a feature of the language. So both languages are memory safe in that they are not memory unsafe, big whoop. That's Dave's point. All new languages have this, and even though they're commonly compared with this metric, the metric itself is useless for new languages.
- gyre007 11y ago
  >Rust and Go are both touted as memory safe. While this statement is absolutely true Duh? >So both languages are memory safe in that they are not memory unsafe This is more accurate statement imo. Saying Go is memory safe [1] is like saying a lamb is safe among a heard of hungry lions. [1] http://www.pl-enthusiast.net/2014/07/21/memory-safety/ http://www.pl-enthusiast.net/2014/07/21/memory-safety/
  - infogulch 11y ago
    From that article, safe Go prevents: buffer overflow, use after free, use of uninitialized memory, illegal free, access to undefined memory. The only thing it misses is null pointer dereference. (OOM errors are not possible to prevent in turing-complete languages.) I don't agree with your analogy. A lamb among lions is clearly very unsafe, but Go isn't unsafe; you just agreed with me on this. Your analogy fits better to C/C++. The lamb could theoretically survive, but it's very unlikely; just as unlikely as a C/C++ program with no memory bugs.
    - gyre007 11y ago
      Yes I do generally agree with you. I went a bit overboard - somewhat HN pushes me over the edge sometimes :-( Lamb metaphore would not do Go the justice indeed. I do like Go, but also do not like some opinion which oversimplify reality.
- coldtea 11y ago
  Again, how are those "the first" after people stopped tolerating new unsafe languages? We hadn't had a new memory unsafe language catching on (or released from some major vendor) since what? C++? It was pretty much standard by the time Java was out. Heck, there were mainstream Smalltalk in the 90s, with IBM support, IDE's et al. So Smalltalk, Java, VB (up to 6), C# and others all all languages that predated Go and Rust in memory safety, and came out in an era memory safety was de rigeur.
  - pjmlp 11y ago
tedunangst 11y ago
Go and Rust are the first two to emerge after decades of evidence. Other languages emerged during those decades. :)

amalcon 11y ago

It seems pretty straightforward to me. Rust fits into more or less the niche of C and C++: a low-level systems programming language with minimal runtime dependencies (no garbage collection, smallish standard library), which happen to also be useful properties for realtime and other perfromance-critical software. Go, on the other hand, fits more into Java's niche: an opinionated mid-level garbage collected language designed for application programming or mid-level systems stuff (i.e. web servers), with concurrency baked into the language design (though Go's concurrency design is much more to my liking than Java's).

Hytosys 11y ago
I mostly agree with your analysis. As someone who is doing web development in Rust, what should I fear of missing from a language like Go or Java? Is it just an ecosystem thing? Java is a more popular option for web server development over C++, but I don't know why.
- jeffasinger 11y ago
  I think with C++ it is much easier to shoot yourself in the foot, but overall, I think it's probably mostly just ecosystem between the C++ and Java. Having tried both Rust and Go, I think I'd much prefer Go for simple web dev stuff because of all the ecosystem around it, but for most other things prefer rust.
  - _pmf_ 11y ago
    > I think with C++ it is much easier to shoot yourself in the foot property Go solves this by not allowing you to have a foot in the first place, instead encouraging you to walk on your hands and write blog posts elaborating why everybody should do this.
- phn 11y ago
  Is Rust really suitable for web development? I am genuinely asking. For server development I think it might be a good choice, but for application code itself it seems like more of a pain to program in than an advantage.

ExpiredLink 11y ago

Two fringe languages are not competitors. Who would have thought it.

coldtea 11y ago
First, being fringe doesn't make you non-competitor automatically. Fringe language can and often DO compete for the same niche. Second, with support from most major shops, and being deployed even in companies such as Apple, Mozilla, Facebook and more, Go is hardly "fringe" at this moment.
- rockdoe 11y ago
  What's the source for Apple, Mozilla (ok Facebook I'm less surprised) deploying Go?
  - mseepgood 11y ago
    http://www.golangprojects.com/golang-go-job-in-Senior-CDN-DevOps-Software-Engineer-Santa-Clara-Valley-Apple.html http://www.golangprojects.com/golang-go-job-in-Senior-CDN-De... http://daringfireball.net/linked/2015/05/06/applebot http://daringfireball.net/linked/2015/05/06/applebot https://blog.mozilla.org/services/2013/04/30/introducing-heka/ https://blog.mozilla.org/services/2013/04/30/introducing-hek...
  - brianm 11y ago
    Most prominent Mozilla Go usage is Heka ( https://github.com/mozilla-services/heka https://github.com/mozilla-services/heka ). I don't know about Apple, but knowing a number of folks in infra and ops there, and their tendencies, I do not doubt it is in use in places.
  - ifross 11y ago
    Apple have posts for go jobs: http://www.golangprojects.com/golang-go-job-in-Senior-CDN-DevOps-Software-Engineer-Santa-Clara-Valley-Apple.html http://www.golangprojects.com/golang-go-job-in-Senior-CDN-De... There is also some conjecture that someone at Apple is writing a web scraper in Go: https://news.ycombinator.com/item?id=8567205 https://news.ycombinator.com/item?id=8567205 Mozilla have a product called Heka written in Go: https://blog.mozilla.org/services/2013/04/30/introducing-heka/ https://blog.mozilla.org/services/2013/04/30/introducing-hek... Facebook have a load of open source libraries written in Go: https://github.com/facebookgo https://github.com/facebookgo

jasode 11y ago

Go and Rust competes in the narrow space of, "what's The Next Interesting Thing to learn?" In that narrow sense, it doesn't matter that the underlying semantics and runtimes of Go and Rust are targeted for different use cases. They get lumped together in the same conversation because people have a vague sense that something... (newer programming language, newer database engine, newer CSS templating, etc)... will make their project better. In that nebulous cloud of possible future benefits, it's understandable for people to mention both in the same conversation. However once people get past the unspecified idea of "better" and actually analyze (i.e. write concrete programs) the real costs & benefits, the differences of Go & Rust will reveal themselves. People will realize that Go is inappropriate to write a 60 fps graphics rendering engine and likewise, Rust is inappropriate to write quick scripts for Google-scale cloud orchestrations. One other reason that Go is mentioned along with Rust is that Google used the adjective "systems" to describe it. "Go is intended as a systems language". Unfortunately, a lot of folks didn't realize that Google was using an idiosyncratic definition of "systems" to mean a programming language to help the management of their datacenters. To others, "systems language" means writing operating systems, device drivers, embedded chips, etc. There was a nuance that got lost and it ended up muddying the discussion. The phrases, "Go is a systems language", and "Rust is a systems language" look the same but they mean different things.

cwyers 11y ago
No, they meant Go was intended as a systems language. Rob Pike: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 http://commandcenter.blogspot.com/2012/06/less-is-exponentia... > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. > We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care. Read the whole thing if you have time - Pike talks about how they were trying to write a language that filled a role similar to C and C++. So they came up with a compiled, statically typed language.

alexatkeplar 11y ago

> Go competes for mindshare [with those who] have lost patience with the high deployment costs of JVM based languages This is repeated so often, but I genuinely don't understand the underlying point. At Snowplow we have to deploy Scala, Java, JRuby and Go, amongst other things. Scala/Java: build a fatjar containing all dependencies using sbt-assembly, upload to Bintray and then deploy onto servers which have a recent JVM. JRuby: build a fatjar containing all dependencies using warble, upload to Bintray and then deploy onto servers which have a recent JVM. Go: build a binary containing all dependencies with godep for each relevant server architecture, upload to Bintray and then deploy onto servers. Yes, Go doesn't need a JVM installed, but on the flipside I have to build a version for each relevant server architecture. And then there's the software where I have to export GOMAXPROCS=`nproc` in a wrapper script...

threeseed 11y ago
Talking about deployment is ridiculous to me with languages that in most cases are going to be long running server side applications. How often are you going to install JVM/Ruby/Python ? Once. How often are you going to deploy ? Thousands. So the important part is how well the overall process works e.g dependency management, build scripts, automation, tooling etc.
- kasey_junk 11y ago
  That makes an assumption about deployment. It assumes that you only provision a server once and you deploy many times. There are operational models where the provisioning of the server themselves is the deployment step.
commentzorro 11y ago
The JVM, CLR, Frameworks, Runtimes, app servers, configurations, etc. _ARE_ the problem. We're tired of all that crap all the time. Compile to an executable and xcopy the executable to an arbitrary server. Ideally, nothing to configure outside of the application itself. Go fits that bill nicely, but it's an annoyingly austere language. With all the languages in this last wave, I just don't know why nobody hit on a full featured Go level language yet. No memory management, not deployment dependencies, full of nice sugary high level abstractions, and cross platform Windows/Linux. Something solid and ready for production use, not an alpha or beta.

pjmlp 11y ago

Go is only a competitor for Java 1.0 like languages. It is not a competitor to Rust, because it lives in enterprise mindset of 90's language design. It is not a competitor to the JVM languages, because all of them are more feature rich and any knowledgeable JVM developer is aware there are plenty of options to deploy, including static binaries.

kasey_junk 11y ago
I have a lot of experience in the JVM and understand how to deploy, build, etc. JVM based solutions including those built on "next generation" JVM languages like Scala. Go absolutely is a competitor to that environment because writing web services across large teams is something Go has a compelling story around. This has been the domain of the JVM for a long time and many people have bad experiences with it (many people have good experiences as well I'd add).
- aikah 11y ago
  > the JVM for a long time and many people have bad experiences with it And the only reason for this is that people don't have to maintain 15 yo Go code bases yet. But Go is verbose and will be a hell to maintain just like any other language that becomes 'enterprisey', just like big nodejs code bases, big rails code bases or big JEE code bases give people 'bad experiences'.
  - kasey_junk 11y ago
    I dont disagree at all. The one thing I would say might mitigate this, is that the golang community and leaders are very much rooted in the Unix philosophy of doing one thing well. They push back very hard on things that enable code bases to get big. Its possible that golang will simply not be viable in use cases that require big code bases, and therefore won't deal with those problems. Its also possible that over time the focus on keeping things small will drift, and golang will just be Java.

deleted 11y ago

[deleted]

Cshelton 11y ago

So I've written a few things in Rust, none in Go, but I've looked through Go's syntax. Everything that can be written in Go can be written in Rust. However, Go would be much more simpler for things, ie. right now, a web server. On the other end, some critical performance things or microprocessors, etc., written in Rust cannot be written in Go. They each have a purpose, and while there is some overlap, the purpose is very different. Go is geared more towards developer simplicity. Inevitably, Go will be a more popular language because of the simplicity. Similar to Ruby and Python. I also see Rust becoming a much more mature language that will take many C and c++ programmers over the next few years. It takes time, 1.0 was only released 7 weeks ago. In the end, I see both of these languages growing more and sticking around for awhile. Especially with large corporate backings (Google, Mozilla) and growing communities. I think I will probably learn both eventually.

mands 11y ago

I certainly see the need for Rust, a better, stricter and more modern C designed for low-level tasks where both performance and correctness matter, e.g. layout engines, game engines, OS kernels. On the other hand Go seems more suited to system/server tools where good-enough perfmance and quick startup matters more. I've noticed that people have been converting Python and Ruby code-bases to Go, and its use in system tools such as Docker, CoreOS, and Kuberentes. We're working in this area and have considered jumping on the bandwagon and rewriting our Python prototype in Go for the same reasons - performance, minimal runtime, strong ecosystem, some 'typing'. (Python made/makes sense atm as we're still very exploratory so doesn't get in our way). However upon investigation I was a bit disappointed with Go, although it has an incredible ecosystem and active community. Perhaps its simplicity is also an advantage although I found it counter-intuitive at times. However I can see why it found use in a way that 'better' (IMHO) tools such as OCaml were unable to. We're still undecided as to what to use when/if rewriting our code. Funnily enough I'm wondering if maybe C#/F# would work, now .NET has been open-sourced and has a native compiler. A good language/runtime, stronger type-system, lots of libraries, and potentially good performance with quick startup. I guess it would be quite amusing if MS's tooling ended up as the best way to write Linux system/server tools within those particular constraints.

jaegerpicker 11y ago

Yeah I think of go as an upgraded scripting language in a lot of ways. In a lot of ways I think go or scala are going to become the standard "oh crap we need to scale and preform better" web application languages. I think in most cases if I'm building a green field web application on the server side I'd be hard pressed to not choose go or scala at the beginning. Nearly as quick a development cycle and a MUCH better scaling story. Rust is too my a language aimed squarely at what I mentally model at tight loop applications, web browser engines, game engines, real time network servers etc... Go has amazing performance compared to python or ruby or even node.js but the GC is still too unpredictable to work well enough for those type of apps IMO.

copsarebastards 11y ago

Why are we still talking about this? Every language that's vaguely close to a multi-purpose language is a competitor with every other language. There are people who write websites in X86 assembler and people who write embedded systems in Python. Rust and Go are competitors. Yes, they were intended for different things, but who cares? Any reasonable metric of language success is going to show one language pulling numbers from the other. Pick your metric: users? There are plenty of people who aren't using Rust because they're using Go, and vice-versa. Successful projects? There are plenty of projects which aren't being written in Go because they're being written in Rust, and vice-versa. Reliability and safety? Maybe Go would have a reasonable type system if Rust hadn't snapped up so many of the good thinkers in that field. Arguing about whether languages are competing based on what they were intended for is a pointless argument: there's no metric for success, no way to validate who's right or wrong. Are we really going to spend time arguing over what Google devs meant when they used the word "systems"? Seriously?

BuckRogers 11y ago

Cheney sounds on the money to me. Even with this ending- "Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages." I agree. If you're a large company that has a lot of product which is backend webservices and you have huge amounts of Ruby, Python (dunno who has large amounts of Node, but that has to be sad)- then Go needs to be looked at pretty hard. While some of Go's deployment advantages are nullified a bit thanks to things like Docker and UbuntuCore, it's probably going to win on maintainability with large codebases over time with new programmers coming in the door over time. I wouldn't put up much argument against that. If running a business and the choice was a 500KLOC codebase in Python, Go or Java.. I'd prefer that is in Go. And no one starts out with 500KLOC, so the decision for a new business would need to be taken seriously from the start. It's cliche but if your problems match Google's, then Go is a great solution. I think Go will be and already is wildly successful in this domain. The killer feature that ensures this is the simplicity. I think anyone coming from any language could pickup one of the "simple is better" languages like Go. That's going to ensure the prophecy continues IMO. Doesn't mean I'm onboard as 1 guy. I wouldn't have a problem with doing it for a job though. It'd be on my short list of acceptable technologies I'd work with. Doxsey in his response though with his Go for everything stance, is a bit overzealous for me. I'd agree if it seemed right, but it doesn't seem right. I don't see it. Fortunately for Go, he doesn't have to be right. I think what I described as being Go's sweet spot in the industry will be more than enough. That religiosity reads as someone who's overly excited and maybe trying to keep Go in the news.