91–100 of 110 posts
Earlier quoted context omitted.
WG14 could design such an evolutionary path, it has been obvious since 1980's, however they clearly aren't interested.
Yeah, it's really disappointing. I think the general attitude is to use calls to functions that are safe and to use instrumentation, which I get, but it results in these piecemeal fixes over the years.
Earlier quoted context omitted.
This is the exact same attitude as people who threw tantrums about seatbelt laws in the 90s. It was wrong then, and it's wrong now. For mostly the same reasons.
Seatbelt laws are still wrong, government has no business protecting me from myself. But even from an utilitarian perspective, compilers do have warnings and they could just have used that.
Discussion yesterday of Odin, that touched on Zig and D. https://news.ycombinator.com/item?id=43939520
Odin, a pragmatic C alternative with a Go flavour - https://news.ycombinator.com/item?id=43939520 - May 2025 (106 comments)
Oh man, I wish the Haskell crowd gave at the very least lip service to that type of idea.
Earlier quoted context omitted.
Anything that produces object files is a lot harder to debug and maintain than a transpiler.
Not sure I agree. If you’re going zig->C->obj, you’d still have to fix the zig source if you find an issue in the C level. If you don’t want to learn or debug in a new language then you should probably just stick with C? The goal of zig as far as I know is to make it so you can transition away from C completely. Maintaining a C target seems antithetical to breaking ties with the “C machine”.
I've been closely following and evaluating the train of C replacement languages that was (I believe) started by Jonathan Blow and Jai. Zig is one of the strong contenders, but Odin is IMO following a saner path, Carbon and D should be mentioned and I think there are a few others. My initial reaction to new programming languages is naturally skeptical, but I really liked the way the designers behind those efforts appr…
> the problems they try to solve are not painful enough. The lack of safety is not painful enough? There is an entire industry (i.e. job sector, training, expertise) that evolved to try to thwart bad actors abusing unsafe languages.
Computer security and exploitation is a complex and difficult topic.
Bad actors are looking for vulnerabilities to build exploits, some are related to memory corruption but many of the most sophisticated ones are not.
All programs are potentially unsafe, regardless of the language. Using a language like Rust can help to some extent, but it won't be sufficient if the programmer is too ignorant about code hardening.
You can't replace experts with the flip of a switch.
Earlier quoted context omitted.
Horrendous compilation time. Unnecessary complexity everywhere, basically C++ but worse.
There's a lot less complexity in Rust than C++. Compilation times are mostly due to lack of compiled code reuse, which is bad but not unsolvable.
Eh, I don't know, I don't think so absolutely. I think in the general "application" paths yes there's less complexity but as a language overall, no.
The thing is Rust has all the same capabilities of C++, that is to say, everything. With that same strong emphasis on free abstractions - meaning, abstractions that do not cost anything more than if you wrote the implementation yourself.
Templates and stuff are a rabbit hole but if you go down the path of procedural macros and generics in Rust it's more of the same. It gets crazy, wild, and super complex. But most people don't have to worry about that, because these sort of "squeeze every last bit of juice" features are most useful for library authors.
The ease of using Odin over Zig for Raylib was an interesting contrast that I hadn’t reflected on myself. I tried to do things well with C3, but it might be hard to beat Odin on that particular point. I just wonder how well it will work long term with update cycles and such. Zig and C3’s decentralized model seems easier for handling frequently updating libraries.