It feels like there's room for a better C today. I don't mean a really different language. I'm thinking something that is semantically C, and 99% syntactically C, but that a much better story around macros, builds, modules, linking, volatile pointers, and all of the other C foot guns. Not C++ or Rust (though I love Rust). I'm thinking just a smoothed out C. And done in a way where a codebase can incrementally move from C to better C, one file at a time.
Zig, the Small Language
171–180 of 429 posts
Re: Zig, the Small Language
#172No post body was provided.
Re: Zig, the Small Language
#173Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
"Not much safer" isn't fair. Zig has full spatial memory safety, which is already a huge improvement over C. The Zig type system and how idiomatic code looks also prevent various safety risks. Also, Zig panics on integer overflow, avoiding various other dangers. Zig does lack a general solution for temporal memory safety. That is a downside. But it can still have that safety in ReleaseSafe mode, at least - for exampl…
Temporal (runtime) safety could actually be provided via tagged index handles (where the tag is a generation count). But this should be implemented by libraries, not built into the language (like: https://github.com/michal-z/zig-gamedev/tree/main/libs/zpool)
(it's of course not a "general solution", but I wonder if something like 'tagged pointers' could be that, even without hardware support, and at some runtime cost)
Re: Zig, the Small Language
#174Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
"Not much safer" isn't fair. Zig has full spatial memory safety, which is already a huge improvement over C. The Zig type system and how idiomatic code looks also prevent various safety risks. Also, Zig panics on integer overflow, avoiding various other dangers. Zig does lack a general solution for temporal memory safety. That is a downside. But it can still have that safety in ReleaseSafe mode, at least - for exampl…
> Zig has full spatial memory safety, which is already a huge improvement over C.
I don't believe this is true. Zig has pointers to unknown numbers of items, which don't seem bounds checked: https://ziglang.org/documentation/master/#Pointers
They prefer slices idiomatically, but that's not "full spatial memory safety". C also prefers you to pass the length of every array whenever you pass a pointer to it, in that correct code must do this. But the entire point of language memory safety is that we don't trust programmers to consistently do the right thing.
You might be able to say something like "Zig minus features X, Y, and Z has full spatial memory safety". I'd be interested to see what features those are: it looks like at a minimum you would have to get rid of multi-element pointers and extern unions.
> But it can still have that safety in ReleaseSafe mode, at least - for example, by not reusing memory addresses.
The overhead is extremely high, because it leaks an entire 4kB page if a single allocation from that page is still alive. In the worst case, it's equivalent to rounding every allocation up to 4kB. If you're OK with that overhead, you could just link in the Boehm GC and get the same safety with less memory usage, and as an added benefit you wouldn't have to call free anymore.
> Also, while in many domains safety should be the #1 factor when when choosing a language (like building a web browser), that's not universally true. Other factors exist.
In the vast majority of those domains, you could just use a GC'd language. I don't see much room for a new language that isn't memory-safe in 2022.
Re: Zig, the Small Language
#175What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.
I must confess I had to suppress my knee jerk urge to downvote. It almost feels like you're asking "what's the appeal of elegance?" "What's the appeal of Chess, if you want complex gameplay just have complex rules." It almost feels alien that someone couldn't get it. Here's a simple but perhaps disappointing theory. Painting with a broad brush for a moment, there are primarily two sorts of thinkers: memorizers and lo…
> memorizing all the characters in the Chinese writing system
Actually, there's a logic (a stroke order logic and also some common building blocks) to how to build the characters in Chinese (and other similar languages). So I would imagine the "logicians" might be OK with it :)
Re: Zig, the Small Language
#176Earlier quoted context omitted.
Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also direct…
> Not fighting the borrow checker This isn't going to be appealing to Rust current users though, because “fighting the borrow checker” is a learning curve issue, you don't fight the borrow checker anymore once you've internalized its rules. > or making gratuitous copies of data to satisfy the borrow checker. You get it backward. In Rust there's less gratuitous copies, not more, because the ownership rules and the bor…
That was not my experience.
I still fought the borrow checker after a year of using Rust.
And I found many situations while using Rust where I either needed to clone, or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.
Re: Zig, the Small Language
#177Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.
I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours…
One should keep in mind that Rust also has an unsafe subset. While it does not get rid of the borrow checker (quite intentionally) and it also introduces some pitfalls wrt. interacting with safe Rust, compared to C, Zig, Hare, Jai etc. it is in principle quite possible that future versions of unsafe Rust might become just as ergonomic as these competing languages.
Re: Zig, the Small Language
#178What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.
> What is the appeal of small languages?
For me, it isn't just the 'smallness' of the language that matters, it is the understandability of code bases written in the language that matters.
Having fewer language constructs (especially ones that offer overlapping alternatives) means that programs that solve the same problem will tend to look the same. This makes reading a new code base easier, which makes on-boarding engineers faster. This is the main reason I like smaller languages.
Languages like C++ (that seem to adopt every language feature that can be implemented) enable developers to solve similar problems in vastly different ways. In small programs that isn't an issue, but in large, old code bases it can become a very costly mistake. It can be hard to understand a large code base as it is, but when 100 different developers have touched the system and each has a pet style, you are in for it.
Re: Zig, the Small Language
#179Earlier quoted context omitted.
> I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity. you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable
Matrix multiplication or even worse, matrix inversion, is NOT a basic operation. This is exactly the point.
> Matrix multiplication or even worse, matrix inversion, is NOT a basic operation.
Neither is dividing floats, especially not on a softfloat & softdiv architecture. And yet, Zig is perfectly OK with you using division between 2 floats. Why does it get to insert expensive function calls behind operators but I can't?
Zig also lets you do remainder division for floats, which is also not a "basic operation." It's slower even then taking the sqrt of a float! Zig then also has specialized operators like saturating addition, which also isn't a "basic operation"
And then Zig also has `*` for array multiplication and `++` for array concatenation. Those are compile-time only, but still deviates from "basic operations only" territory surely. And also Zig overloads `||` to allow for the merging of enums (sorry, "error sets"), rather than only being a boolean OR.
Re: Zig, the Small Language
#180Earlier quoted context omitted.
Maybe language docs vs stdlib docs. Language docs are good for most topics, stdlib docs are much worse than stdlib sources.
That's exactly right. When I tried it, the Language Reference was great, and the stdlib documentation was a UX-challenged semi-broken webapp.
For what it's worth, work on it as resumed now that the self-hosted compiler is mature enough. Still very far from being complete, so we don't link it yet on the front-page, but it's being actively improved.