Most active commenters
  • frollogaston(7)
  • hu3(3)
  • tough(3)

←back to thread

Rv, a new kind of Ruby management tool

(andre.arko.net)
333 points steveklabnik | 23 comments | 26 Aug 25 08:15 UTC | HN request time: 1.445s | 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 #
1. 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 #
2. 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 #
3. 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 #
4. tough ◴[27 Aug 25 01:45 UTC] No.45034544[source]▶
Finally Linus accepted it into Linux.

It's his birthday today btw hbd

replies(2): >>45034950 #>>45035084 #
5. sleepy_keita ◴[27 Aug 25 02:27 UTC] No.45034814[source]▶
Maybe - but in this case, Ruby is written in C, it uses C extensions when performance matters, but tooling for the Ruby language itself is all in Ruby. Rust isn't replacing the use of C in the core of Ruby (yet) - it's stepping in to the area where Ruby would have been traditionally used.
replies(1): >>45035122 #
6. 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.

7. 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 #
8. dboon ◴[27 Aug 25 02:53 UTC] No.45034950[source]▶
It is not his birthday. Today is my birthday and you almost made me very excited
replies(1): >>45045107 #
9. hu3 ◴[27 Aug 25 02:56 UTC] No.45034975{3}[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 #
10. frollogaston ◴[27 Aug 25 03:12 UTC] No.45035067{4}[source]▶
GC vs no GC will impact your code structure more than anything else.
11. frollogaston ◴[27 Aug 25 03:13 UTC] No.45035080{3}[source]▶
GC is ok for these use cases. In fact with such short-lived processes, GC is probably not even running before it terminates.
12. frollogaston ◴[27 Aug 25 03:14 UTC] No.45035084[source]▶
Torvalds was right all along to hold out against C++.
13. frollogaston ◴[27 Aug 25 03:20 UTC] No.45035122[source]▶
Similar thing is in motion with the JS toolchains. Rewriting in Rust is easier than rewriting in C, but why didn't they previously rewrite in something like C++ or Go? I'm guessing because people were simply not interested.
14. jtbaker ◴[27 Aug 25 03:24 UTC] No.45035142{4}[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 #
15. frollogaston ◴[27 Aug 25 04:13 UTC] No.45035389[source]▶
I think Go is going away. It occupies such a weird niche. People have said it's good for app backends, but you should really have exceptions (JS, Py, Java) for that sort of thing. For systems, just use Rust or worst case C++. For CLIs, it doesn't really matter. For things where portability matters like WASM, can't use Go. Bad syntax and type system on top of it.

What if Google spent all that time and money on something from the outside instead of inventing their own language? Like, Microsoft owns npm now.

replies(3): >>45035789 #>>45037084 #>>45037982 #
16. hu3 ◴[27 Aug 25 05:07 UTC] No.45035668{5}[source]▶
Makes sense. Cyclic data with Rust is not trivial, to put it mildly. And GC does make things much easier.
17. skotobaza ◴[27 Aug 25 05:35 UTC] No.45035789[source]▶
I always thought of Go as a middle ground between C and Python. From C it gets simple syntax, from Python - "batteries included" part.

Deserializing JSON and XML is a breeze from my experience. And it's available out of the box. But I guess C++ will get there with reflection having been approved in C++26.

So I don't think it will go away (in the coming years at least), since a lot of tools is written in it.

replies(1): >>45047908 #
18. JetSetIlly ◴[27 Aug 25 09:01 UTC] No.45037084[source]▶
You can compile to WASM from Go.
19. pansa2 ◴[27 Aug 25 11:06 UTC] No.45037982[source]▶
> For CLIs, it doesn't really matter.

Actually, I'd say this is where Go has a real advantage. Are any other mainstream languages both garbage-collected (for ease of development) and native-compiled (for ease of distribution)?

replies(1): >>45043736 #
20. 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.

21. frollogaston ◴[27 Aug 25 19:10 UTC] No.45043736{3}[source]▶
Yeah. Only ObjC and Swift, which nobody wants. But JS distribution is arguably easier than building for every platform. Google did that with Gemini CLI.

Also if you're ok being dirty, short-lived processes can just leak. Some of those Go CLIs are probably not even GCing before the program exits.

22. tough ◴[27 Aug 25 20:53 UTC] No.45045107{3}[source]▶
well happy birthday too dboon!
23. frollogaston ◴[28 Aug 25 03:06 UTC] No.45047908{3}[source]▶
It's not that bad to handle some JSON in C++ or Rust. It can get annoying if you're doing it everywhere, but that's usually that's the kind of use case where JS or Python works anyway. Yes I get that some people prefer Go, but it's not necessary enough to guarantee that it'll stick around.