←back to thread

Rv, a new kind of Ruby management tool

(andre.arko.net)
333 points steveklabnik | 10 comments | 26 Aug 25 08:15 UTC | HN request time: 0.42s | source | bottom
Show context
sleepy_keita ◴[26 Aug 25 22:27 UTC] No.45033134[source]▶
I find it interesting how Rust is gaining momentum in tooling like uv and now rv.
replies(2): >>45033154 #>>45033816 #
inopinatus ◴[26 Aug 25 23:57 UTC] No.45033816[source]▶
Rust is the new C. Go had a shot but went in an applications direction. I predict that very soon, perhaps even inside of three decades, Rust will become the dominant, first-choice systems programming language.
replies(4): >>45034164 #>>45034544 #>>45034814 #>>45035389 #
1. hu3 ◴[27 Aug 25 00:48 UTC] No.45034164[source]▶
Go can do just as well in tooling.

Microsoft chose Go for tsc rewrite. https://devblogs.microsoft.com/typescript/typescript-native-...

And then there's esbuild, also in Go, which revolutionized web bundling speed https://esbuild.github.io

replies(4): >>45034540 #>>45034880 #>>45034918 #>>45038999 #
2. tough ◴[27 Aug 25 01:44 UTC] No.45034540[source]▶
I love both Go and Rust but Go is GC no? Where rust shines is on its safety at compile time and lifetime/borrow/memory model imho

both are awesome tools!

replies(1): >>45035080 #
3. veber-alex ◴[27 Aug 25 02:40 UTC] No.45034880[source]▶
MS uses Go for tsc because they are basically doing a line by line rewrite of tsc from typescript to Go.

It's impossible to do this kind of rewrite from a GC language to a non GC one, especially Rust where the object soup of typescript will probably cause the borrow checker to explode.

I think that if MS or someone else decided to write a typescript type checker from scratch there is a high chance Rust will be chosen.

4. bikitan ◴[27 Aug 25 02:47 UTC] No.45034918[source]▶
It's important to note that Microsoft's choice of Go for tsgo was because it would be easier to port the existing TypeScript codebase due to the structural similarity of TypeScript and Go. If writing from scratch, they likely would not have chosen Go.

Which is not to say that Go can't do well in tooling. Only that Go was not necessarily their first choice.

replies(1): >>45034975 #
5. hu3 ◴[27 Aug 25 02:56 UTC] No.45034975[source]▶
How is Go structurally similar to TypeScript?

It doesn't even have advanced generics like TypeScript, nor union types. No classes and no heritance either.

Unless you have a source, I'd say that's a very debatable speculation.

My guess is they chose Go for the same reason most users do: it's good enough, easy to grasp, has a decent std lib and is easy to grasp.

replies(2): >>45035067 #>>45035142 #
6. frollogaston ◴[27 Aug 25 03:12 UTC] No.45035067{3}[source]▶
GC vs no GC will impact your code structure more than anything else.
7. frollogaston ◴[27 Aug 25 03:13 UTC] No.45035080[source]▶
GC is ok for these use cases. In fact with such short-lived processes, GC is probably not even running before it terminates.
8. jtbaker ◴[27 Aug 25 03:24 UTC] No.45035142{3}[source]▶
https://www.youtube.com/watch?v=10qowKUW82U

Around the 13 minute mark, Anders goes into it. IIRC, the big things were the GC and them both supporting cyclic data structures.

replies(1): >>45035668 #
9. hu3 ◴[27 Aug 25 05:07 UTC] No.45035668{4}[source]▶
Makes sense. Cyclic data with Rust is not trivial, to put it mildly. And GC does make things much easier.
10. inopinatus ◴[27 Aug 25 12:55 UTC] No.45038999[source]▶
That is kinda my point though. None of those are kernels, device drivers, hypervisors, virtual machines, interrupt handlers, bootloaders, dynamic linkers; and writing such things in Go would be an uphill battle against the language's own design, much like the Go runtime itself. Being a GC'd language almost completely fences Go off from even being in the running for these, except for hobby projects trying to prove a point.

Universal applicability may not be necessary to write a Ruby installer, but it certainly is to have any hope of taking C's crown.