While Drew is the designer of Hare, a lot of us worked on Hare, and we tried really hard to create something useful and valuable. I think it would be a shame if you disregard it because of something that Drew said at whatever point in time. If you have the time, please try Hare and let us know what you think!
Aside from that, the question of memory safety is more complex than you make it out to be, and Drew, myself and others have discussed it in a lot of detail in this thread, Drew mentioned there are many memory safety features, potential plans for an optional borrow checker and so on — please draw your conclusions based on the full information.
I am sympathetic, but I agree with others that any new systems language in 2022 must have memory and thread safety with minimal escape hatches as its utmost priority and a core component of the language design.
Otherwise, what's the point? Yet another language that is a bit more convenient than the alternatives but doesn't do much to help with all the vulnerabilities and bugs in our software? We already have quite a few languages like that: Zig, Nim and D to name a few. (for both Nim and D GC is optional)
Rust is by no means the ultima ratio. It's complex and places a lot of immediate burden on the developer. I'm sure there are better solutions out there that don't sacrifice the safety guarantess. Particularly because Rust not only has the borrow checker but also a general focus on very type-system heavy designs.
But it has proven to be a significant step up from the likes of C and C++, and the additional burden pays off immensely in maintainability and correctness. I can count the memory/thread unsafety issues I encountered in 5 years of Rust on one hand, and in each case the culprit was a C library. (either because of a bad wrapper, or inherent incorrectness in the library)
Memory and thread safety can't be retrofitted into a language without producing a mess, as can be seen by the discussions and efforts in D, C++ and to some extent Swift.
They need to be central to the core language and standard library.
> Rust is by no means the ultima ratio. It's complex and places a lot of immediate burden on the developer. I'm sure there are better solutions out there that don't sacrifice the safety guarantess.
There are undoubtedly better solutions than Rust, but they tend to allow for more developer-managed complexity rather than less! For example, one might imagine a cleaned-up variety of the GhostCell pattern, to decouple ownership- and borrow-checking from the handling of references. The principled extreme would be a language that just implements full-blown separation logic for you and lets you build up the most common patterns (including "ownership" itself) starting from that remarkably "simple" base.
I don't think that's really the case. I can't think of any new safe GC-free languages that are more "manual" than Rust, but there are at least a couple that use reference counting with compile time optimisations to make it not really slow. Koka looks the most interesting to me at the moment.
Making the Rust ownership model central to the core language and standard library has meant that after 11 years of Rust, your program still can't have two objects of the same type owned by different allocators. As a result, I am interested in other approaches to these problems.
Local allocators are being standardized. This has nothing to do with the Rust ownership model, C++ took a long time to standardize an allocator abstraction too.
This is a very unsympathetic take. If you expand to the full context, you'll note that I weigh memory safety against other trade-offs, and come away with a different answer than Rust does.
Hare does have safety features. Checked array and slice access, mandatory error handling, switch/match exhaustivity, nullable pointer types, mandatory initializers, no undefined behavior, and so on. It is much safer than C. It just doesn't have a borrow checker.
Your comment comes off as very dishonest. How does this quote summarize "everything I need to know". The quote you show appears to be out of context, I followed your link and that it appears to be a conclusion following a number of points explaining why, for the author, Rust's safety feature is apparently not enough to counterbalance it's flaws.
I don't fully agree with the points there (I enjoy Rust), but what does criticizing Rust have to do with "not understanding memory safety"?
Can you elaborate on why somebody has to appreciate Rust? Because I don't see it. Rust is not a religion and we shouldn't treat it as such.
