Game Jam 2 Results

This is an extremely vague claim with so many caveats that it doesn't end up meaning anything yet if you state it confidently you might fool idiots into thinking you said something consequential.

It'd be great if there was all the real competition you seem imagine for Rust, but we don't see that. What we see are people pretending that it doesn't matter if they produce crap software using unsafe languages, but their customers are starting to notice.

@pron I was with you before: I think pcwaltons' take on zig is ... Err, unduly negative to the point of rudeness and closed minded — and kinda paints a clear picture for why we're seeing all of the defensiveness in twitter from andrewkelly and the zig folks.

But — I think you're coming into it similarly here against Rust. Unnecessarily rude, antagonistic, and on technical points: closed minded.

@pcwalton The zig team feels they've made good pragmatic choices around memory safety? Cool. Leave a few reasons why it's different from/and why rust took another approach and your take. Dope.

@pron The Rust folk are happy and proud of the inroads they've made in adoption. Dope. Sure, there's different ways to slice the numbers and you feel what? They've taken unearned pride in their work?

I'm a fan of all of your work, but man. This thread has been disheartening.

Actually, out of job postings, which, however imperfect, is the best metric we have: https://www.devjobsscanner.com/blog/top-8-most-demanded-lang...

The numbers are in line with older numbers (i.e. showing some growth), obtained by other people: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/

> Oh yeah, I guess Objective-C peaked in 1993, Python peaked in 2001, and Java, PHP, Ruby and JavaScript peaked in 2005.

Objective-C is irrelevant (as its adoption is tied to that of another product, kind of like VBA), and with the exception of Python, pretty much yes (I said neared or reached, not reached). Other than Python, no language showed surprising growth after a decade, including C (1983) and C++ (1995).

> but it will steadily entrench itself as foundational building block of everything that surrounds you, as it has already started.

The evidence suggests otherwise, but things could change. I'm not saying Rust will never succeed, just that current performance and the historical trend don't bode well. Of course, other languages -- Zig, Odin, JAI, and those that don't exist yet -- will also enter the game, and it's not unreasonable to expect that the low-level programming world will experience a similar fragmentation to that of the applications world, where no new language is particularly dominant.

I think it is quite possible that Rust will achieve similar success in the low-level world as Go reached in the applications world. Anything beyond that is not out of the realm of possibility, but there are no current indicators to support that. Rust's adoption rate, in its target domain, is -- today -- lower than that of languages that have achieved unusual popularity in that domain or in others.

> to bash the language

I don't bash the language at all. I bash unfounded claims about it, such as those made in this discussion: that it's achieved extreme success, that all other designs are "fringe", and that it's well established as the best way to achieve correctness. None of these things are known to be true. As for the language itself, I find it too complex and reliant on implicitness for my taste, but I've said over and over that that design is certain to appeal to others. Moreover, I think Rust's "grand idea" of the borrow checker and type-checked lifetimes is nothing short of genius, although I wish it came in a simpler language.

I also don't understand people who become so attached to languages that they deny reality. Clojure is one of my favourite languages, but it's silly to deny that its adoption is low; obviously, it's not many people's cup of tea. I find TLA+ to be one the most useful tools for me, but clearly many don't. I don't understand why people who like Rust need make believe that it's doing well, inevitable, or the only reasonable choice, when the truth -- as we know it today -- is that it's none of those things, yet that shouldn't stop anyone from enjoying it, just as Clojure or TLA+'s lack of popularity has no impact on my enjoying them. Why can't people say, "I use Rust because I enjoy it, I find it convenient, useful, interesting, and beautiful?" Why the need to also make up stuff about it?

> that they spent such a significant amount of their comment activity on HN

This one gave me pause, but I think you'll find that what mostly triggers my HN comments is not so much Rust but claims related to software correctness. I've spent years on this subject, I care deeply about it, and misleading claims about it abound. It's just that recently they've been coming with great frequency from Rust folk (just as before we heard similar claims about Haskell, that triggered me just as much). Sadly, we don't know the most effective approach (or, more likely, a combination of approaches) for software correctness, and incorrect claims to the contrary drive me crazy. It is such a complex topic, with often surprising and perhaps unintuitive realisations (Tony Hoare was certainly surprised and changed his mind on some matters), and the truth is that we simply don't know whether an approach like Rust's or like Zig's lead to more correct software than the other.

That sounds an awful lot like bypassing the borrow checker.

> As far as I know Zig can't say well these two functions can run in parallel because they are at compile time guaranteed to never access same resources and it's impossible to bypass it (outside unsafe). And their content is thread-safe based on the type they satisfy.

Yeah but that's the point. Rust has one way of guaranteeing that two pieces of code don't mutate the same memory at compile time, but that's not the only way to write a correct program which guarantees that. Rust is going to force you to write your program in a certain way to achieve this. There are many other approaches you may be able to use in an unrestricted language which reach a correct and potentially more performant result which are correct, but which rustc cannot verify are correct.

> Douglas Crockford made a good case that every language should on some level try to prevent errors.

That's one opinion. There are many who disagree.

> Python is also older than Java, but even Python is memory safe (GC). Zig and new batch of better C aren't. In that way we definitely regressed.

That's not even an argument. It takes it for granted that lack of memory safety in a systems language is "a regression". That's not an established consensus.

> If that is truly the case we'd be all programming in Excel and Access.

How exactly do you come to the conclusion that Excel and Access are better at delivering value than other programming languages?

> Anything can deliver value, question is - can it be maintained, and at what cost.

Yeah exactly. The point is which language can deliver the most user value in your desired use-case at the least cost. For something like an operating system, where reliability is paramount, it may be a good tradeoff to use something like Rust which is unergonomic and slow to compile because the safety and correctness tools contribute to your use-case directly.

For something like a web front-end project, you're probably not going to choose Rust since it's going to be hard to find enough programmers who are willing or able to get over the Rust learning curve, and Rust's USP's don't do a lot for you.

For something like game-dev, where 30% of what you're doing is thinking about memory layouts, Rust's tradeoffs are actively working against you, and you might appreciate the faster code/build/run loop offered by something like Zig.

As to "crap software", most of application software these days -- crappy or excellent -- is written in safe languages, and nearly all low-level code is written in unsafe languages, including some of the world's most dependable software, from avionics to OSes. We can say with close to certainty that we can do better than C, but we can also say that full soundness (Idris) is not the answer, so the sweet spot is obviously somewhere in the middle. But we really don't know where exactly -- except that it's not at either end -- or even how wide the sweet spot is (or maybe there are multiple ones, which could be either universally equivalent or dependent on some variables).

There's more we don't know about software correctness than what we know -- it's extremely complicated and affected by factors ranging from formal languages and complexity theory to management, economics, psychology, and social psychology -- but we believe noe that the ideas of the 1970s of full soundness being the only path have proven wrong (including an acknowledgment even by Tony Hoare [1]), and, indeed, Rust doesn't adopt soundness fully, and relies on testing, code reviews and other unsound processes as the main means for correctness, like virtually all mainstream programming languages.

Anyone who cares about correctness (like me -- https://pron.github.io) knows to be very skeptical of any claims for absolute answers, let alone simple ones, on that extremely complex subject.

[1]: http://176.9.41.242/docs/math/1996-hoare.pdf