Keep in mind that software engineering as a field is like, incredibly new, compared to a lot of other fields. Computers have not been around for that long, historically speaking.

It’s honestly to be expected that some of the first established languages did not turn out to be the best language that could be. We’re still figuring out how programming languages should be.

In 50 years, there will probably be another series of programming languages. They might even be optimised for LLM usage rather than for human directly, who knows. This stuff is all so new.

working on a project where memory safety isn’t that important

I can’t really imagine anything where this is not the case, unless you’re doing like… I dunno, small scripts for personal use or something? But why would you use Zig or C or even Rust for that, just do Python or even bash at that point? Python is memory safe and perfectly suitable for very small programs where static analysis gives little benefit.

ReleaseSafe which have runtime checks to prevent illegal behavior

To prevent some illegal behaviour. Again, I’m not an expert on Zig, but as far as I understand, even Release"Safe" is not actually memory safe.

Saying that “memory safety is checked by tests” is basically saying “memory safety is not checked”. Yes, you can write tests. How do you know the tests cover all cases? How do you know the tests aren’t buggy?

Also, what about memory safety across threads? Are you testing multi-threaded scenarios? Are you ensuring you have no data races?

I also don’t understand how this is an argument for Zig over C. You can also test memory safety of your C code via various means, but it’s never a guarantee. Zig is the same. So again, it seems a bit more pointless to go from C to Zig. Going from C to Rust brings actual tangible guarantees of memory safety (outside of any unsafe usage, obviously).

rust does a great job, however there are some inconsistentcies where a lot of memory allocations can throw out of memory errors that will crash the app

That is not an “inconsistency”. Crashing the application when you run out of memory is honestly in almost all cases the correct call and crashing is memory safe. Most applications can do absolutely nothing when running out of memory. “Handling” OOM is extremely complicated and most applications simply cannot handle it in any way.

Of course low level stuff needs to sometimes actually handle this, but it’s mostly an operating system thing. And Rust still allows you that control, it’s just not the default behavior of the collections and such in the standard library, because again, it almost never makes sense to try to handle OOM. But if you really need that behavior, you can have it.

Agreed that it makes the transition from C easier, but I’d also say it makes the transition from C more pointless. I don’t really know that much about Zig but from what I’ve heard, I don’t really get the benefits - if you want a fast systems-level language without guard rails, why aren’t you just writing C (or C++, if that’s your thing)?

Can’t argue with that

Why are you considering Zig instead of Rust? Or is it in addition?

Generally agree with the takes here and similarly befuddled that an unofficial site like lib.rs seems to be entirely better in almost every way than the official site. It’s a bit disappointing.

I’ve unfortunately seen first hand the stubbornness of some developers on the Rust project when I tried to contribute a minor thing myself. I perhaps just had a bad unlucky experience, but it turned me off from ever contributing again.

it becomes possible to discover parts of the website that exist but you can’t access.

This doesn’t really apply as a concept to crates.io though, as all crates on the site are public. It seems kinda like security theater to be doing these 403s when all the data is public anyway. GitHub doing this makes sense as there are private repos.

A code viewer for the actual uploaded code is much appreciated. The upcoming diff view sounds really useful too.

Is season 3 better than the rest? Do you need to watch the movie?

Considering coal is pure C, I can’t really imagine an alternate fuel that would change the math substantially

Yea probably within an order of magnitude or so - then again, elephants are probably within an order of magnitude of size of humans. I don’t see why elephants couldn’t eventually evolve to an intelligent civilisation, given enough time. I’d say that’s still pretty large.

But yea I mean the blue whale and the largest dinosaurs are probably about the limit of how large life can get, at least with Earth conditions.

Rust-based JS engine that isn’t just AI generated unsafe everywhere

Tbf only 4% of the code was unsafe after the rewrite, which is much better than the 100% of the Zig code being unsafe. Honestly it’s not surprising you’d have such a large amount of unsafe when you translate Zig to Rust. But as I understand it, it’s since been refactored to much less than 4%.

I mean it was 600,000 lines of Zig prior to the rewrite yea? If we say that a team is ~6 people, that’s 100,000 lines each to read through and translate. Assuming 250 working days in a year, that’s 400 lines of code you just need to read every day, let alone the Rust you need to be writing (approximately another 400 lines).

Add to that overhead for planning and coordination… I actually think a year for a team might be an underestimate.

But maybe you wouldn’t need as much fire cause bigger animals tend to hold heat better?

I thought the same thing. Then again, fire is not only needed for heat, but also for cooking food and creating new materials (metallurgy essentially). But surely a large creature could just make fires the same size as humans do if they needed to do those things? But perhaps it’d be impractical to cook food at a tiny fire hehe

Smaller I suppose, but larger? Why not? Wouldn’t you just have a really large fire?

Not kinda, exactly like it - it is just another example of it :)

I’ve never seen such a small flame, I think they can’t exist. Why? I don’t know.

Your intuition is correct and it’s quite simple really. A small fire cools down faster than it can keep/generate its own heat.

Surface area of the fire (which correlates with how quickly it cools) grows with the square of the size of the fire. Meanwhile volume of the fire (which correlates to how much heat it generates, how much fuel it is burning) grows with the cube.

At small sizes, the surface area can win out against the volume. However, because it grows with the cube, the volume eventually wins as the fire gets bigger. So a fire can only get so small.