9 ms·

I keep seeing a lot of 'Rust vs Go' discussions, including in this thread. To me they seem to be targeted at different use cases. i.e. Rust is a C level replace

• kibwen 12y ago
  I have been trying to discourage Go vs. Rust comparisons since time immemorial, given their wildly different purposes and audiences. The eagerness to compare the two seems to stem primarily from 1) both market themselves as "systems" languages (though the vagueness of that term makes this a tenuous connection), 2) both have a focus on concurrency (though in the year 2014, if your language doesn't have a great concurrency story, you've already lost), and 3) the tech crowd seems to adore the imagined narrative of Google vs. Mozilla (though both languages are somewhat disconnected from their backing companies). As a Rust follower, I would really love to see more comparisons to C++, Erlang, and Ada.
  • jsmthrowaway 12y ago
    None of those reasons apply to me, and I think you're overlooking a simple one: As an SRE, I compare them because I'm looking for the next language to adopt as my primary systems/infrastructure language. I have enough issues with C++11 and Python in large systems that I'm looking for an expressive language in which I can work fast and build robust systems. Go and Rust are the finalists for that, with Python keeping the scripting side. Go just happened to finish first. And, I think they both target the same use cases, they just adopted a different mind set on the way there. Most outsiders to Google don't realize this, but Go expresses volumes about the way that Google works internally. And, as with Protocol Buffers, the really awesome stuff in the technology was held back; any Googler will tell you that Go inside the veil is a vastly different experience because of the language-agnostic systems that Google has built internally. At the end of the day, I want a language to write the various tools and systems I need in my SRE life. I've had a hodgepodge until now, and Go is appealing because I can centralize on one (with one toolchain). Rust is becoming more palatable every day.
    • pnathan 12y ago
      I sit in that area (SRE/DevOps/Tools) as well, and I strongly believe that Rust is a better foundational language because of the type system strength and guarantees. Particularly useful is the `enum` type and type matching. I want, simply put, to be able to write code that is "bulletproof" after I've brought it to deployment, and Rust gives me some awesome tools for that. (I've also come to understand that Go is an extremely sharp tool for Google's problems - the style of coding, the concurrency, the expectations of the developers (look at the Google style guides to see the culture of development there, there's a harmony with Go). Your harmony with Go reflects your harmony with Google's problems).
  • TheHydroImpulse 12y ago
    I would be very interested in comparisons to Erlang. Erlang seems to be the king of reliable and fault-tolerant systems and Rust seems to have taken lessons from it.
    • Ixiaus 12y ago
      Not much to compare it to there. Rust's type system is much more advanced which is a big win and it is lower level but Erlang's model of reliability is based heavily on the BEAMVM. Rust has a good concurrency model but I doubt it will compare favorably with Erlang's distributed computing primitives and fault-tolerance features (read, fault-tolerance is not equivalent to type safety!!)
      • TheHydroImpulse 12y ago
        Thanks! Yeah, I was specifically pointing to how tasks in Rust work in terms of failure. The approach of "if it fails, just kill it and potentially restart it". This is the same approach that Storm has managed to be fault tolerant.
        • Ixiaus 12y ago
          Well, you could build a process supervisor that runs in its own forked resource (I'm sure, I don't know the language too well) - we have that in Haskell too (you can see similar code in the Cloud Haskell project where you give a supervisor some child specs and it "supervises" them with a couple different restart strategies). Storm does it more at the machine level, while the philosophy is the same there it's not really done in the language but by Nimbus (correct me, someone, if I'm wrong). The things in Erlang that are novel are really features in its BEAM VM, and not as much in the language. Distributed RPC, a DNS system built in for discovery, hot-reloading, heartbeat, etc... I'm sad that Storm ended up being built on Java - Erlang would have been a perfect and probably better way to implement it.
          • TheHydroImpulse 12y ago
            Indeed. I have never touched Erlang, so thanks for the insight. Storm is a hybrid Java/Clojure project, so it's much better than simply a Java project. But yeah, the fault tolerance is not in the language, but the project itself.
• TheHydroImpulse 12y ago
  They are indeed targeting different use cases. I think a potential reason people are comparing the two is because Rust is also great (it's still early, though, so it'll be interesting where people leverage Rust) at the use cases that Go was designed for, while Go cannot touch what Rust was built for. However, the two being defined as system languages with two widely different views on what "system" means doesn't help.
  • loudmax 12y ago
    I am looking forward to seeing browsers and maybe even operating systems written in Rust. Go, not so much. I'm not so positive that Rust will be so great in cases where you have many developers with different levels of skill and experience working on infrastructure projects. Rust makes the low level stuff easy, but a lot of high level stuff is still going to be easier in Go.
    • TheHydroImpulse 12y ago
      I don't think Rust is that much more complicated. There's a few new concepts, but there are proposals to make them easier to use. I actually feel that Rust is really good at abstractions that make it seem a lot higher-level. I agree that Rust more complex than other languages, but I don't think it's that much more complex. I think better documentation and tooling will make it more approachable.
      • wtetzner 12y ago
        I think that having algebraic data types and pattern matching will actually make Rust nicer a lot of higher level things than Go.
• deleted 12y ago
  [deleted]
• dragonwriter 12y ago
  > Rust is a C level replacement for low level direct memory access coding while Go is a garbage collected Java replacement for infrastructure level programming. Go has been fairly expressly billed as a C/C++ replacement. Now, I think that's somewhat misleading in comparison to Rust also being a C/C++ replacement, in that Go seems intended to replaces C/C++ in uses that are near the boundary where C/C++ (and, yes, Java) competes with Python/Ruby/etc. (where the former set has more of the performance characteristics sought but may be less convenient/concise/expressive, whereas the latter has the reverse features), whereas Rust is aimed at C/C++ deep in those languages prime use cases where they have little current competition -- certainly not from languages like Python/Ruby/etc. -- not at the boundary where they compete with Python/Ruby.
  • mbell 12y ago
    > Go has been fairly expressly billed as a C/C++ replacement. I think the community at large has billed it as such, but I haven't seen such a direct statement come from anyone on the Go development team. This is really the core of my original question, why does the community think of Go as a C replacement when it explicitly does not support the feature set required to be such a language?
    • steveklabnik 12y ago
      You may be interested in reading http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential... , which is a bit old, but has lots of this history.
      • mbell 12y ago
        I think inevitably we all look at languages from the angle of our own experience. For me, thinking of Go as any sort of replacement for C/C++ comes down to the fact that I've used those languages almost exclusively at a very low level. For me, that is firmware on micro-controllers, and not at the level of linux applications or arduino applications, but direct to the 'bare metal' applications where direct memory addressing and other constructs that are 'poor practice' in high level development are the norm. For example I've implemented an http server on an 8-bit microcontrollers with ~3KB of RAM. I can't imagine doing anything remotely close to that type of work in Go, it's on the wrong planet. Rust on the other hand does seem to have the capabilities required to do that type work so in the end, I don't see them competing in any grand sense, they are different languages for different purposes. Put in other words, there is a class of problems C/C++ are used for which Go isn't even remotely suitable for, on the other hand, there is a large class of problems that C++ was used for, that could have been written in Java and Go is a good replacement for. I feel that the subset of problems that were/are solved in C/C++ that could not have been solved in something like Java is fairly small. Off the top of my head things like high end video games, high frequency trading, perhaps database type systems where direct memory access may not really be needed yet the performance constraints are tight enough that something like Java was too slow for it. This may be where the 'systems programming language' moniker came from. I would guess that Google has a disproportionately large set of problems that fit into the space that I think is relatively rare for the programming community at large.
• pohl 12y ago
  When the Go team introduced the language, they used the phrase "systems language", and the meme has stuck, even though Rob Pike has since expressed some regret about having used the phrase so carelessly. Now he thinks the phrase "cloud infrastructure language" would be more apt. http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan... (approx 6 minutes 45 seconds into the talk) I think it will take about a decade for everybody to readjust their frame on this one, alas. P.S. Rust's own Niko Matsakis is one of the 4 people in this panel discussion, by the way, and it is well worth watching – even though they burn maybe a little too much time struggling with the question of what does/doesn't constitute a systems programming language.
  • spopejoy 12y ago
    I blame Stroustrup, who likes to throw "systems programming" or "system language" into every discussion about his baby. It is a bad meme, it even doesn't fit for C++ given it's main application as an application language (cue Torvalds rants about C++)
    • kps 12y ago
      I wouldn't blame Stroustroup. “Systems programming” is vague because originally “systems software” was what came with your system — ranging from OS drivers (which you could write today only in a very carefully restricted subset of C++, amounting to “C with classes”), up to compilers, which can be expressed more cleanly using the larger generally-regarded-as-sane subset (e.g. STL, RAII) of C++. I think Go fits decently for the latter, and reaches up to higher-level (or lazier) code that others might write in Python or Ruby or Haskell. Rust seems to reach as far down as C, which would be nice, though I worry that LLVM lacks any target smaller than ARM to keep them honest.
    • pohl 12y ago
      The concept of "systems language" itself is not the meme to which I referred. Rather, the bad meme is the notion that Go is one. It may be some day if they make GC optional, but it isn't in its current form.
• TylerE 12y ago
  I actually see it the exact opposite way - Go is C's sort-of minimalist brethren, while Rust is the more turbo-powered nuclear chainsaw of C++.
  • wtetzner 12y ago
    The thing is, Rust seems rather simple. The difference is that Rust introduces some concepts most people are unfamiliar with, like lifetimes.
• alricb 12y ago
  "I keep seeing a lot of 'Rust vs Go'" That's unfortunate. We should be arguing about Ocaml vs. Rust or Ada vs. Go!