Game Jam 2 Results

Possibly because the IDE helps with that. Including adding and removing import statements. I feel like this complaint is more theoretical than something felt by people using Go day to day.

> And again we're assuming that the ones we went over in the previous thread are all there is.

No one is assuming that. Like Rust, Zig has a set of unsafe operations that are well known to Zig programmers.

> How are they clearly marked, when they're neither relegated to a separate section of the documentation nor behind a switch?

They are syntactically distinct from the safe features, and they might be hidden behind a switch when there's demand for such a feature.

> As far as I can tell, the person who has gone through the most effort to isolate the spatial memory safe subset of Zig is me, in these HN threads.

So not only is disagreeing with you a fringe opinion, you're now the most knowledgeable on Zig's safety, a subject that is of great interest to Zig programmers? Those who spend the two days required to learn Zig know which operations are unsafe.

> Again, "struggling to get 1% of the market" is a weird way to describe a language that's serving billions of users right now.

Haskell and Erlang are also "serving billions of users" in the same way. The fact is that at an age where almost all programming languages (Python might be the sole exception) were in the ballpark of their all-time peak popularity, only a tiny portion of developers choose Rust. Like Zig, Rust is a language whose future success is uncertain.

Look, not everyone would like Zig, not everyone would like Rust, and for all we know it's quite possible that the main difference between the two approaches is that they appeal to different people. But trying to make Rust's design appear inevitable or uniquely legitimate for low-level languages when that language is doing poorly, or claiming to speak on behalf of a consensus where there clearly isn't one and several other languages targeting the same domain prefer a very different approach, make you sound detached from reality.

I find it a questionable choice to design a new complex language when complex languages tend to do poorly in the market, or to attempt a language for low-level programming that tries to appear high level on the page after C++'s lacklustre success with that approach, but I recognise that not everyone has the same taste as me, and I wouldn't call my opinions a consensus.

With all due respect, your comments seem to imply a certain level of immaturity and it does not seem like you really know what you are talking about.

It's possible in some cases that you can implement something in JavaScript which is competitive with a systems programming language, thanks to all the incredible optimization work which has gone into JavaScript engines, but the performance ceiling of a language like JS is much much lower than that of system programming languages. For instance, if you are optimizing for memory cache performance C or Rust or Zig are going to have tools which just don't exist in JS. There's a reason that HPC - one of the computing fields where profitability literally depends on speed - is all implemented in C and C++.

And not that it matters but I've got plenty of experience with languages. I've been doing software engineering professionally for over a decade, and I've shipped professional projects in probably a half dozen languages or more including C, Rust, and Javascript. I've also done my fair share of programming in the systems domain, including computer graphics and games. I've also implemented programming languages of my own.

> you can't seem to wrap your mind around the idea that there isn't some niche where Zig is perfect and unassailable or the only alternative is rust.

I never said Zig fits a perfect niche. I said the theory of the language is valid, and it's a worthwhile contribution to the field. Zig, like all other languages, is an experiment. It's actually quite an interesting one with different goals than a lot of the other popular languages out there, and which is very appealing for the systems programming domain. I'm arguing against the idea that Zig is "irresponsible", which is an extreme position.

I keep bringing up rust because of you guys insistence that Rust is a counter-example to the idea that a new systems programming language not necessarily be memory safe. For instance this comment:

> We can't ignore the fact that Rust has shown that memory safety is not incompatible with low-level semantics.

Seems to imply that Rust's existence unto itself is proof that every new systems programming language must be memory safe.

C is the current standards bearer for systems programming. Everyone is trying to invent a "better C". Go and Nim are trying to do it with garbage collection. Rust is trying to do it with the borrow checker. Zim is trying to do it with ruthless simplicity and explicitness.

All of these are experiments, and all of them are valid. 20 years from now we'll know a lot more about what works and what doesn't from each of these experiments, but it's too early to conclude that now.

I think you're actively hurting the project that you care about in your ineffective crusade, but hey, don't let me stop you.

> However, what I've seen in the discourse of several programmers that claim to prefer Zig is the assumption that Rust is "not really that big of a deal". There's a constant minimization of the advancements both the ownership system and the safety approach provide, and a lack of recognition for the fact that the language is a "game changer" in the industry.

I think you have inadvertently worded this in a way that silently confirms what the parent poster was saying. But more generally, while I can't speak for the entirety of the Zig community, the people involved with Zig directly tend to be aware of Rust's strengths. The problem is that one of the reasons why Zig exists (and is having some level of success) is because some people just don't want to deal with abstraction-heavy code. Some people value simplicity over a complex language with a memory-safe subset.

And the value of simplicity is not just a matter of aesthetics. Simplicity is a defense against bugs, because memory safety is not the end goal, correctness is.

https://twitter.com/croloris/status/1568342336580755456