21–30 of 58 posts
I feel like there's space for imperative, garbage collected, pattern matching, and ADT language. Just Golang + pattern matching + ADT. I would be sooooooooooooooooooooooooo happy. I think there ought to be a subset of Rust that uses Arc for everything, maybe with a language feature that desugars into it. Obviously this requires compilers to be able to reason and optimize out atomics.
> Writing a substantial amount of unsafe Rust really sucks the beauty out of the language. I really disagree with this take, given the examples of unsafe code the article chose to exhibit. Trying to write C in Rust totally goes against the grain of Rust's ergonomics, which are oriented towards discouraging unsafe code patterns. It should be a pain to attempt something dangerous, and it should feel really easy to writ…
This sounds like just prescriptive orthodoxy. In fact lots of applications, including big chunks of Rust's own standard library, need unsafe to correctly express their algorithms (doubly linked lists and balanced trees are famous examples of things that can't be borrow checked, the use case in question appears to be a collected heap which would likewise need to live in the same space). Deciding that these areas "shou…
This is the "strategic use of friction" described here, ironically enough, by the creator of Zig: https://github.com/ziglang/zig/issues/3320#issuecomment-8844...
Earlier quoted context omitted.
This sounds like just prescriptive orthodoxy. In fact lots of applications, including big chunks of Rust's own standard library, need unsafe to correctly express their algorithms (doubly linked lists and balanced trees are famous examples of things that can't be borrow checked, the use case in question appears to be a collected heap which would likewise need to live in the same space). Deciding that these areas "shou…
Rust's approach is more like a "keep off the grass sign" than a barbed wire fence. If Rust really wasn't meant to be used for these things, it wouldn't have the unsafe keyword at all. But instead of forbidding those things entirely, it just makes them uncomfortable. This nudges the programmer to question if they really need to be on the grass to accomplish their goal, and helps subconsciously steer them onto the safe…
The details in the linked articles rise well above merely "uncomfortable" though. If your response was appropriate, we wouldn't be here discussing them. In particular the interaction between the borrow and aliasing analysis is something I hadn't thought of before, and seems terrifying.
This gets back to my earlier point. The Rust community seems to have abandoned introspection for orthodoxy. You say something interesting about it, and the response comes back as a canon incantation about why Rust is always right. But there are interesting criticisms to be made, people just don't want to hear them it seems.
(In particular the bit about "you can't write dlist in safe rust" routinely seems to surprise people, even reasonably expert Rust developers, I talk to in real life. The flock's dedication to the borrow checker apparently means that no one is allowed to discuss or think about the places where it can't work!)
I feel like there's space for imperative, garbage collected, pattern matching, and ADT language. Just Golang + pattern matching + ADT. I would be sooooooooooooooooooooooooo happy. I think there ought to be a subset of Rust that uses Arc for everything, maybe with a language feature that desugars into it. Obviously this requires compilers to be able to reason and optimize out atomics.
https://dart.dev/language/patterns
Edit: while there aren’t full ADTs, it does have sealed classes which help with exhaustiveness in matching
> Writing a substantial amount of unsafe Rust really sucks the beauty out of the language. I really disagree with this take, given the examples of unsafe code the article chose to exhibit. Trying to write C in Rust totally goes against the grain of Rust's ergonomics, which are oriented towards discouraging unsafe code patterns. It should be a pain to attempt something dangerous, and it should feel really easy to writ…
This sounds like just prescriptive orthodoxy. In fact lots of applications, including big chunks of Rust's own standard library, need unsafe to correctly express their algorithms (doubly linked lists and balanced trees are famous examples of things that can't be borrow checked, the use case in question appears to be a collected heap which would likewise need to live in the same space). Deciding that these areas "shou…
I feel like there's space for imperative, garbage collected, pattern matching, and ADT language. Just Golang + pattern matching + ADT. I would be sooooooooooooooooooooooooo happy. I think there ought to be a subset of Rust that uses Arc for everything, maybe with a language feature that desugars into it. Obviously this requires compilers to be able to reason and optimize out atomics.
Zig has a singular focus on doing low level systems programming and it shows. Rust is very nice for systems programming, but it's not as ergonomic as Zig at all. Of course, it's a much nicer and more comfortable general purpose language. I think both languages are great and hope to see them used more and more in the future. It's much better to debate when to use Zig and when to use Rust then go back to the dark days…
Apart from syntax sugar over which I agree should be improved, the argument sells to boil down to: my language doesn't enforce a borrow checker so it is UB safe. Which in my book is just not true. The allocator example the user gives is not really good since if he had another try in between the alloc/free I assume the memory would not be freed, Drop semantic is better in that regard. You can also set a global alloc t…
The idiomatic way to handle that is with some combination of `defer` and `errdefer`. Then, in code, there are no lines between alloc/free, and if a try would exit before the free then you would instead first free anyway.
> drop semantic is better in that regard
The drop trait has its warts too. Zig's version sets up a point in time where the given cleanup code _will_ run (ignoring power outages and the like), and Rust's sets up a point in time where the given cleanup code is _allowed_ to run. It solves UAF, but it makes performance harder to reason about and makes leaks easier to write (a common theme in my complaints about Rust -- it's mostly a nice language, but many of the design choices slightly encourage leaky code, so most projects of any size and complexity have leaks). Having drops be that easy to write also encourages programmers to think in terms of small units of data rather than collections and common lifetimes, typically resulting in increased execution times.
It is still in Rust.
No, there's parts of Roc that are in Zig[1]. At a glance, it seems like they moved mostly-wholesale over to Zig at one point, then moved back while still keeping some parts. [1]: https://www.roc-lang.org/faq.html#rust-and-zig
> Roc's compiler has always been written in Rust. Roc's standard library was briefly written in Rust, but was soon rewritten in Zig.
> Rust’s raw pointer types are nullable by default and have no null-pointer dereference checking. There is a NonNull pointer type that gives you more safety. I’m not sure why it’s not the default, since Rust’s references are non-nullable. NonNull would probably be a better default indeed, but one reason might be that NonNull has more UB than *mut T (namely, it is UB for it to be the null pointer). (A lot of the text…
Not quite. In Zig, a (non-C) pointer type is closer to a Rust reference in its behavior. It isn't null, and that's enforced by the type system.
The author's point about opting into nullability is that in a function signature you can choose to allow null pointers to be passed to the function by making the argument type an optional pointer, a weaker type with the same safety guarantees (because, like with Rust, the type system forces you to handle the null branch).