5 ms·

Rust and Go are very different languages, with very different aims and objectives. They are often mentioned together, as a few years ago around about the time

Rust and Go are very different languages, with very different aims and objectives. They are often mentioned together, as a few years ago around about the time Go went public, they both talked of themselves as 'Systems Languages'. But they meant very different things by that. Ruby is not a language that would ever be used for writing a web browser, Virtualmachine, OS kernel, or other high performance low-level software. Nor is Go. Rust is. Ruby and Go are languages for writing servers, web apps, 'scripting', and high level stuff. Rust has the interesting property that it may well be possible to write relatively sane higher-up-the-stack server software, in the land that Ruby and Go currently are popular, but it's not there yet. If you want a replacement for Ruby, and don't want to use Go (for whatever reason), then I'd really advise asking "Why?", first. If you want to learn and grow as a programmer, then learn a bunch of languages, and don't get too hung up on whether or nor they'll last. There's a good chance that in 20 years time we'll all be using something totally weird and different, so learning a bunch of different ways of working and learning to think in different terms from Ruby may be more use than any specific language. Learn Haskell, Rust, Racket, Erlang, Assembly, Forth, Ada, Fortran, C, D, Clojure and Scala, say. If you want a very practical language for writing server stuff, quickly and without having to learn too much new stuff straight away, then maybe look at Elixir, Kotlin or Ceylon. If you're happy with Ruby, then there's no real reason not to stick with it. It's a good language, and a lot of fun to use. (Elixir is superficially similar, if the aesthetic of Ruby code really appeals to you). Rust should be pretty easy to write extensions for ruby in, so if you want to try branching out into Rust, for doing high performance / low-level stuff, then give that a go.

tptacek 11y ago
Go would be decent for applications asymptotically approaching web browsers if the user interface options were better. It's UI library support that makes Go such a bear for desktop applications, not any fundamental property of the language. In general, I find Go works really well for anything I would normally code in C in userland. A better way to put it: if you can reasonably write it in Java, you can almost definitely write it in Go. Nobody calls Java a "scripting language".
- pcwalton 11y ago
  > Go would be decent for applications asymptotically approaching web browsers if the user interface options were better. No, it wouldn't. Browsers are too performance critical. You need an industrial-strength optimization pipeline in the compiler, and even having a GC is risky. (There are numerous other smaller-but-still-critical reasons why Go's design prevents it from working as the implementation language for a competitive browser, but these two are the biggest show-stoppers.)
  - tptacek 11y ago
    I agree, which is why I replaced "applications like web browsers" to "applications asymptotically approaching web browsers".
- deckiedan 11y ago
  I kind of think web browsers are a special case - along with complex game engines with very high framerate requirements, and running lots of custom scripts. But yes, GUI apps would be pretty good in Go, if there was better library support. I totally agree. I wasn't trying to say Go is a "scripting language"... Maybe that came across badly. There's a lot of crossover from where 'scripting' merges into the 'real application' world. I had a bunch on bash scripts for writing large video projects to tapes, and synchronising projects on multiple workstations. I then wrote a very simple web app so that non-techies could control it too without the commandline. I then ended up writing a small job queue for that, and a few other bits to go along with it, some workstation monitoring, and so on. It's now a 3k lines small python application, with a few shell scripts underneath. That domain, Go could work pretty well for too, I think.
davidpelaez 11y ago
I agree in that you wouldn't write a driver in Go, but you would in Rust. It simply feels very strange to consider that Rust intention is limited to those areas. It could, but I have a feeling it can have a larger scope than the one it has somewhat imposed on itselve because it can effectively replace C/C++. It's semantics are somewhat more complex that something like Go, but using it shouldn't prove much more complex that Go one you are used to the language basics. This could be of course my errors anaylising the problem, maybe it's way slower/complex and without any great benefit when precise memory management can be spared in favor of development speed. But even then I wonder if the existance of immutability, exhaustive pattern matching and an expressive type system don't increase heavily the realiability of Rust code hence providing stability reducing bugs. > If you want a replacement for Ruby, and don't want to use Go (for whatever reason), then I'd really advise asking "Why?", first. I'm slightly tired of not having a type system, I keep shooting myself in the foot and introducing little bugs that a type system would often get. In ruby heavy testing is very important and I find myself wanting things like immutability and pattern matching to ensure I handled exhaustiveness in my logical assertions during the program flow. Also, my company pays way to much for not so much concurrent users because Ruby consumes a lot of memory. We have to think to much about deployments and horizontal scaling and I'd prefer something simpler to scale. This are all problem that we have solved. They are natural to the dynamic character of Ruby, but the beautiful syntax and simplicity of DSLs come at a price in development and deployment. Go feels a very poor language. Channels are nice and expressive, but the lack of a larger type system, error handling, it's mostly imperative semantics and excessive simplicity make it unattractive. I don't want a compiled Javascript, I want the quality of abstraction that simple tools can bring even though they may not be the easiest. Javascript is very unrealiable and full of quirks. Go is too simple to offer level of abstraction we want to invest heavily in program correctness without too much testing. Ocaml has an interesting balance but I want statically linked binaries at all times and have no interesting in dealing with what seems a messy standard library and compiler flags to get the exact result I want. Haskell's too complex to learn for any practical use. Purescript seems interesting but suffers from the same complexity as Haskell. Many other languages are not safe even though they're fast and compiled and many JVM languages are way to close to Java which I would love to see disappear during my lifetime. It's very picky, but hopefully the downsides of every language appear clear as to why I'd consider Rust instead of Go as a replacement to ruby.

tptacek 11y ago

Go would be decent for applications asymptotically approaching web browsers if the user interface options were better. It's UI library support that makes Go such a bear for desktop applications, not any fundamental property of the language. In general, I find Go works really well for anything I would normally code in C in userland. A better way to put it: if you can reasonably write it in Java, you can almost definitely write it in Go. Nobody calls Java a "scripting language".

pcwalton 11y ago
> Go would be decent for applications asymptotically approaching web browsers if the user interface options were better. No, it wouldn't. Browsers are too performance critical. You need an industrial-strength optimization pipeline in the compiler, and even having a GC is risky. (There are numerous other smaller-but-still-critical reasons why Go's design prevents it from working as the implementation language for a competitive browser, but these two are the biggest show-stoppers.)
- tptacek 11y ago
  I agree, which is why I replaced "applications like web browsers" to "applications asymptotically approaching web browsers".
deckiedan 11y ago
I kind of think web browsers are a special case - along with complex game engines with very high framerate requirements, and running lots of custom scripts. But yes, GUI apps would be pretty good in Go, if there was better library support. I totally agree. I wasn't trying to say Go is a "scripting language"... Maybe that came across badly. There's a lot of crossover from where 'scripting' merges into the 'real application' world. I had a bunch on bash scripts for writing large video projects to tapes, and synchronising projects on multiple workstations. I then wrote a very simple web app so that non-techies could control it too without the commandline. I then ended up writing a small job queue for that, and a few other bits to go along with it, some workstation monitoring, and so on. It's now a 3k lines small python application, with a few shell scripts underneath. That domain, Go could work pretty well for too, I think.

davidpelaez 11y ago

I agree in that you wouldn't write a driver in Go, but you would in Rust. It simply feels very strange to consider that Rust intention is limited to those areas. It could, but I have a feeling it can have a larger scope than the one it has somewhat imposed on itselve because it can effectively replace C/C++. It's semantics are somewhat more complex that something like Go, but using it shouldn't prove much more complex that Go one you are used to the language basics. This could be of course my errors anaylising the problem, maybe it's way slower/complex and without any great benefit when precise memory management can be spared in favor of development speed. But even then I wonder if the existance of immutability, exhaustive pattern matching and an expressive type system don't increase heavily the realiability of Rust code hence providing stability reducing bugs. > If you want a replacement for Ruby, and don't want to use Go (for whatever reason), then I'd really advise asking "Why?", first. I'm slightly tired of not having a type system, I keep shooting myself in the foot and introducing little bugs that a type system would often get. In ruby heavy testing is very important and I find myself wanting things like immutability and pattern matching to ensure I handled exhaustiveness in my logical assertions during the program flow. Also, my company pays way to much for not so much concurrent users because Ruby consumes a lot of memory. We have to think to much about deployments and horizontal scaling and I'd prefer something simpler to scale. This are all problem that we have solved. They are natural to the dynamic character of Ruby, but the beautiful syntax and simplicity of DSLs come at a price in development and deployment. Go feels a very poor language. Channels are nice and expressive, but the lack of a larger type system, error handling, it's mostly imperative semantics and excessive simplicity make it unattractive. I don't want a compiled Javascript, I want the quality of abstraction that simple tools can bring even though they may not be the easiest. Javascript is very unrealiable and full of quirks. Go is too simple to offer level of abstraction we want to invest heavily in program correctness without too much testing. Ocaml has an interesting balance but I want statically linked binaries at all times and have no interesting in dealing with what seems a messy standard library and compiler flags to get the exact result I want. Haskell's too complex to learn for any practical use. Purescript seems interesting but suffers from the same complexity as Haskell. Many other languages are not safe even though they're fast and compiled and many JVM languages are way to close to Java which I would love to see disappear during my lifetime. It's very picky, but hopefully the downsides of every language appear clear as to why I'd consider Rust instead of Go as a replacement to ruby.