[octalide]

You can shoot your legs all day in mach. There is no such thing as unsafe code, just poorly designed code.

The stdlib has patterns like zig's allocator design as well as Option and Result types that are used frequently through the stdlib itself and other projects written in mach. Achieving safety is very possible, and entirely optional.

[Panzerschrek]

> There is no such thing as unsafe code, just poorly designed code.

It's incorrect. In many programming languages there is a clear separation between safe and unsafe code - via special unsafe blocks or something similar. Languages without such separation are always unsafe or (rarely) always safe.

So, I assume Mach is fully unsafe, like C is.

[throwaway17_17]

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.

[Panzerschrek]

Rust have shown that safety can be achieved without sacrificing performance and many other aspects of language design. My language Ü proved this to be true too. So, I now see no reason not to incorporate safety mechanisms into newly-designed programming languages. For me adding no safety mechanisms is like not including safety belts and airbags in a newly-built car. That's why ask the same question again and again under each Show HN post presenting a new 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.