I'm often skeptical of the desire to create a lot of passes. In the early Vale compiler, and in the Mojo compiler, we were paying a lot of interest on tech debt because features were put in the wrong pass. We often incurred more complexity trying to make a concept work across passes than we would have had in fewer, larger passes. I imagine this also has analogies to microservices in some way. Maybe other compiler people can weigh in here on the correct number/kind of passes.
This PumpkinOS project is pretty incredible. I can't imagine how much effort it would take to be compatible with all the system calls that the average Palm app would expect. I remember Palm did some truly weird things with memory: anything moderately large would need to be put into a special memory block that the OS could rearrange at will, and one would need to lock the block's handle to keep it stable while accessing it. Stuff like that must have been challenging (and fun) to implement in PumpkinOS.
This brings me back. I used to make little games for Palm OS, and I was so excited for the next version of the OS which would let one use the (then new) Palm OS Development Suite to make programs. It was also the last OS I've used where an app had a central event loop. Everything else today has UI frameworks that handle it for you. Things are easier now, but I still miss it.
I'm particularly interested in this line of thinking, and I'd probably lean the same way. Would love to hear more, why do you think it's a better approach to default to more high-level, with the ability to drop down into manual memory management for hot paths?
I think the reason Rust's syntax is so controversial and divisive is that its syntax works well for some areas and poorly for others.
TFA highlights it well:
> It is needed because Rust loves exposing physical layout of bytes in memory as an interface, specifically for cases where that brings performance.
Rust (and its syntax) is designed for precision and performance and explicitness. That's great for the parts of your code that are extremely performance sensitive.
However, for most of our code, we need flexibility and high-level readability a bit more... a bit of a mismatch with some of Rust's decisions.
I like C#'s approach here. By default it decouples away all of these unnecessary low-level decisions, and lets you focus on what the code is actually trying to do. Then, if you want to do performance-sensitive work, you can use things like `struct`. I wish it went a bit further, but it's pretty nice.
I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains:
A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this.
We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side.
Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.
I suspect a lot of the toxic discourse originally comes from folks not understanding each other's use cases and priorities.
For some, memory safety is a means to an end: delivering value. In this perspective, one must weigh the benefits of improving memory safety against the complexity costs of proving memory safety. In some situations, the improvement is too small and the added complexity is too much. Some apps and some embedded situations come to mind. Languages like Odin and Zig can be stellar in these situations.
For others, memory safety is a responsibility, and upholding it is a basic requirement of modern software no matter what costs we need to pay for it, and if the world would just accept that, then we as a society could move past the days of rampant vulnerabilities and odd memory bugs.
Both sides are equally compelling, to me at least. What I hope people can learn is that it really depends on the situation. There is a place and time for both approaches. Once we can accept that, I think the toxicity will dissipate.
One thing I like about Odin is that you can use any allocator with any existing function, without wiring that function to specifically do that. It just comes for free. In a way, it completely decouples the code from the allocator choice. It's especially nice because we can use any allocator with any third party code.
I think this kind of decoupling is a big step in the right direction. The more concerns we can decouple from each other, the simpler and more flexible our codebases become and the less time we have to spend infectiously refactoring.
Ante is making some very intriguing steps forward in memory safety design and I thought others would find it interesting too.