[tempest_]

The use of LLMs has caused Rust usage to explode.

If youre not writing the code yourself and vibing away which I think most people generally are despite the disdain around here then why would you not choose the "more performant language" (I know that isnt necessarily reality but it is a common perception).

Go's managed runtime is less valuable when the LLM is perfectly happy to slap a bunch of stuff together for you to and approximate it and doesn't complain at all when writing async rust despite some of the rough edges.

[hu3]

Correction: The use of LLMs has caused every major language usage to explode.

And as mentioned in other comments, Rust slow compilation can be detrimental to LLMs + fast iteration speed. And it's not just speed, Tauri takes 20GB of disk space to compile. It's bonkers. This is npm/js ecosystem all over again but slower.

Another reason to pick Go if you're leaning on LLMs is the standard library. Often you can do more work with fewer dependencies.

I'd rather leverage world class engineers paid by Google to maintain dependencies for me than try my luck with half a dozen of 0.x crates. Plus stdlib APIs can (and are) versioned just like third party dependencies.

[wanderlust123]

Fully agree with this. We use Rust in an enterprise setting for building web app backends and the experience is painful. A lot of crates just seem like someones side project. Too many ways to do things leads to bike shedding in PRs. Compile times are atrocious and can take like 30 mins to build.

Honestly using Go would have got us to the same point much quicker, with code that is much easier to review.

[Aurornis]

> And it's not just speed, Tauri takes 20GB of disk space to compile

I’ve worked with enough UI frameworks and large applications that this doesn’t sound unreasonable. It’s a smaller disk footprint than I’ve needed for several other C++ codebases with similar scope.

[lanstin]

I like vibe coding but I am sceptical that a vibe coded runtime in Rust would be as awesome as the Go runtime which is written with deep expertise of Unix software and threading and many low level details that are subtle and do depend on global properties of the code to work flawlessly. It makes sense you can crank out Rust with an LLM if you know what you are doing, but if you want a GC type thing or preemptive scheduling across an N by M threading model, then you are competing against some very good code.

[LtWorf]

> the Go runtime which is written with deep expertise of Unix software

Go has no mmap(), import a 3rd party dependency for that and you'll get a segfault the very second you do a mistake.

Python has an mmap module which will catch many memory errors and present them as exception rather than causing a CVE.

[tptacek]

I don't agree with the parent comment, but mmap is exposed (low-level) in the standard library and there's a high-level wrapper in x/exp. You need to be careful with mmap no matter where you're using it.

What Go mmap CVE were you thinking of?

[LtWorf]

> What Go mmap CVE were you thinking of?

Every time you see "segmentation fault", that right there is a CVE.

[tptacek]

No, obviously.

[LtWorf]

Because you don't report and open the CVE, not because it isn't a security issue :)

[tptacek]

I agree that agents make Rust a lot more tenable for less "kernel-and-browser"-demanding tasks than it was 4 years ago, but I do not agree that they eliminate the "managed vs. unmanaged runtime" question, and to the extent they influence any of this decisionmaking at all, you have to accept the notion of not reading the code. If you're reading it, it matters that Rust makes you do bookkeeping that managed runtimes avoid.

[PaulRobinson]

By that reasoning, we should all be vibing away C code. It's the most performant and efficient language out there, there's a ton of code out there the LLMs were trained on, and the complex logic of memory management is abstracted away by the LLM so you don't need to think about it.

Most people are not doing that though. There's probably a good reason, and it applies to other languages too.

[fg137]

There is a good chance that your vibe coded C program segfaults immediately upon running and contains lots of subtle logic errors, all of which requires many iterations (finding issues at runtime) before you program runs as expected.

With Rust, you'll likely get many compilation errors, but if your syntax is correct, compilation errors will be few, and your code will almost certainly just work.

[tptacek]

I wouldn't build anything in C that I didn't absolutely have to, but, no, there is not in fact a good chance that your vibe-coded C program segfaults immediately.

[risyachka]

In order to use C you need to actually understand it, also toolchain is more complex etc. Which makes it a no go for 99%.

Rust is so safe that anyone can vibe it without any idea what is going on there. Which is basically what is happening here.

And why rust is more used than go for vibecoding? Mostly because of hype and performance gains which 99.9% of projects do not need.

[tcfhgj]

> performance gains which 99.9% of projects do not need.

most software isn't "needed"

[majormajor]

> The use of LLMs has caused Rust usage to explode.

Rust had a "vibey" community long before vibecoding. In particular, it's long been fairly non-serious about yolo importing a bunch of crates to solve things (since the standard lib is small) which is kinda the same problem as having all those things just vibecoded. Either way, most projects weren't reading all of that other code!