While I agree with most of your points, I am not sure what this has to do with the parent you're replying to.

The one part I disagree with is:

> A lot of these things do find some modest niche to survive in. But none really take over the world as originally forecast by the hype wave.

One of Blow's critique of C++ is specifically that it's trying to be the everything language. Jai's goal is to be for video game development, and that's it. Not for embedded systems, not kernels, not drivers, not high performance computing, not operating systems. Just video games.

It's false, he never said that it was only for games.

But the decisions made are going to be for the benefit of game development first, and everything else secondarily.

Either the word "only" is doing a lot of heavy lifting in your sentence, or you're simply wrong [0].

Yes you could program anything in the language, just like you could programming anything in any language. But he's designing the language for video game development. The whole reason he's making it is for videos specifically, and he's been very explicit that he does believe that a language should not try to be designed for use in every application.

[0]: https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1...

I mean this is a little pedantic. It's true he never said that only games are able to use his language as if it were some kind of law, but he did say that his language is being designed to address issues that video game developers face and that was his main, and almost exclusively his only concern.

If other domains benefit from that, he's not going to actively bar them from using his language, but he also won't give them much consideration.

It's just false, i'm in the closed beta and there are a lot of people that use it for other things than games. When they find a bug or have a suggestion he give them the same consideration as anyone.

What people use it for and what it's meant for are two different things.

I was surprised to recently learn that embedded isn't on Jai's roadmap. I respect the decision re scope and feature-creep. It was surprising, given that usually languages with the performance, and low-level capabilities of C are also suited for embedded. Ie: The overlap with existing languages is almost 100% when you look at A: Languages that are fast/LL. B: Languages that are suitable for embedded. (The usual suspects of C, C++, Rust, Zig, and ADA)

I imagine that part of that is that he's a video game developer and not an embedded systems developer. I have no experience with embedded systems programming so idk how similar the two are.

But:

1) Lots of things things have high overlap with fast/LL languages.

2) I imagine there are nice returns to focusing the language on a specific use-case, even more so when the core developers are not actively using it for the other use cases (I doubt he or his team will be doing embedded work anytime soon).

I’ve also observed these waves, but never about a language that you can’t actually go pick up a compiler or interpreter for. Jai is unique in that sense.

Who’s actually getting into these closed betas?

People that have an interesting projects for stress testing the langage.

You don't think JavaScript is widely used in day jobs?

Go as well seems to be pretty big nowadays.

I'm starting to actually believe that Rust will eat C's lunch for systems programming.

Lets see if it has better luck than C++ on domains that don't care about anything beyond C89, and compiler extensions.

People have been believing that for close to a decade now.

Yup, and it keeps steadily winning a small stream of converts and additional projects from C.

So I didn't believe it before, but it's starting to seem more plausible.

Of course, it'll take a very long time. There's a lot of C code out there. :D

Well, I wouldn't mind. Personally I had to start a new C project just the other day. :/

And now there’s Rust in the Linux kernel

The disparity between Rust jobs and C/C++/C#/Java/Golang jobs on Indeed is staggering. Even worse, most of the Rust jobs are blockchain-related and may not survive the coming blockchain downturn.

It may be the case that some people use Rust but without Rust jobs, there will be no pool of experienced developers to later draw on.

Hasn't the downturn already happened?

> The disparity between Rust jobs and C/C++/C#/Java/Golang jobs on Indeed is staggering.

Most of the world are things other than real systems programming. C++/C#/Java/Golang are likely better choices for this than either C or Rust.

But a C-like language is necessary. Rust may be (very slowly) displacing C for systems programming.

As you mention, it takes awhile for the pool of experienced developers to show up.

AFAICT most Rust jobs don’t require previous experience in the language.

Anecdote: My company is a nearly 100% Rust shop and we have never made it a job requirement.

I think there is a space for other alternative low-level languages that aren't that strict about compile-time safety though (Zig, Jai, Odin), that Rust cannot capture.

Many proclaim that compile-time safety using type theory is the only way to create reliable low-level software, but I think it can alternatively be done with good data structure design and various compiler tooling that instead catch these errors at runtime (generational indices/references, Address Sanitizer, and recently Zig's safety mode). We need to explore multiple directions to really solve the memory safety problem, and I don't think Rust is the only way (although it is a viable way, proven by some recent successful applications).

You can even get safety using logic without the compiler. I think resource cleanup responsibility tracking as a static analysis tool is likely to happen with some of these languages. I think zig is a good candidate, once they lock down the intermediate representation.

It's already the case that people are using "logic add-ons" for additional rust static analysis, so one wonders exactly why is it generally speaking that borrow checking itself must occur at the compilation step.

Trivially, one could create an annotation layer on top of zig or c that exactly replicates the rust syntax and performance borrow checking in the same way. It wouldn't be exactly the same because there isn't RAII but you can make correct inferences about what is happening in the body of the functions.

Rust will not accomplish this without significant language changes as well as changing cargo into something a lot more cooperative with external ecosystems.

Zig is getting an absolutely enormous boost from the fact that it is a self-contained C ecosystem that can cooperate with others. Zig has tripped into a very powerful niche--a lot of people LOATHE the build systems of the C/C++ world. If Zig gains very much more traction there, it's going to be extremely hard to dislodge.

I suspect that there are FAR more users of "Zig as C build system" than there are of "Zig as a language".

Cargo isn’t part of Rust (the language) and you can use Rust without using Cargo.

And yet cargo-raze still requires cargo and is still experimental after 5+ years of development effort by folks from Google.

It is my fondest hope that the Linux folks will finally beat the cargo out of Rust.

> beat the cargo out of Rust

But cargo already isn’t in Rust. There are AFAIK no cargo-specific concepts that have leaked into Rust, the language. It is very straightforward to build Rust code without using cargo, for example with a makefile.

The reason other tools are slow to add support for rust is because cargo is so ubiquitous in the rust ecosystem that there is little point (I’d estimate that >99% of Rust code is built using Cargo), and not because of any technical impossibility.

I highly doubt so. Rust is extremely complex and restrictive. For actually critical software, there is Ada/SPARK.

Rust is much easier and less complex than C++, which is very widely used.

Very doubtful. My impression is that devs coming from non-C++ background are having a hard time to grasp the concepts of Rust.

Maybe, but they are both very complex. Perhaps Rust will eat C++, but not C.

Javascript absolutely took its position. Speaking of those waves, where did Ruby and RoR go? Seems completely dead on HN whereas 'back in the day' it was top most talked thing. LISP would be a guest of honor - always there, never here.

Ruby/RoR values form over function. Over the past few (five or so?) years, as teams went through the transition from aggressive feature development to devoting more effort to maintenance and operations, they realized that relying on conventions as a guiding principle has a substantial cost burden that you don't pay when prefer rigor and specification.

I think Ruby and RoR just didn’t quite survive the transition to much heavier client-side JavaScript apps. Ruby peaked sometime around 2009 and back then, the browser landscape was much more diverse, and it was common to support IE6. It’s easy to forget how much of a burden IE6 was on web developers.

Ruby also suffered from a proliferation of ill-advised programming practices (monkey patching) and there was also some drama in the Ruby community (Rails Is a Ghetto). These were fixable problems and the Ruby community took steps to stop monkey patching everything and maybe address the other problems, but in the end, I think would-be Rails developers started using Node.js, and Ruby fell from the public spotlight.

As far as I can tell, Python survived by virtue of tools like NumPy, SciPy, Pandas, PyTorch, OpenCV, etc. Kind of a universal glue language for people who don’t want to write C or C++. Otherwise, I think of Python and Ruby (as languages) as nearly interchangeable. Python had its own issues to work through (2 -> 3) and its own drama, but it settled in some more stable niches and seemed to have fewer mercurial personalities at the center of it all.

Ruby and Python is not interchangeable, and Ruby is way more powerful than Python, that's a real reason why there is no equivalent of RoR in Python eco-system [1].

Python becomes very popular not by virtue of its tools, but by virtue of its intuitive and beginner friendly syntax. Because of this essential trait the useful tools and libraries are flourishing in the Python eco-system.

You are right that RoR is like a Ghetto and RoR is not considered as Ruby language. On this aspect, I think D has done a good job to ensure that any D based library and framework will still resemble D language. Like they said with great power comes great responsibility, and I'm afraid that Jai will follow Ruby and Lisp becoming untouchable by the mere mortals except only for a selected few domain expert programmers maintaining very niche applications.

[1]Stop Designing Languages. Write Libraries Instead:

http://lbstanza.org/purpose_of_programming_languages.html

I transitioned from Ruby to Python for scripting tasks, with a heavy heart, for the simple reason that linuxes typically have Python installed by default, but not Ruby, which made working with and sharing Ruby code in diverse and often locked-down environments too painful.

> linuxes typically have Python installed by default, but not Ruby

interesting, i wonder why?

I always look for practical application.

I think cutting through the hype-train is something every engineer learns with time, but some times there are diamonds to be picked out.

At least for my own anecdotal experience, Rust has lived up to a lot of the hype for the time-critical low-level projects I was formerly performing with C/C++.

Agreed, though I’m sad it isn’t more often used. It’s certainly picking up steam, but it seems to have a ways to go before it’s going to be a serious contender for new projects in the embedded, video game, etc spaces where C/C++ still reign (by which I mean something like “before the majority of new projects are implemented in Rust”).

> at our Java/C#/Python/C++ day jobs.

I'm sorry, I don't speak corporate. /s

No but seriously who starts a new codebase in Java? Kotlin is vastly superior and has enough critical mass.

Go is also good.

And Python for anything else then scripting / glue code? Might as well just go with Node at that point (at least you can use Typescript).

I don’t think Go was ever especially over-hyped, and it has been pretty wildly successful in its “niche” (server side programming, CLI tools, daemons, etc). There was some controversy because someone said it was for “systems programming” by which the author seems to have meant “distributed/networked systems” rather than “operating systems” or whatever most people mean when they use the (very imprecise) term “systems programming”.

And to that extent, Go has been very successful (virtually the entire container ecosystem and a good chunk of the broader cloud ecosystem). It is doing a lot of stuff that would have previously been in Java or C# or Python or Node or Ruby (contrary to your “hardly anyone is actually using anything else…” remark).

Of course, older languages are naturally going to have more jobs because there’s an enormous volume of legacy code that can’t be cheaply translated to a new language, but so you have to look at the distribution of languages among new projects to be able to even begin making reasonable comparisons between languages, and even then a historically Java shop is probably going to give a ton of preference to Java, so here too we see a lot of weight given to older languages irrespective of their merit.

"virtually the entire container ecosystem"

An entire area of software that is completely unnecessary, but because the gods at Google gifted it to us, people have to pretend it's amazing

Of course, this is nonsense and people use containers because they deliver real value, not because of Google marketing or name recognition (most don’t even know containers come from Google, but would likely attribute them to Docker). I’m not a container purist—eventually micro VMs and unikernels will eat a lot of their market share (that’s my prediction, anyway), but until we get there containers are invaluable and criticism like yours is devoid of substance.