4 ms·

The problem with rust is that it has been around for nearly as long as Go, yet is nowhere near stable or production ready in nearly every aspect. Go has been r

The problem with rust is that it has been around for nearly as long as Go, yet is nowhere near stable or production ready in nearly every aspect. Go has been ready for years.

arthursilva 12y ago
Well, once you compare both languages you can see why. Hint: inovation/complexity (not that either is a good or bad thing). Anyway, that's only one possible reason... I think Go is actually 2 years older.
- andrewchambers 12y ago
  Go hasn't changed much from its initial versions, iirc rust is unrecognizable compared to early versions. Rust didn't know what it wanted to be from the start. I wanted to give rust a crack years ago, but I am glad I didn't because it would have required constant updates for anything serious.
  - dbaupp 12y ago
    Go hasn't changed much from its initial released version, or initial internal version? As I understand it, Go was released in a much more final state, whereas Rust was developed in the open from very very early. Rust has always known what it wanted to be, it has just taken a while to find the best way to actually fill that goal. That isn't really a fundamental problem with the language (in fact, I see the constant iteration and change as a good thing: the language was developed empirically, removing features that didn't work/pull their weight, adding ones that did), although it is definitely a good reason for people to have not used Rust historically. In any case, this discussion seems like a non-sequitur: whether Go is boring to hanlec or not is orthogonal to whether Go is more stable than Rust or not. The fact that a language has been stable for years rather than only just now approaching stability might be something you value highly, but clearly hanlec has a different utility function.
    - andrewchambers 12y ago
      Go hasn't changed much, because it is the natural extension of plan9 C and other languages from the past. If you look at the project layout of the plan9 source tree, it matches the Go project layout now. I think plan9 C even used CSP channels in the form of a C library for most of the servers. They just took what they already knew worked, and tried to polish it and add garbage collection. Rust is trying many things at once then letting things die off as they prove useless.
      - dbaupp 12y ago
        > Rust is trying many things at once then letting things die off as they prove useless. Yes, this is perfectly true. I cannot tell from your phrasing whether you think experimentation, learning from experience and removal of pointless code is good or bad. I personally think all of those are good, but you're perfectly entitled to differ. Go was designed with the lessons learned and experienced gained from plan9, Rust was designed with the lessons learned and experienced gained from iterating on Rust itself. Seems pretty similar. :)
        andrewchambers 12y ago
        You are right on all counts. I think experimentation is a good thing, I don't know if I want to be the guinea pig though.
oldmanjay 12y ago
of course, if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way, go isn't ready at all. it does have some marquee names behind it, though. I suppose if you squint, that can make up the difference.
- andrewchambers 12y ago
  Go performance is going to converge on C performance with new optimization's being written after go 1.5. Any gains from rusts expressive type system are lost by all the memory lifetime annotations imo. I still think rust is probably going to be the best language for embedded software like router firmware, as they need to be fast, low overhead and secure.
  - seanmcdirmid 12y ago
    As an upper performance bound for a GC language, I don't think Go will be able to surpass C# (which has stack allocation in the form of structs, ahead of time compilation, and many other goodies). Rust, on the other hand, has more potential as a non GC language, though at the end of the day it might be hard to tell given equivalent applications.
    - andrewchambers 12y ago
      The upper performance for garbage collected languages (and rust) is potentially higher than C. The reasons are non aliased pointers allow more aggressive optimization, and batched garbage collection plus memory compaction can perform better than regular mallocs. Rust still has these advantages though, time will tell. Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.
      - kibwen 12y ago
        Rust essentially never wastes cycles on bounds checking thanks to the design of its iterators. The Servo team tells me that bounds checking has never shown up in any performance profiles.
kibwen 12y ago
Rob Pike has been working on Go's design since Newsqueak in the 90s, and further explored the same space later with Limbo. For reference, Newsqueak is a C-inspired language that features CSP for concurrency (which should sound familiar to Go programmers). Here's some example syntax (which should look familiar to Go programmers): a := mk(array[10] of int) Given this lineage, it seems disingenuous to compare the ages of the two languages. Modern Rust is to early Rust as Go is to Newsqueak.
- andrewchambers 12y ago
  This is true, but it does confirm my point about language flux potentially being a problem. It may work out nicely though.
  - kibwen 12y ago
    Indeed, it may ultimately turn out that modern Rust is to early Rust as Limbo (rather than Go) is to Newsqueak. I expect Rust will experience growing pains over the next few years as people begin employing it on an industrial scale and discover where the dark corners of the language lie. But nobody's saying that Rust will be the last systems programming language to ever be written. :)
tatterdemalion 12y ago
This comment is very strange. Go was made public when it was stable (or maybe shortly before?), Rust was made public long before it was. Rust will be stable in 4 weeks, Go was stable several years ago. So what? If we judged languages by how early they were stable, we would all be writing Fortran 57, Algol 58, and COBOL 60.
- andrewchambers 12y ago
  I'm not judging the language, I'm just warning people to be careful in choosing to build a product with it. The team still seems to be changing stuff like crazy even after the "stable beta" release.
  - dbaupp 12y ago
    I think you have the wrong impression about the recent changes, e.g. a recent "regression report"[1] found only two regressions between nightly and the original released beta. Furthermore, several changes have been rejected due to being breaking. The team is seriously committed to stability. [1]: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015...
    - andrewchambers 12y ago
      You can be sure if more people used rust, there would be many more detected breakages. The undetected ones are more worrying. I get that the language is a beta, but be warned. One example I saw - http://internals.rust-lang.org/t/memcpy-is-backwards/1797 http://internals.rust-lang.org/t/memcpy-is-backwards/1797
      - dbaupp 12y ago
        Breaks during beta that are not detected seem fine to me: people were not using the feature, and the improvement/bug fix could land without issue. That particular change caused heartache, yes, but it was purposely made before the beta release, exactly because it was breaking.

The problem with rust is that it has been around for nearly as long as Go, yet is nowhere near stable or production ready in nearly every aspect. Go has been ready for years.

arthursilva 12y ago

Well, once you compare both languages you can see why. Hint: inovation/complexity (not that either is a good or bad thing). Anyway, that's only one possible reason... I think Go is actually 2 years older.

andrewchambers 12y ago
Go hasn't changed much from its initial versions, iirc rust is unrecognizable compared to early versions. Rust didn't know what it wanted to be from the start. I wanted to give rust a crack years ago, but I am glad I didn't because it would have required constant updates for anything serious.
- dbaupp 12y ago
  Go hasn't changed much from its initial released version, or initial internal version? As I understand it, Go was released in a much more final state, whereas Rust was developed in the open from very very early. Rust has always known what it wanted to be, it has just taken a while to find the best way to actually fill that goal. That isn't really a fundamental problem with the language (in fact, I see the constant iteration and change as a good thing: the language was developed empirically, removing features that didn't work/pull their weight, adding ones that did), although it is definitely a good reason for people to have not used Rust historically. In any case, this discussion seems like a non-sequitur: whether Go is boring to hanlec or not is orthogonal to whether Go is more stable than Rust or not. The fact that a language has been stable for years rather than only just now approaching stability might be something you value highly, but clearly hanlec has a different utility function.
  - andrewchambers 12y ago
    Go hasn't changed much, because it is the natural extension of plan9 C and other languages from the past. If you look at the project layout of the plan9 source tree, it matches the Go project layout now. I think plan9 C even used CSP channels in the form of a C library for most of the servers. They just took what they already knew worked, and tried to polish it and add garbage collection. Rust is trying many things at once then letting things die off as they prove useless.
    - dbaupp 12y ago
      > Rust is trying many things at once then letting things die off as they prove useless. Yes, this is perfectly true. I cannot tell from your phrasing whether you think experimentation, learning from experience and removal of pointless code is good or bad. I personally think all of those are good, but you're perfectly entitled to differ. Go was designed with the lessons learned and experienced gained from plan9, Rust was designed with the lessons learned and experienced gained from iterating on Rust itself. Seems pretty similar. :)
      - andrewchambers 12y ago
        You are right on all counts. I think experimentation is a good thing, I don't know if I want to be the guinea pig though.

oldmanjay 12y ago

of course, if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way, go isn't ready at all. it does have some marquee names behind it, though. I suppose if you squint, that can make up the difference.

andrewchambers 12y ago
Go performance is going to converge on C performance with new optimization's being written after go 1.5. Any gains from rusts expressive type system are lost by all the memory lifetime annotations imo. I still think rust is probably going to be the best language for embedded software like router firmware, as they need to be fast, low overhead and secure.
- seanmcdirmid 12y ago
  As an upper performance bound for a GC language, I don't think Go will be able to surpass C# (which has stack allocation in the form of structs, ahead of time compilation, and many other goodies). Rust, on the other hand, has more potential as a non GC language, though at the end of the day it might be hard to tell given equivalent applications.
  - andrewchambers 12y ago
    The upper performance for garbage collected languages (and rust) is potentially higher than C. The reasons are non aliased pointers allow more aggressive optimization, and batched garbage collection plus memory compaction can perform better than regular mallocs. Rust still has these advantages though, time will tell. Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.
    - kibwen 12y ago
      Rust essentially never wastes cycles on bounds checking thanks to the design of its iterators. The Servo team tells me that bounds checking has never shown up in any performance profiles.

kibwen 12y ago

Rob Pike has been working on Go's design since Newsqueak in the 90s, and further explored the same space later with Limbo. For reference, Newsqueak is a C-inspired language that features CSP for concurrency (which should sound familiar to Go programmers). Here's some example syntax (which should look familiar to Go programmers): a := mk(array[10] of int) Given this lineage, it seems disingenuous to compare the ages of the two languages. Modern Rust is to early Rust as Go is to Newsqueak.

andrewchambers 12y ago
This is true, but it does confirm my point about language flux potentially being a problem. It may work out nicely though.
- kibwen 12y ago
  Indeed, it may ultimately turn out that modern Rust is to early Rust as Limbo (rather than Go) is to Newsqueak. I expect Rust will experience growing pains over the next few years as people begin employing it on an industrial scale and discover where the dark corners of the language lie. But nobody's saying that Rust will be the last systems programming language to ever be written. :)

tatterdemalion 12y ago

This comment is very strange. Go was made public when it was stable (or maybe shortly before?), Rust was made public long before it was. Rust will be stable in 4 weeks, Go was stable several years ago. So what? If we judged languages by how early they were stable, we would all be writing Fortran 57, Algol 58, and COBOL 60.

andrewchambers 12y ago
I'm not judging the language, I'm just warning people to be careful in choosing to build a product with it. The team still seems to be changing stuff like crazy even after the "stable beta" release.
- dbaupp 12y ago
  I think you have the wrong impression about the recent changes, e.g. a recent "regression report"[1] found only two regressions between nightly and the original released beta. Furthermore, several changes have been rejected due to being breaking. The team is seriously committed to stability. [1]: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015...
  - andrewchambers 12y ago
    You can be sure if more people used rust, there would be many more detected breakages. The undetected ones are more worrying. I get that the language is a beta, but be warned. One example I saw - http://internals.rust-lang.org/t/memcpy-is-backwards/1797 http://internals.rust-lang.org/t/memcpy-is-backwards/1797
    - dbaupp 12y ago
      Breaks during beta that are not detected seem fine to me: people were not using the feature, and the improvement/bug fix could land without issue. That particular change caused heartache, yes, but it was purposely made before the beta release, exactly because it was breaking.