The article significantly misses the mark by treating Ruby as nothing more than Rails — a perspective that currently detracts from the language. The author clearly hasn't explored the strong features of Ruby 3. Not to mention, it's a very nice language to learn as an entry point into programming.
Ruby is incredibly versatile: NASA has used it for simulation, it's a popular choice for scripting, DevOps automation, and static site generation. It's a simple, dynamic language ideal for quickly prototyping solutions.
Elixir, however, is a separate conversation. Having used it in production for years, I can attest that the ecosystem is fantastic. Its lack of mainstream popularity doesn't matter; its true strength lies in the BEAM, an incredibly well-architected piece of software. Elixir is simply a great way to access that power. Beyond its Ruby-like syntax, it has become its own distinct entity. It used to exist mainly as a alternative to erlang but it's become its own thing in recent years.
I really hate language-based dogma, every virtually every programming language has place as a tool in in a programmer's tool belt. There is even value in learning and using deprecated languages because doing so gives you a perspective beyond whatever ecosystem that you're currently tied to. There is a reason that languages like fortran and lisp have persisted as meaningful choices in certain domains and I suspect that Ruby will stick around for a very long time.
Scoop is the main package manager I've been using for years on windows apart from chocolatey. Dunno many others aside from the official windows one: winget.
I've been using Windows as dev platform since it was called "DOS but don't look too closely", I know chocolatey, ninite, winget, and powershell's own built-in nonsense, and yet had never head of scoop until just now. So... that really just tells us that any application manager we think is popular, ubiquitous, and the obvious choice is still really just a niche program =(
Contrast that to brew on MacOS: ever non-devs know about brew.
And from all of those, which I'd heard of, I think scoop is the only one to allow a package author to just create a git repo, and publish a package that way.
Like brew does. That why I use scoop.
Chocolatey would rather charge money for that, for some reason, and people are still willing to donate them their free time.
Hmm, well Go itself has gone through a ton of revisions where the GC saw large improvements. And other languages coming up are experimenting with various types of GCs. Its really up to the use case though.
With discord, I imagine a big reason why Rust was considered as an alternative to Go is because they already have a substantial Elixir codebase. Rust and Elixir have a very easy time communicating with one another via Erlang NIFs (native function interfaces). You can embed languages like C/C++/Rust into elixir without much overhead. While I've never personally tried do to such a thing with go, I can't imagine its a smooth experience. You'd probably need to use Ports or CNodes for Go simply for this reason.
I love go myself, but one of the biggest turn offs for the language is its FFI support for C and other C connected languages. CGo is a relatively expensive investment when compared to many other comparable alternatives and it should be avoided if possible.
We use Elixir + Rust in a few select places. But the majority of our Rust code is services that are purely written in Rust.
We use Rust over Go, not only because of the garbage collection issues, but because it's truly a better language in almost every way (once you learn it!)
I will say, Go is much easier to pick up, but in exchange you pay in the long term having a language that actively works against you when you start working on more advanced programs, and a mountain of code that's accumulated over the years that you have to maintain.
We work on high concurrency systems here, and I very much enjoy not ever having to think about "is this thing thread safe" because the compiler is checking that for you. I love being able to use the type system to offer my co-workers powerful, but difficult to misuse libraries. I like having sensible abstractions around concurrent execution.
Like, for example, if you create a channel in go, and for whatever reason, don't try to read from the channel, or give up (because you're racing a timeout), then the goroutine that tries to write to that channel will block forever and leak. In Rust, if you try to write to a channel where there is no longer a receiver, the write to channel will return an error, which you can then choose to handle, or simply ignore depending on your use-case. Of course, you can be wise and allocate your channels with a capacity of 1, but you can also just completely forget that, and start a steady leak of goroutines for the lifetime of your program that the garbage collector won't save you from!
Want to execute many futures with bounded concurrency in Rust and collect the results back into a Vec, but give up if any of the futures fail, or if a timeout is elapsed, and also make sure that all allocated resources are properly dropped and closed in the event that any errors happen? Just combine a futures::stream::StreamExt::{buffer_unordered, collect}, and a tokio::time::timeout, and in a few lines of code you've done it.
Want to do the same in Go? Spawn a pool of goroutines I guess, distribute two channels, one for sending them work, one for receiving work, and don't forget to throw in a WaitGroup, pass a context along to all the goroutines, make sure you don't forget any defers, if you are using a shared resource, make sure it's thread safe, or make sure you're locking/unlocking the appropriate mutex, make sure you size your result channel appropriately or you might leak goroutines and any allocations they hold if your main goroutine that's spawned all that work timed out waiting for the results to come in. Is there a library that does all this for you in Go? I googled "golang run many goroutines and collect their results" and looked at the first page of results, and it's basically the above...
It is no surprise then that we've picked to use Rust pretty seriously. When you're looking to build reliable systems with serious speeds and massive concurrency, you pick the best tool for the job. That for us is Rust, not Go. And for our real time Distributed systems, we pick Elixir, because BEAM/OTP is just so dang good.
> We use Rust over Go, not only because of the garbage collection issues, but because it's truly a better language in almost every way (once you learn it!)
What about complexity? How does "enterprise Go" code compare to "enterprise Rust" code? And what about the tooling. The other threads here are dwelling on GC, and latency, and threading and so on.
One of Go's selling points is that it tends to force writing simple-to-read code.
My general experience in C++/C#/Java/Kotlin is once a code base gets beyond a certain size and number of developers, without any discipline, it becomes a hot mess.
all the issues you mention for go literally plague every other language out there except for a very small minority. of which rust is one. its a fair criticism but you're completely disregarding the downside around development speed.
I've used both languages extensively. I like both languages. I still reach for golang first because its faster to develop with simply due to the compile times.
+1. Used Go, Python, React, etc extensively for years at Facebook. The massive Go projects were easiest to extend, operate, and on-board people to.
Rust vs Go discussions are pretty silly. More folks should think of Rust + Go. There are a lot of glue-services that can take the trade-off of a GC, be magnitudes better than Python, and be maintained by a short-staffed team.
Plus, Rust is still plagued by Python (and others) Async problem — it's easy to accidentally block the event loop. When you have a ton of tiny glue services, esp. if one has a lot of contributors / internal libs, it's an easy mistake. Critical path things are worth the attention to detail. Others... ¯\_(ツ)_/¯
not really. if you're in a steady state (like discord was) you wouldn't see any spikes. you'd have a consistent utilization. if you start allocating heavily then you would potentially see an increase. which makes sense, you're increasing your workload, utilization needs to increase. but still not necessarily a 'spike'
The main issue with Go in this regard is that it generally doesn't have multiple ways of doing the same thing at least idiomatically. I mean sure, there are architectural choices you could make in a rewrite but the actual structure of the code itself is going to be very similar.
I love Rust elixir Nifs. Gives you the best of both worlds to be honest. Highly fault tolerant code with fast computation. Only downside is that it can't really handle extreme crashes like a native process can.
Erlang/Elixir + Rust is an awesome couple. For the downside you mentioned, depending on the use case, it could be interesting to use Rust as a node: https://github.com/sile/erl_dist
You've got alternatives like Flutter and ReveryUI which are both pretty solid for building cross platform applications without using web technologies or webviews.
And you can always just use some of the other GUI toolkits that have been coming out recently.
Interesting. So according to @baxrob, Tauri took over control of https://github.com/webview/webview project for the past year. And now I'm told they are moving away from it.
I'm left wondering why take over a project if they're going to ditch it. For lack of a better term.
We didn't take over control, rather we helped setup an independent org around webview and other related repos. At the time, the original author of webview expressed plans to work on it a lot. However, this didn't really happen. Webview is stuck with some nasty bugs and missing features, and none of the members of the Tauri team had enough C experience to fix it efficiently. Instead, we created our own pure Rust solution (https://github.com/tauri-apps/wry). We've already given it way more features than the original webview project, and it doesn't carry the bugs that plagued webview either. The next release of Tauri (about a month or so out) will use Wry, and will have features such as multi-window and fancy window styling (frameless, fullscreen, custom controls, etc...).
Ruby is incredibly versatile: NASA has used it for simulation, it's a popular choice for scripting, DevOps automation, and static site generation. It's a simple, dynamic language ideal for quickly prototyping solutions.
Elixir, however, is a separate conversation. Having used it in production for years, I can attest that the ecosystem is fantastic. Its lack of mainstream popularity doesn't matter; its true strength lies in the BEAM, an incredibly well-architected piece of software. Elixir is simply a great way to access that power. Beyond its Ruby-like syntax, it has become its own distinct entity. It used to exist mainly as a alternative to erlang but it's become its own thing in recent years.
I really hate language-based dogma, every virtually every programming language has place as a tool in in a programmer's tool belt. There is even value in learning and using deprecated languages because doing so gives you a perspective beyond whatever ecosystem that you're currently tied to. There is a reason that languages like fortran and lisp have persisted as meaningful choices in certain domains and I suspect that Ruby will stick around for a very long time.