361–370 of 429 posts
Earlier quoted context omitted.
Quoted post unavailable.
I think it is a big improvement, on the axes that matter most for low-level programming. In fact, Zig is so revolutionary (rather than evolutionary) that its power is sometimes missed on first glance.
Earlier quoted context omitted.
Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer overflow semantics of Zig with "-fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow -fsanitize=float-cast-overflow". You could write a checker that enforces that only these features are used (in fact, this checker basically exists--ISO Core C+…
Yes, technically there might exist a subset of C++ as safe as idiomatic Zig. But in practice inertia and legacy code and lack of ergonomics etc. work against that subset of C++ becoming popular - does anyone constantly type .at()? Zig can do better, if it doesn't squander the opportunity. In other words, this isn't about theoretical subsets of a language. It's that there is an opportunity when designing a new languag…
Earlier quoted context omitted.
> Third: There are a lot of cases where the cost of memory safety just isn't that high, and Zig's mitigations are more than sufficient. But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. C++ makes sense when you already have a lot of C++ code, but if you're talking about new code, I don't see a lot of room for a language without memory safety.
> But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. I mostly agree with you, and I'm enthusiastically using Rust. But I'd love to be able to develop new software, with modern developer conveniences, that could run on a 1995 computer. Assuming that implies a 32-bit OS, that seems plausible with Rust, albeit not with std (but alloc should be fine). Maybe I'll pla…
https://medium.com/@MStrehovsky/building-a-self-contained-ga...
What 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.
Go look at herb sutter's guru of the week articles, and consider how many C++ programmers can actually solve them. Then consider c++ has gotten even more complex in the past 9 years since he last published a gotw. The main problem is that every c++ programmer has their favorite little bit of complexity in the language, and that favorite bit is different for everyone. So you end up with a codebase sprinkled with the f…
Earlier quoted context omitted.
It does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?
The fanaticism of Rust devs makes me think it's probably massively overrated (see Node yesterday and Ruby/Rails the day before) and Go is associated with Google which gets a perhaps unfair but still unignorable knee-jerk reaction from me to avoid it. I don't know enough about Nim to pass judgment. Two reasons I decided to give Zig a try: The official chat channel is on IRC, instead of Discord or Slack (so the people…
Or it's enthusiasm for something that's genuinely worth being excited about. Such things do come along from time to time. It's probably not a good idea to be permanently jaded, to assume that everything is zero-sum, that we can never again make progress by bending tradeoffs.
Earlier quoted context omitted.
Have you considered adding a dedicated `breakpoint` keyword for this use case? Linters could ignore it, but the compiler could warn or error. The problem with workarounds like `assert(0)` is that the linter lacks context to do the right thing.
Adding another feature is always tempting, and there are daily new feature requests for D. We simply have to have a very high bar for new features.
Earlier quoted context omitted.
I'm not at all trying to change your mind (I've never used Zig so I can't comment there), but just FYI: 1. Rust uses Zulip (ie, not Discord or Slack), 2. Rust doesn't lack for promising-looking, declarative/reactive UI frameworks: https://iced.rs/ , https://crates.io/crates/egui , for example.
>1. Rust uses Zulip (ie, not Discord or Slack), The official Rust chat is on Discord. Now, to Cyberdog's point, there is an IRC channel on libera (that I'm also a part of) and it's even bigger than Zig's channel, but it's "unofficial" and they did ask for an official one. Like, Zig's channel has the advantage of being a direct line to andrewrk which you won't get from the Rust channel.
Culturally, there's more of a "pitch in to help" and less "ask before touching". So people are mostly looking for hand-holding, "How do I?" and "Is this correct?" rather than decisions and permission.
Why 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/
The simple answer to your question (if you really meant it as a question) is that memory safety comes with ergonomic and performance costs. The Rust project is an experiment in hammering those costs down as small as possible, and sometimes maybe even turning those costs into benefits. But the costs do exist, and of course not every project in the whole world will want to pay them.
Earlier quoted context omitted.
I do think the 'unsafe' notation is the crucial bit here. Rust has stuff that is heavily (although not completely) motivated by C interop. For example, 'union' in Rust is something that is rarely used outside of C interop. (With some notable exceptions in the standard library.) But, crucially, in order to actually use a Rust 'union', you do have to utter the 'unsafe' notation. I'm not sure I have an opinion as strong…
I don't think the annotation itself is actually the point. The point is being able to find all sources of unsafety and reason about them. Annotations do that, but other things can too. Imagine if you could run a tool on a codebase, and it statically found all the unsafe locations, and in idiomatic code there were very few of those, and you could reason about them. That would be equivalent to writing "unsafe" in the c…
Otherwise, I do think you underestimate the differences between an annotation like 'unsafe' and what you can find easily only through a static analysis tool. The key bit of the 'unsafe' annotation is the concept of "safe API" that it inspires, and also gives one a vocabulary for talking about things like 'soundness.' For example, you can mark Rust functions as 'unsafe' and then document the preconditions for avoiding UB. If you didn't mark that function as 'unsafe', then we would call it unsound because there exists an input that could cause UB, but it does not necessarily result in UB for every input.
The annotation gives people a way to talk about and crystalize precisely what it means for an API to be safe for all uses. It funnels everything about memory safety down into that one concept and makes reasoning about it much much easier. Without an annotation like that, it's cumbersome or downright difficult to even talk or communicate about soundness.
Earlier quoted context omitted.
I think it is a big improvement, on the axes that matter most for low-level programming. In fact, Zig is so revolutionary (rather than evolutionary) that its power is sometimes missed on first glance.
If we look from the point of view of comptime and having a more curly friendly syntax for C folks, maybe.