Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

521–530 of 560 posts

Re: Rewriting Bun in Rust

#521

Post by comex »

FridgeSeal wrote: post #233
comex wrote: post #222

Earlier quoted context omitted.

The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors? In C, usually…

> Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?…In Rust, almost always no, because of circular dependencies This feels like a strange, overly-specific complaint. It reads a bit like “When I write entangled code, it’s hard to untangle”. Like, yeah, the only thing that’ll save you from that is…not writing entangled code? I…

I addressed some of these points in my reply to a sibling comment:

https://news.ycombinator.com/item?id=48856158

I may have been a little overly specific, since there are other issues besides cycles that also block splitting crates apart, but from what I’ve seen it’s very common for modules within a crate to have cyclic dependencies and therefore not be easily factorable into separate crates.

Re: Rewriting Bun in Rust

#522

Post by pjmlp »

IshKebab wrote: post #502
pjmlp wrote: post #488

Earlier quoted context omitted.

Yes, but no one needs to use C++23 to the full extent to stress test the compiler in -O3, or go crazy with compile time execution. While I could comfortably still develop C++ in a Asus 1215B netbook with 8 GB and SSD, thanks to all the native libraries I could install, and make use via pkgconfig, the same could not be said to play around with Rust on the same netbook. This matters, because not everyone can afford top…

I don't think I really agree with that. You can make do with less powerful machines in Rust too. Until this year I was using a 12 year old quad core machine that was only a bit faster than a RPi 5. I think the biggest issue is actually disk space. C++ isn't exactly efficient with disk space but Rust is on another level. You're going to run out of disk space on that netbook it you have any more than like 2 Rust projec…

On that netbook, this tiny Gtk Rust application took about 10 minutes from a git clone.

https://github.com/pjmlp/gwc-rs

The original C++ versions was done in 2 minutes, because it spent zero minutes compiling all dependencies.

Needlees to say that first compilation had an impact on battery charge as well.

Naturally on such a beefy machine it will fly given how fast Bevy gets compiled.

Re: Rewriting Bun in Rust

#523

Post by josephg »

afiori wrote: post #333
imtringued wrote: post #258

Earlier quoted context omitted.

How is not having to mark your unsafe code as unsafe a good thing? You couldn't have come up with something more incomprehensible. If 99% of your code doesn't use unsafe, why contaminate 100% of your code base with footguns?

I agree with your point, but for completeness: > How is not having to mark your unsafe code as unsafe a good thing? The problem with unsafe code in Rust is that IIRC nobody actually figured out yet the "rules" of unsafe i.e. which invariants you can stretch and which can cause UB. My (not super up to date) understanding is that this is an active area of research and progress is being made and also that in practice th…

I don’t know what you’re referring to. Unsafe seems pretty well defined for 99% of use cases. Unsafe blocks allow you to dereference raw pointers and call unsafe functions. Thats about it. Remarkably, even in codebases which need a lot of unsafe (eg the kernel), almost all code is safe code.

Re: Rewriting Bun in Rust

#524

Post by pjmlp »

vlovich123 wrote: post #501
Rohansi wrote: post #470

Earlier quoted context omitted.

It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of. C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).

Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger. Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on. C…

Yes, it is, most game studios use Live++, a commercial product which whole goal is to enable live reload in game engines.

Likewise CERN's ROOT is quite famous, nowadays superseded by CINT, and integrated in Jupiter netbooks via Xeus.

Re: Rewriting Bun in Rust

#525

Post by pjmlp »

vlovich123 wrote: post #518
Rohansi wrote: post #510

Earlier quoted context omitted.

> only work on Windows with Visual Studio Really shouldn't be a dealbreaker when 95% of your users will be using Windows (to play games), so your most tested platform should be Windows. > when you started it under a debugger Hot reload isn't a replacement for scripting IMO. It will never be as good. Even hot reload in Rust would have more limitations than an actual scripting language.

Sure, that doesn't take away from the experience of Rust being better than C++ even if you probably still want a scripting language too. In total Microsoft only holds ~12% of the total video game market share across PC and console in terms of owning the platform (i.e. Xbox + Windows). I think you're overestimating how many game developers get to use reverse debugging for gaming. In practice given the limitations for…

It is a share big enough that Valve cannot have games for the SteamDeck without Proton.

Re: Rewriting Bun in Rust

#526

Post by pjmlp »

flohofwoe wrote: post #262
didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

> and you decide to drop to down to C++ Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).

Market share, IDE and graphics tooling, and industry standards.

LLVM is not going to take PRs written in Rust to fix the Rust compiler backend, for example.

Neither are OpenJDK, .NET, V8, JSCore going to take such PRs.

By the way, LLVM and GCC would also not take PRs written in C.

Re: Rewriting Bun in Rust

#527

Post by pjmlp »

frizlab wrote: post #151
didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

My personal memory and concurrent-safe option is Swift. And I agree, choosing a non-memory safe language for a new project is close to irresponsible today…

Sometimes we have no option, given the industry standards that expect C or C++.

Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives.

I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if they technically exist, you still need to overcome the human and political factors.

Hence why it is so relevant to fix C and C++ security flaws to some extent as well.

Re: Rewriting Bun in Rust

#528

Post by pjmlp »

whytevuhuni wrote: post #252
steveklabnik wrote: post #187

Earlier quoted context omitted.

> way too big https://github.com/tormol/tiny-rust-executable This produces a 137 byte binary. Obviously AMD64 isn't used in embedded, but I've seen ARM ones that are in the ~256 range. It's all in how you use it. Of course, if you don't care about binary sizes, they can get large, but that's very different than actually paying attention to what you're doing.

I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash). First of all, I was amazed by how much I could do with Rust ( safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project. But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the wh…

On that universe you would be better off with BASIC or Pascal compilers than Rust, which would already be safer than C, while offering similar sizes.

Mikroe has C, Pascal and BASIC compilers for all kinds of microcontrollers, that is their main market.

Re: Rewriting Bun in Rust

#529

Post by flohofwoe »

pjmlp wrote: post #526
flohofwoe wrote: post #262

Earlier quoted context omitted.

> and you decide to drop to down to C++ Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).

Market share, IDE and graphics tooling, and industry standards. LLVM is not going to take PRs written in Rust to fix the Rust compiler backend, for example. Neither are OpenJDK, .NET, V8, JSCore going to take such PRs. By the way, LLVM and GCC would also not take PRs written in C.

'Industry standards' is where programming languages go to die ;)

As for PRs: well yeah of course, when in Rome...

Re: Rewriting Bun in Rust

#530

Post by pjmlp »

flohofwoe wrote: post #529
pjmlp wrote: post #526

Earlier quoted context omitted.

Market share, IDE and graphics tooling, and industry standards. LLVM is not going to take PRs written in Rust to fix the Rust compiler backend, for example. Neither are OpenJDK, .NET, V8, JSCore going to take such PRs. By the way, LLVM and GCC would also not take PRs written in C.

'Industry standards' is where programming languages go to die ;) As for PRs: well yeah of course, when in Rome...

C has been doing quite well with industry standards like UNIX/POSIX, OpenGL, Vulkan, VFX, OpenMP,..

Same applies to C++ with CUDA, SYSCL, HPC/HFT frameworks, LLVM/GCC, AI compilers,...

They don't look dead to me, even if we as industry could be much better by now.

Post reply on HN