
Would you consider replacing Ruby with Rust instead of Go? - davidpelaez
I&#x27;d love to see comments that don&#x27;t consider the amount of libraries but the languages themselves since eventually more open source will exist in Rust. This is mostly a question of someone doubting go because of this http:&#x2F;&#x2F;yager.io&#x2F;programming&#x2F;go.html
======
deckiedan
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
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
> 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
I agree, which is why I replaced "applications like web browsers" to
"applications asymptotically approaching web browsers".

------
derekperkins
While the points in that article are valid, in practice they don't cause as
much trouble as Go trolls think. :)

As for moving from Ruby to Rust or Go, Go is almost guaranteed to be faster
for developers to learn. The reason for the complaints in the article is that
Go is intentionally simple, and you're seeing many people migrating from
dynamic languages to Go for those benefits. The fact that Go has its roots in
C will make it immediately understandable to anyone with experience in a
C-type language.

My final thought is going to address libraries and widespread acceptance.
Regardless of your thoughts about Go as a language, there is no doubt it is
here to stay. Underlying major technologies like Docker, it has already seen
massive adoption. While initial signs are positive for Rust, you're still
betting that it continues to build momentum and doesn't stagnate like Haskell.

~~~
davidpelaez
I agree many people use Go for it's simplicity for new developers which is
understandable but not the only way to measure why a language should be
adopted.

I'm yet to verify this, but it seems that Rust is closer to Haskell in that it
intends to enhance the likeliness of program correctness as it's being written
and not only through testing. In go you still get runtime errors and I don't
think it's all that rare, Rust should reduce those greatly.

I do share that adoption through libraries and widespread acceptance is very
important and when you compare Rust to Haskell you make a nice point, the
language could be great but not generate adoption.

However besides adoption I don't see anyone who seem to dislike the process of
writing Rust itself. Apparently people think it's viable if more libraries are
out there. The natural presentation of the arguments made me feel that people
are open to it should the right libraries be there.

------
TheSwordsman
> I'd love to see comments that don't consider the amount of libraries but the
> languages themselves since eventually more open source will exist in Rust.

That doesn't seem like the kind of comment to start a meaningful conversation.
I must ask, what data do you have behind that statement.

I think both languages offer their own set of pros and cons.

For me, Go has been my go-to because of the maturity of the language. And, it
has been implemented in systems that run at a very large scale by people
within Google/YouTube as well as CloudFlare.

Would I consider it? Honestly, maybe one day. But that depends on how the
language, and related things, mature over the next few years. And I think it's
after the libraries have filled-in, and there is experience running systems
built with it at scale.

Go is allowing me to solve the problems I have right now with some well-built
packages. Is it perfect for everything, no. But it does well in a lot of
areas.

~~~
davidpelaez
It's not my intention to close the conversation but to try to make it richer
by not focusing on the historical advantage that Go has over Rust. You are
correct in that it's possible that not much more open source will exist in
rust since it could simply fail to acquire any massive adoption.

I do think there will be space for both and I would prefer to consider them as
raw tools, hence the language themselves, and take the risk of having a
community in the future sharing libraries for common things. It's a risk but
not a crazy one I'd say and probably helpful for the analysis.

Building on your reply, I'd say prove of adoption is one downside for choosing
Rust. This however ignores the merit of Rust as a language which hints me into
what I have begun to see more often: that it's the newness and relative
absence of production use cases that don't seem to validate it viability, not
some inherent complexity or downside to the language itself.

------
akacase
No, Go is more simple, in terms of syntax among other things. The threading
model in Go is very attractive as well, please refer to this article:
[https://swtch.com/~rsc/thread/](https://swtch.com/~rsc/thread/)

~~~
pcwalton
> The threading model in Go is very attractive as well, please refer to this
> article: [https://swtch.com/~rsc/thread/](https://swtch.com/~rsc/thread/)

That's a nice overview of CSP. It's not a selling point for Go over Rust. Rust
threads are in fact a purer implementation of CSP than Go goroutines are.

~~~
davidpelaez
Go offers thread as channels directly expressed in the language Syntax, not as
a semantic construct on top of them. That is of course attractive for it's
simplicity, but Rust offer a lower level alternative. I don't have much
experience with Rust, but maybe a clever macro could be use to express in a
higher level the type of things you'd use go channels for.

Going back to my proposed question, maybe people can prefer golang for this
syntactic benefit but I don't think that addresses the larger set of
differences that usually separate them.

------
hartator
IMHO, Ruby is still one of tthe strongest language in term of ease of use,
object orienteness and features. Go and Rust compared to Ruby will adress not
performance but core scability and this can be addressed in numerous ways in
every architecture.

~~~
davidpelaez
I agree that you can address the scalability problem in every architecture in
different ways. In ruby you'll typically have a mix of vertical and horizontal
scaling that often results in a significant consumption of memory. This even
though feasible comes at a higher price on cloud resources. I have experience
this first hand and I think it's similar (at much minor scale of of course) to
what companies like Shopify have experienced as motivations to change to
something like Go.

