|
|
|
|
|
by throwaway17_17
2 days ago
|
|
Not to derail this thread on Mach, which as I stated in another comment has some pretty appealing characteristics for me, but since you’re here and the dev of another ‘low-level’ programming language: I read through a segment of your language’s docs when it was on the front page a couple of days ago ago. Since you’re talking safety’s is there a link (or just a suggested starting point) to read about Ü’s safety mechanisms and guarantees? I feel like I sit along a different axis in the safe versus unsafe discourse, so I don’t discount languages like Zig or Mach for not providing opt-out safety for certain areas of concern and I don’t give extra credit to languages like Rust or Ü for having those features. What I am interested in is what choices where made and why, then what do those choices mean for me as a potential user of a language. |
|
> I feel like I sit along a different axis in the safe versus unsafe discourse
I can't believe someone can be neutral in this question. If you do actually write code in unsafe-languages, you are eventually forced to find a fix memory-related bugs and other bugs caused by their unsafety. Maybe you just don't need writing such low-level code and use some high-level language without direct memory access instead?
> what choices where made and why
In many cases there is no answer. My experience shows that many design decisions are made without thinking too long. One often just needs something to work right now rather than spending much time carefully designing each language feature. It's especially true for pretty-young language projects like Mach.