[ilovecaching]

As a systems programmer any mention of the word Haskell next to the word Rust sends shivers down my spine. Haskell is the king of yak shaving abstractions and is almost the polar opposite in all the ways that made C the most practically successful language on the earth.

I do not want abstractions where they aren't needed. I want control, simplicity, a clear correspondence between what I'm writing and what logical assembly I'll be generating (logical, not physical). Most of all I want my code to be stupidly clear to the next person reading it. Systems programming isn't like writing a Java app, the domain is complicated enough that there's no room for abstraction astronauts to create problems where there are none.

I am still very wary of Rust. I have used it and will continue to use it, but it still teeters on being too complicated to be useful in the same way as C.

[Ericson2314]

I've helped write some very abstract combinator-y Rust that compiled down to an embedded program that runs with only 4K RAM. Get over it.

> and what logical assembly I'll be generating

The problem with Rust and C is not worrying about what assembly I'll get, it is that one has very little control over the layout of the stack. It's the last implicit data structure and that's a PITA for highly resource constrained programming.

[ilovecaching]

With all due respect, writing one program with a small memory footprint doesn't disprove my point. I'm referring to writing very large, complex programs that interact directly with hardware - kernels, boot loaders, firmware, all of which must be as clear as possible. And I say this with many years of experience dealing with other companies badly written device drivers and firmware.

I absolutely need to worry about what assembly I get. I am often checking my assembly or looking for optimizations in my assembly. And I'm doing this across multiple architectures.

[Ericson2314]

> I'm referring to writing very large, complex programs

Then the power of good abstractions should be all the more useful!

> that interact directly with hardware

OK if you are using various privileged instructions, writing things with weird calling conventions like interrupt handlers, etc. Then the assembly matters.

But, and this may sound heretical, this stuff is the boundary of the lower level code; its interface with the hardware. For the interior, the precise assembly once again doesn't matter.

> And I say this with many years of experience dealing with other companies badly written device drivers and firmware.

There is a lot of crap low level code out there, yes. And I would say a chief mistake of crap code is not properly respecting layers of abstraction. The low level world needs more http://langsec.org/ where we precisely and mechanistically document the interface, rather than half-assing it with reference implementations.

Just as user space weird instructions get intrinsics exposed to spare the user from writing inline assembly, libraries like https://docs.rs/x86/latest/x86/ should be maintained the device manufacturer or ISA consortium. They should be unit-tested with an emulator too.

We properly do all this legwork to fix the foundation, and the rest of the low-level software will practical write itself, compared to today, and be accessible to a much larger pool of programmers.

[kilgnad]

Rust is the bastard child of C++ and Haskell.

So it doesn't have the simplicity of C, it tries to give you as many abstractions as possible while still maintaining the zero cost philosophy.

I would say Rust is easier then C++ and easier haskell.

[ilovecaching]

Being easier than C++ or Haskell isn't really saying much at all. Neither of them have improved code readability and are notorious for their learning curve.

[kilgnad]

It is saying a lot because no other language offers that combination of performance and high level abstraction.

The speed of C++ with high level language features of haskell. And none of the safety pitfalls of C++ either. That's a lot.

When compared with haskell the benefits aren't clear. When compared with C++, rust is clearly better when viewed from strictly a language standpoint.

[ilovecaching]

But C++ is an outlier in systems software. Systemd is written in C. Grub is written in C. The Linux kernel is written in C. Firmware is written in C. Sure there are some kernels that use a bit of C++, but it's an outlier, not the norm. C++ never proved the is was so worthwhile to have a higher level language that we should drop everything and write C++. C++ only dominates in performance critical applications where there is a bridge to higher level languages and you're interfacing with software.

The strongest argument for Rust is its safety features. Abstractions have made C++ an unusable mess that even C++ developers complain about on a constant basis.

[kilgnad]

No C++ is considered systems software. I largely agree with you, except on the fact that C++ is an outlier in systems software. It's only an outlier for GNU linux.