[kubota]

Part of me loves the advent of so many zero-cost-abstraction languages. The other part wishes the systems programmers would pick a winner already so that the already small community of systems programmers do not end up multifurcated into even smaller communities of Rust, Zig, Val, etc developers. I hope the systems language wars end soon in other words.

[eska]

Maybe we picked one too early and didn’t have enough innovation in this area for too long. Bring the war :)

[packetlost]

I like Rust, but damn is it complicated and very heavy. I really just want C with namespaces, actual enums (tagged unions are a bonus), a "modern" type system, and proper package management. They all have their place, IMO it's not that hard to switch between languages.

[skywal_l]

https://ziglang.org/ ?

[pjmlp]

You're in luck, C++ covers that.

[dgb23]

I think when someone says „I want a C that’s cleaner and has some simple, generally loved features“ they don’t think of C++?

[pjmlp]

Probably not, but they should.

C already felt primitive in the mid-1990's, and by C++98 most of those features were available.

So they can use C++ for those fixes, with its JavaScript/TypeScript kind of symbiotic relationship for better or worse, or stick to C and keep waiting for such language, that will most likely require parsing include files with some kind of tooling.

[packetlost]

I didn't mention, but minimal is something I desire in a language too. Honestly, C++ is such a "design by committee" kitchen sink language that I have no interest in ever touching it. Yes, you can restrict yourself to a subset of the language, but then every time you need a library, or need to find some info on how to do something on SO or whatever, you have to deal with the rest of the language. You cannot simply ignore it because everyone else won't.

[pjmlp]

There is also a bit of committee on everything WG14 does since C89.

[csjh]

C++ has proper package management?

[pjmlp]

vcpkg and conan nowadays.

Not using one of them is making oneselfs live difficult on purpose.

[djbusby]

Not even a war, right tools for the job. I don't think it's possible for one language to rule them all. Options are good.

[VWWHFSfQ]

I think at this point Rust is the winner just because it's already overcome the incredible hurdles of being shipped in the Linux and Windows kernels themselves. In that regard, I doubt there's room for any more of these new systems languages now.

[bsaul]

I have the intuition that rust can’t possibly be the winner, it really feels too crude regarding the way it manages lifetimes. It really feels like the clumsy grandparent of the language that will indeed solve those problems elegantly.

[lolinder]

But we made do with C for how many years? OP's question isn't whether Rust is as good as systems languages will get, the question is whether any successor language stands a chance of being included in the kernels.

The bad ergonomics of C were never enough to get another language into the Linux kernel, it took a language that solves the number one class of security bugs. It's unclear that any successor to Rust will be able to show as clear a need.

[forrestthewoods]

> the question is whether any successor language stands a chance of being included in the kernels

Uhh no. No that is not “the question”.

My question is “what language will I use to write video games”. C++ sucks and Rust isn’t a great fit.

[omgmajk]

I guess Jai aims to move into the gamedev space of this, but the language has a terrible presence online

https://inductive.no/jai/

[forrestthewoods]

I wrote a large blog post about Jai. https://www.forrestthewoods.com/blog/learning-jai-via-advent...

It’s a very interesting language that does a lot of things “very right”. But it’s also a long ways from being broadly available.

[3836293648]

Rust is fine in an ecs engine like Bevy. Absolutely awful in traditional oop setups though.

[forrestthewoods]

Bevy is very cool and I follow it closely. It has yet to ship a meaningful project.

[aldanor]

Not sure what you mean by "traditional oop setups" and why anyone should care about it, that's more of an outdated design pattern and a bad choice of the past than a desired language feature.

[xwowsersx]

That's not how I read OP's question. OP was wondering whether a lang besides Rust can be "the winner" (unqualified) given that Rust has already passed the hurdle of being included in the kernel. It didn't sound like at all like their question was limited to whether there's room for another lang in the kernel.

[thfuran]

But isn't it worth spending a few years poking around before we lock ourselves into fifty more years of bad ergonomics, now that things have clearly reached the point where there's credible motion towards a C alternative?

[pornel]

Rust's lifetimes have a steep (un)learning curve, but once you know what you're doing, they're fine. Really. IMHO Rust has ergonomic problems around effects or generic numeric code, but not memory management.

AFAIK no silver bullet has been discovered yet that would be an improvement over Rust that doesn't have some other trade-off. Val's mutable value semantics is more local and limited. It "solves" the problem of ugly lifetime annotations by not supporting complex zero-cost lifetimes at all. That doesn't mean Val can't be successful — it can be easier to use by supporting simpler constructs and focusing less on zero-cost abstractions, like Swift, but its ideas aren't stop-the-presses for Rust.

We're already overdue for having a more modern, practical replacement for C. Waiting for a hypothetical better-than-Rust language will only mean staying with C for even longer.

[pjmlp]

Ada already existed, politics and a free beer compiler ecosystem also helped.

[kjs3]

But we made do with C for how many years?

K&R C was, what, 1972...and it's 2023 now. So that's 51 years with no definitive end of 'making do' in sight.

[germandiago]

Same opinion here. Let us look at Val and Vale.

There is also Carbon and CppFront but those are more of C++ evolution than new-born things.

[tormeh]

Like what happened with Java. Once a language has accumulated enough popularity it’s extremely hard to depose it, due to network effects. The switching costs are enormous.

[IlliOnato]

The role of Rust in the Linux kernel is so far extremely limited, it's more of an experiment than a production tool at the moment.

I don't think that the "window of opportunity" for another language in the kernel has closed. If anything, Rust has shown what would be the hurdles to overcome, so it may inform the next attempt if it happens.

And of course Linux is not the only kernel out there, and new kernels can also arise.

[chrisco255]

Won't happen. But all the more reason to expand wasm + wasi support everywhere.

[jjtheblunt]

Are those languages able to do low-level hardware things?

[chrisco255]

Wasm is WebAssembly, which has a nice compact set of instructions to compile to and network effects from being the 4th language of the web to ensure its staying power. WASI is a WASM system interface for connecting with hardware and other systems:

https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

[anyfoo]

It rather looks like WASI interfaces to code which is written in one of the other system programming languages that are the topic in this thread, so I guess the answer to the parent commenter's question is "no"? Am I misinterpreting this?

[chrisco255]

If you want to be pedantic, sure. The point is whether those interfaces are written in C or Go or Rust that they are interoperable, and a dev can write their core logic with a wasm compilation target in Zig, Val, or whatever other language comes up. Hardware and OS devs can write WASI modules in whatever language they prefer so that others can consume.

[anyfoo]

I don't think this is being pedantic. We here talk about languages like Rust, Val, and also C (which we attempt to replace) as languages to interface directly with the bare metal. Think device driver or a kernel itself.

To me it initially looks like WASI does not let you use WASM as a bare metal language (I don't know enough about WASM to judge whether that's even really sensible). Instead, you have a layer on the bare metal (or even several layers above) implemented otherwise, and then you can use WASM still further above, to interface to that layer.

But again, maybe I misunderstood.

[tracker1]

Not really, unless some future hardware supports such a beast, could be an interesting approach for AI/WebGPU interfaces.

It's more for service-oriented applications currently... you pass stuff in, get stuff out.