9 ms·

This is only tangentially related to the article, but why does any discussion of Rust and/or Go asymptotically approach "RUST VERSUS GO RUST VERSUS GO", or at l

This is only tangentially related to the article, but why does any discussion of Rust and/or Go asymptotically approach "RUST VERSUS GO RUST VERSUS GO", or at least have everyone and their grandma chip in on which one they prefer (like this very post)? I'll admit that I only have experience with the former, but they seem like totally different beasts to me, intended for very different domains / target audiences. I figured that the holy war would be between Rust and the other trendy systems languages (Nim, Zig, Crystal) or between Go and other Web-oriented / glue languages (Java, Python, Perl, et cetera).

deleted 7y ago
[deleted]
lmkg 7y ago
It's an accident of history and messaging. They were both publicly announced at the same time, and both described themselves as "systems programming languages." As it turns out, the two languages have entirely different ideas of what "systems programming" means. And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Still, the initial contrast seems to have stuck. The only real overlap is that both deign to be C successors. But in such different ways that the head-to-head comparisons make little sense. There's also the perception that they're the only recently-created languages that have gained any real traction. You don't see nearly the ink spilt on Nim or Zig as you do on Rust or Go. So there's maybe some sibling rivalry there. (In this vein, I occasionally see comparisons of Rust vs Swift.)
- steveklabnik 7y ago
  While there's a lot of truth in this comment, at the same time, the domains are wide enough that there are a lot of similar usages, and teams that decide to use one, the other, or both.
  - umanwizard 7y ago
    True, but you could say the same of nearly any pair of general-purpose languages. Even Python and C overlap to some non-trivial extent. Go and Rust certainly have overlap, but I'm not sure I'd agree that they have an unusually high level of overlap. I think the closest language to Rust in niche is, by far, C++. I'm surprised to see it compared less often to that than to Go.
    - snazz 7y ago
      I think the reason that C++ and Rust are compared less often is because the advantages and disadvantages of each are clearer. Rust has better memory safety and concurrency, is less focused on backwards compatibility and so doesn't bring a lot of cruft along, and so on. Of course, its ecosystem is far less mature and there are situations where backwards compatibility is paramount.
      - throwaway17_17 7y ago
        The advantages and disadvantages of the two may be clearer, but Rust is clearly most similar to C++ from a complexity and usage domain view. I don’t see why this is not the only discussion on ‘Rust vs’. The same arguments against C++ being compared to C are almost directly applicable to arguments comparing Rust to C, and the same goes when comparing against higher level languages. I get that Rust has its borrowing/ownership semantics and a ML inspired type system, but Rust and C++ are more readily comparable than almost any other languages in general usage.
- yeah2 7y ago
  I'd say it's in part because Go originated at Google and Rust originated at Mozilla. Two browser vendors announcing new languages at the height of the browser wars caused the languages to attract the same tribalism.
  - throwaway894345 7y ago
    I don't think the tribalism is even really in the language communities themselves as much as it is among onlookers, casual users, or otherwise fans of either language. (Note that there is certainly plenty of enthusiasm for each language in its respective community). Rust in particular seems to have a large following of people who aspire to use it but haven't really learned it or used it in anger (this especially used to be the case). Basically they (like me) appreciate the ideas of strong static guarantees, strong performance characteristics, and the general aesthetic of Rust code compared to other high-performance languages or other "functional languages". But those people (and to a lesser extent, many in the Rust community proper) tend to believe that Rust is optimal for those use cases that are conventionally considered to be Go's purview, which is to say they believe Rust is more productive than Go, Python, Ruby, Java, etc for the sorts of applications that those languages are regularly used for (SaaS application backends and other network services). They argue that you just need a little more experience with Rust and you will hit some productivity nirvana; however, each year, I (and many others with experience in this domain) get another year of experience with Rust (as a hobbyist--not full-time development) and still I'm far more productive in Python and Go than I am with Rust. And I don't think the "just need a little more experience" argument holds water. It's based on the idea that the borrow checker and memory management in general become progressively more natural. Well, I have a decade of C and C++ experience and manual memory management is very natural (almost said "super natural") to me, and the trend is asymptotic--with more experience you do indeed get better with the borrow checker and memory management, but it never quite reaches the point where it's in the same ballpark as a garbage collector (where you truly don't need to think about memory management outside of hot spots). Of course, GC languages also don't help you deal with race conditions, but 99% of the code we write in these domains isn't subject to race conditions (and if you are writing something that is pervasively subject to race conditions, it might well be worth considering Rust). Note that there are a handful of very smart, well-respected (and deservedly so) people who also have lots of experience with Rust and who are familiar with the domain in question who disagree with me. I think theirs is the niche opinion, but I think it's worth hearing them out and forming your own opinion.
- znpy 7y ago
  > both described themselves as "systems programming languages." IIRC Rob Pike later commented that Go should have been advertised more like a "network services programming language" as it is better suited for writing network services than to write low-level components (os kernels, device drivers, embedded programs).
- cwzwarich 7y ago
  > And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Back when Rust was announced, it was much more similar to Go than it is now, even having a similar runtime for concurrency. Go did a better job than Rust of delivering this paradigm, largely because the Go implementors weren't relying on commodity technologies like LLVM and libuv. As time went on, Rust was given more support by Mozilla, and it evolved into something more suited for browser implementation. It had other major influences at this point: - The constraints of using LLVM. Many projects have failed trying to make LLVM do something that it's bad at doing. At the end of the day, LLVM is good at compiling C++ and things that look like C++, so if you stick to using LLVM and want an efficient language, your language will end up looking more like C++ over time. - The swell of momentum around C++11. All of a sudden, programming idioms from the "Modern C++" movement were becoming mainstream. - The halo of academic research into type-safe systems languages. Very few of the ideas in Rust are new, but some type system features from academia became more palatable for ordinary programmers when combined with the C++11 style.
  - throwaway894345 7y ago
    I've heard this about LLVM a lot in the past; does LLVM recognize its C++-centricity as a problem in delivering on its mission of being a multilingual target platform, or has it tacitly changed its mission to be more-or-less implicitly C++-centric? And specifically, what sway does Rust hold on the LLVM project and its goals?
    - swsieber 7y ago
      I would say it's mostly incidental - c++ like things are its biggest use case and get the most feedback.
    - cwzwarich 7y ago
      > does LLVM recognize its C++-centricity as a problem in delivering on its mission of being a multilingual target platform, or has it tacitly changed its mission to be more-or-less implicitly C++-centric? LLVM is a mostly corporate-sponsored open source project. There isn't really a global LLVM roadmap, and developers usually work on things that help their employers. There has rarely been explicit opposition to features that help other languages, but at the same time it is very difficult to make a large nontrivial change to LLVM at this point. Someone who is not already an active LLVM developer might be overwhelmed and give up on upstreaming their changes. IMO the most successful use of LLVM for a sufficiently non-C++ language has been Azul's work on last-tier JIT compilation using LLVM: https://llvm.org/devmtg/2017-10/#talk12 https://llvm.org/devmtg/2017-10/#talk12 > And specifically, what sway does Rust hold on the LLVM project and its goals? As far as I can tell (and this may be a bit out-of-date), basically none.
- dagmx 7y ago
  Rust and Swift though do have a very close relationship IMHO. They have similar design decisions for ergonomics, and often borrow (no pun intended) from each other. Not to mention Graydon worked on both.
- reacharavindh 7y ago
  Learning Go and Rust recently, it feels like Go is aiming to be a better Java(GC, excellent libraries, feature rich std library, fast enough but easier on devs) and Rust is aiming to be a safer C.
  - neutronicus 7y ago
    I'd say C++ is a closer point of comparison.
  - dralley 7y ago
    D is aiming to be a better C++ Rust is aiming to be a better and safer C++ Zig is aiming to be a better C
    - pron 7y ago
      Zig has a good safety story -- in fact, I think it might turn out to better than Rust's -- but it is very different. A language that uses sound methods to guarantee certain kinds of safety (as Rust does) is not necessarily the best way, and it certainly isn't the only way, to write safe code. The handwavy way to explain that is that a language that soundness comes at a cost, and getting rid of 100% of a certain class of bugs might overall be less safe than an approach that gets rid of, say, 98% of that class and can also help reduce bugs outside that class by similar unsound means. I.e. system safety and memory safety are very much not the same thing (although the former is a subset of the latter), and since the goal is system safety, it is unclear exactly how much it is worth paying to soundly eliminate all memory safety bugs.
      - throwaway17_17 7y ago
        I agree with the premise that there are multiple measurements for ‘safety’ and I absolutely do not believe Rust’s chosen method is superior to all others, but I’ve seen you get blow back in other threads for these statements before, so I thought I’d toss in some support of the overarching ideas before the long meeting of response come flying in.
  - 7y ago
hu3 7y ago
Indeed, Rust and Go are different beasts with different target audiences. I see it mostly as a debate between correctedness vs pragmatism. Granted these traits can be orthogonal but often aren't.
pjmlp 7y ago
Depends on where one is coming from. For example, while I do find quite interesting what Rust developers have managed to do with linear types, to the point that they have influenced language designers from D, Swift, C++, Haskell, OCaml to find ways to adopt them into their language designs, if Go community would be more welcomed to modern language design, that would be enough for my use cases. As I am a firm believer, that even it takes beyond my lifetime, all modern OSes will eventually be like Mesa/Cedar, Oberon, Singularity, Midori,.... By the way, Java is not a Web / glue language, there are plenty of embedded bare metal deployments using it, e.g. PTC, Aicas, IBM, Gemalto, Kyocera, Ricoh, all have offerings in that regard. If you want examples for systems programing in Go have a look at Android's GPU debugger, gVisor hypervisor, F-Secure USB key, TinyGo for micro-controllers, or its boostraped compiler.
deleted 7y ago
[deleted]
mamcx 7y ago
You must also take account that people not always look at a language per by their MOST perfect domain fit. For me, and probably many I look in the rust sphere(and go and swift and F# where I also have worked), this langs are not picked because "I need bare-metal baby!" but "I need something a bit faster/easier to deploy/less resource/less crazy intensive than obj-c/python/ruby/js/php". I have picked all 4 (rust, f#, go and swift) because that, because all (except go) have AGDTs and pattern matching (and go only because I need some utilities easier to cross compile FAST) and that is all. ALSO because are langs FRIENDLY to solo(me!)/small teams of developers. Even If i must pick a "system language" I will NEVER pick C++, too much complexity. That is why I pick F# vs C# (F# is more economic in lines of code, more expressive and overall simpler), Swift as fast I as could (vs obj-c) and Pascal over C/C++ in the old days. Looking this way, them intersect much more than most imagine.
- niclo 7y ago
  May I ask how you experience with F# was and how you used it ? I'm slowly learning it but I'm not 100% sure to keep going, maybe switch to other similar languages with bigger communities/bigger market demand
  - mamcx 7y ago
    I use C# a lot before and think F# is a good alternative. I use for ERP-like app development with web backend, CLIs, mobile all done on OSX. I move now to Rust (for long term bets I made) but think F#/.NET Core is a great toolset in itself.
bcrosby95 7y ago
Many companies standardize on a couple languages. For companies like that, Go and Rust might occupy the same sphere of influence.
sacado2 7y ago
They have very different design philosophies and were announced more or less at the same time, that's why people always compare them and feel like they have to pick a winner, despite them targeting very different niches.

deleted 7y ago

[deleted]

lmkg 7y ago

It's an accident of history and messaging. They were both publicly announced at the same time, and both described themselves as "systems programming languages." As it turns out, the two languages have entirely different ideas of what "systems programming" means. And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Still, the initial contrast seems to have stuck. The only real overlap is that both deign to be C successors. But in such different ways that the head-to-head comparisons make little sense. There's also the perception that they're the only recently-created languages that have gained any real traction. You don't see nearly the ink spilt on Nim or Zig as you do on Rust or Go. So there's maybe some sibling rivalry there. (In this vein, I occasionally see comparisons of Rust vs Swift.)

steveklabnik 7y ago
While there's a lot of truth in this comment, at the same time, the domains are wide enough that there are a lot of similar usages, and teams that decide to use one, the other, or both.
- umanwizard 7y ago
  True, but you could say the same of nearly any pair of general-purpose languages. Even Python and C overlap to some non-trivial extent. Go and Rust certainly have overlap, but I'm not sure I'd agree that they have an unusually high level of overlap. I think the closest language to Rust in niche is, by far, C++. I'm surprised to see it compared less often to that than to Go.
  - snazz 7y ago
    I think the reason that C++ and Rust are compared less often is because the advantages and disadvantages of each are clearer. Rust has better memory safety and concurrency, is less focused on backwards compatibility and so doesn't bring a lot of cruft along, and so on. Of course, its ecosystem is far less mature and there are situations where backwards compatibility is paramount.
    - throwaway17_17 7y ago
      The advantages and disadvantages of the two may be clearer, but Rust is clearly most similar to C++ from a complexity and usage domain view. I don’t see why this is not the only discussion on ‘Rust vs’. The same arguments against C++ being compared to C are almost directly applicable to arguments comparing Rust to C, and the same goes when comparing against higher level languages. I get that Rust has its borrowing/ownership semantics and a ML inspired type system, but Rust and C++ are more readily comparable than almost any other languages in general usage.
yeah2 7y ago
I'd say it's in part because Go originated at Google and Rust originated at Mozilla. Two browser vendors announcing new languages at the height of the browser wars caused the languages to attract the same tribalism.
- throwaway894345 7y ago
  I don't think the tribalism is even really in the language communities themselves as much as it is among onlookers, casual users, or otherwise fans of either language. (Note that there is certainly plenty of enthusiasm for each language in its respective community). Rust in particular seems to have a large following of people who aspire to use it but haven't really learned it or used it in anger (this especially used to be the case). Basically they (like me) appreciate the ideas of strong static guarantees, strong performance characteristics, and the general aesthetic of Rust code compared to other high-performance languages or other "functional languages". But those people (and to a lesser extent, many in the Rust community proper) tend to believe that Rust is optimal for those use cases that are conventionally considered to be Go's purview, which is to say they believe Rust is more productive than Go, Python, Ruby, Java, etc for the sorts of applications that those languages are regularly used for (SaaS application backends and other network services). They argue that you just need a little more experience with Rust and you will hit some productivity nirvana; however, each year, I (and many others with experience in this domain) get another year of experience with Rust (as a hobbyist--not full-time development) and still I'm far more productive in Python and Go than I am with Rust. And I don't think the "just need a little more experience" argument holds water. It's based on the idea that the borrow checker and memory management in general become progressively more natural. Well, I have a decade of C and C++ experience and manual memory management is very natural (almost said "super natural") to me, and the trend is asymptotic--with more experience you do indeed get better with the borrow checker and memory management, but it never quite reaches the point where it's in the same ballpark as a garbage collector (where you truly don't need to think about memory management outside of hot spots). Of course, GC languages also don't help you deal with race conditions, but 99% of the code we write in these domains isn't subject to race conditions (and if you are writing something that is pervasively subject to race conditions, it might well be worth considering Rust). Note that there are a handful of very smart, well-respected (and deservedly so) people who also have lots of experience with Rust and who are familiar with the domain in question who disagree with me. I think theirs is the niche opinion, but I think it's worth hearing them out and forming your own opinion.
znpy 7y ago
> both described themselves as "systems programming languages." IIRC Rob Pike later commented that Go should have been advertised more like a "network services programming language" as it is better suited for writing network services than to write low-level components (os kernels, device drivers, embedded programs).
cwzwarich 7y ago
> And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Back when Rust was announced, it was much more similar to Go than it is now, even having a similar runtime for concurrency. Go did a better job than Rust of delivering this paradigm, largely because the Go implementors weren't relying on commodity technologies like LLVM and libuv. As time went on, Rust was given more support by Mozilla, and it evolved into something more suited for browser implementation. It had other major influences at this point: - The constraints of using LLVM. Many projects have failed trying to make LLVM do something that it's bad at doing. At the end of the day, LLVM is good at compiling C++ and things that look like C++, so if you stick to using LLVM and want an efficient language, your language will end up looking more like C++ over time. - The swell of momentum around C++11. All of a sudden, programming idioms from the "Modern C++" movement were becoming mainstream. - The halo of academic research into type-safe systems languages. Very few of the ideas in Rust are new, but some type system features from academia became more palatable for ordinary programmers when combined with the C++11 style.
- throwaway894345 7y ago
  I've heard this about LLVM a lot in the past; does LLVM recognize its C++-centricity as a problem in delivering on its mission of being a multilingual target platform, or has it tacitly changed its mission to be more-or-less implicitly C++-centric? And specifically, what sway does Rust hold on the LLVM project and its goals?
  - swsieber 7y ago
    I would say it's mostly incidental - c++ like things are its biggest use case and get the most feedback.
  - cwzwarich 7y ago
    > does LLVM recognize its C++-centricity as a problem in delivering on its mission of being a multilingual target platform, or has it tacitly changed its mission to be more-or-less implicitly C++-centric? LLVM is a mostly corporate-sponsored open source project. There isn't really a global LLVM roadmap, and developers usually work on things that help their employers. There has rarely been explicit opposition to features that help other languages, but at the same time it is very difficult to make a large nontrivial change to LLVM at this point. Someone who is not already an active LLVM developer might be overwhelmed and give up on upstreaming their changes. IMO the most successful use of LLVM for a sufficiently non-C++ language has been Azul's work on last-tier JIT compilation using LLVM: https://llvm.org/devmtg/2017-10/#talk12 https://llvm.org/devmtg/2017-10/#talk12 > And specifically, what sway does Rust hold on the LLVM project and its goals? As far as I can tell (and this may be a bit out-of-date), basically none.
dagmx 7y ago
Rust and Swift though do have a very close relationship IMHO. They have similar design decisions for ergonomics, and often borrow (no pun intended) from each other. Not to mention Graydon worked on both.
reacharavindh 7y ago
Learning Go and Rust recently, it feels like Go is aiming to be a better Java(GC, excellent libraries, feature rich std library, fast enough but easier on devs) and Rust is aiming to be a safer C.
- neutronicus 7y ago
  I'd say C++ is a closer point of comparison.
- dralley 7y ago
  D is aiming to be a better C++ Rust is aiming to be a better and safer C++ Zig is aiming to be a better C
  - pron 7y ago
    Zig has a good safety story -- in fact, I think it might turn out to better than Rust's -- but it is very different. A language that uses sound methods to guarantee certain kinds of safety (as Rust does) is not necessarily the best way, and it certainly isn't the only way, to write safe code. The handwavy way to explain that is that a language that soundness comes at a cost, and getting rid of 100% of a certain class of bugs might overall be less safe than an approach that gets rid of, say, 98% of that class and can also help reduce bugs outside that class by similar unsound means. I.e. system safety and memory safety are very much not the same thing (although the former is a subset of the latter), and since the goal is system safety, it is unclear exactly how much it is worth paying to soundly eliminate all memory safety bugs.
    - throwaway17_17 7y ago
      I agree with the premise that there are multiple measurements for ‘safety’ and I absolutely do not believe Rust’s chosen method is superior to all others, but I’ve seen you get blow back in other threads for these statements before, so I thought I’d toss in some support of the overarching ideas before the long meeting of response come flying in.
- 7y ago

hu3 7y ago

Indeed, Rust and Go are different beasts with different target audiences. I see it mostly as a debate between correctedness vs pragmatism. Granted these traits can be orthogonal but often aren't.

pjmlp 7y ago

Depends on where one is coming from. For example, while I do find quite interesting what Rust developers have managed to do with linear types, to the point that they have influenced language designers from D, Swift, C++, Haskell, OCaml to find ways to adopt them into their language designs, if Go community would be more welcomed to modern language design, that would be enough for my use cases. As I am a firm believer, that even it takes beyond my lifetime, all modern OSes will eventually be like Mesa/Cedar, Oberon, Singularity, Midori,.... By the way, Java is not a Web / glue language, there are plenty of embedded bare metal deployments using it, e.g. PTC, Aicas, IBM, Gemalto, Kyocera, Ricoh, all have offerings in that regard. If you want examples for systems programing in Go have a look at Android's GPU debugger, gVisor hypervisor, F-Secure USB key, TinyGo for micro-controllers, or its boostraped compiler.

deleted 7y ago

[deleted]

mamcx 7y ago

You must also take account that people not always look at a language per by their MOST perfect domain fit. For me, and probably many I look in the rust sphere(and go and swift and F# where I also have worked), this langs are not picked because "I need bare-metal baby!" but "I need something a bit faster/easier to deploy/less resource/less crazy intensive than obj-c/python/ruby/js/php". I have picked all 4 (rust, f#, go and swift) because that, because all (except go) have AGDTs and pattern matching (and go only because I need some utilities easier to cross compile FAST) and that is all. ALSO because are langs FRIENDLY to solo(me!)/small teams of developers. Even If i must pick a "system language" I will NEVER pick C++, too much complexity. That is why I pick F# vs C# (F# is more economic in lines of code, more expressive and overall simpler), Swift as fast I as could (vs obj-c) and Pascal over C/C++ in the old days. Looking this way, them intersect much more than most imagine.

niclo 7y ago
May I ask how you experience with F# was and how you used it ? I'm slowly learning it but I'm not 100% sure to keep going, maybe switch to other similar languages with bigger communities/bigger market demand
- mamcx 7y ago
  I use C# a lot before and think F# is a good alternative. I use for ERP-like app development with web backend, CLIs, mobile all done on OSX. I move now to Rust (for long term bets I made) but think F#/.NET Core is a great toolset in itself.

bcrosby95 7y ago

Many companies standardize on a couple languages. For companies like that, Go and Rust might occupy the same sphere of influence.

sacado2 7y ago

They have very different design philosophies and were announced more or less at the same time, that's why people always compare them and feel like they have to pick a winner, despite them targeting very different niches.