New leadership for Asahi Linux

Nobody claims that you can implement RCU or spinlocks in safe Rust.

>I will point out that every time it is some silly mistake.

In Rust most of these silly mistakes are impossible to do. That's the point.

>Almost always a localized and simple fix will do.

Not having to do a fix, because nothing is broken, will do better.

>Telling people what they have been doing for their entire career is hopelessly broken, is not a selling point

Sure. People tend to not like changes.

>They know what they have been doing gets the job done.

... with a steady stream of security issues.
If you can accept that then yes, C gets the job done.

>but then it's type system sees an unsafe and bows out.

unsafe blocks don't disable any of the type, borrow and safety checks.

>I haven't seen anything in Rust beyond it's type system that can be used to catch
>the rare mistakes conscientious people make.

Sure. But that's just because you didn't look. Not because they don't exist.

Which data structures Rust doesn't allow to be modeled (perhaps with a bit of `unsafe` inside the implementation)?

> My second statement ( "C is good enough") is about practical utility. In the common cases. In the cases where nobody cares about security.

No. C is not "good enough". It's downright dangerous. At this point, merely using C for new projects should be considered bordering on criminal negligence.

> I will point out that every time it is some silly mistake. An off by one error, or not getting error handling quite right. Overall code paths that don't matter for what people are trying to do. Almost always a localized and simple fix will do.

Yeah. And that's how we get airplanes crashes and nuclear reactor blowups. This attitude is just distilled nonsense and sheer arrogant ignorance.

The single greatest advantage in the safety science was the recognition that humans can't help but make mistakes, and that measures should be taken to make these mistakes impossible: LOTOs, automatic safety interlocks, etc. So every other engineering discipline (including the ones that are much younger than Computer Science) has adopted tools that reduce the possibility and the impact of "silly mistakes". Even non-engineering disciplines are doing that.

The latest advantage that drastically reduced the death rate in surgeries was not some kind of tricorder powered by AI, but simple checklists: https://en.wikipedia.org/wiki/WHO_Surgical_Safety_Checklist

Do you have any existing examples of this actually happening in any language, nevermind C? Maybe Erlang-based deployments at telcos (depending on your definition of "update")? But I can't think of any C program that has been "on the Internet for decades without updating" while also being "secure". Unless maybe you're counting `/bin/true` as "on the Internet"?

And I agree that machine validation is required for further trust in software. But Rust is not only more easily tooled (because its source just has more information than C does), but *has* better tooling in almost every dimension that matters (sure, UBSan is "better" for C than Miri is for Rust given Miri's limitations, but its need for such a tool is also *far far* lower).

No, I do not see a problem with characters serving different purposes simultaneously.

In ML it's a type variable, representing an unspecified type that will be determined via type inference when the value is instantiated (I think). Basically the same as T in C++ templates. In Rust it's a similar idea, but just for the lifetime component of a type. The Rust compiler was originally written in OCaml, so they would have been familiar with that syntax.

However, it turns out ML had nothing to do with it. Until Rust 0.6 they used "&a/foo" instead of "&'a foo", but they weren't happy with that: https://smallcultfollowing.com/babysteps/blog/2012/12/30/... . That blog post suggested several options including "&{a}". Someone on Reddit suggested "&{'a}", to make the syntax less ambiguous. Graydon Hoare thought the braces were ugly (https://web.archive.org/web/20140716163946/https://mail.m...), so they settled on "&'a".

The use of the same syntax for loop labels is not a coincidence: the original idea was that loop labels were actually lifetimes, and you could write " 'a: { let x: &'a T = ...; }" to explicitly tie a variable's lifetime to a block (https://web.archive.org/web/20140716182842/https://mail.m...). That didn't happen, so now the loop labels are only used for control flow and exist in a different namespace to lifetimes.

That is another character where a handful of other languages (sh, perl) and documentation-related formats have popularized symmetric use. So, personally, no, I would not use `.
The goal is not to make use of every symbol that's on the keyboard (hey, remember Perl?) and looks like a mathematician's scribblings, but to make a program that's amenable, to others, as well as oneself 10 years down the line. C# and Python's use of keywords appear like a nice idea, e.g. "f(ref int x)" and "for i in stuff", respectively.

Then you need to spend effort to *understand* it, and only then return to critique.

Put it more bluntly: the fact that the language in question has concepts that you do not understand (some of which come with their own syntax) is not a language problem, it is a you problem.

C is not the pinnacle of programming languages, and therefore it is unreasonable to assume that a person who is proficient in C is automatically proficient in everything else (from which it follows that if "something else" gives you trouble, then it must be a problem with "something else," because you assume that you are proficient by default). If you disown this fallacious assumption, everything else falls into place.

I don't know Rust either and am not a C developer, but I thank you for taking the time to be open and vulnerable (in that by admitting you don't understand you open yourself to critique in the nature of "you 'just' need to get good") about the learning process. You can often get the jist skimming a language you don't know, eg. the other day I was curious how Oxidized network device backup handled a few platforms, but I could follow along well enough even though I couldn't do a variable assignment in Ruby without checking the documentation, but that's not really true of Rust as I've seen a number of code examples posted of various things and I don't get the jist at all, even though I do believe the people who are very passionate about the benefits of Rust, I'd need to spend a _lot_ more focused attention to be able to even skim read it let alone write in it.

Not every person is willing to learn something radically new that makes them a beginner again where they put themselves in a position to need help from or get critiqued for beginner mistakes by less senior people who have less experience in their area of expertise, when they can continue to be the trusted expert that other people look up to. Someone a long time ago noted that progress happens "one funeral at a time" but many people do learn and grow with the changing world, its *notable* when they don't.

I said in another thread that what is needed is a kernel-focused targeted training to on-board seasoned C developers who are thinking in machine or assembly language and how the underlying hardware works because the mental models are quite different, and the kinds of tasks/operations needed by an application developer using the standard library and an OS kernel developer using the kernel internal library are vastly different. Kernel developers are going to need to understand how to design and audit an unsafe block to bang on memory and implement something other code can use in a way that an application developer can just abstract away and use a standard library function or some common 3rdparty crate. This training would be best delivered where everyone can see it on the mailing list or some other mechanism that puts it where the people are, because expecting busy people to get hyped enough for totally self-directed training is not a reasonable assumption, you have to meet them where they are if you want to effectively advocate for change. Loudly proclaiming "I'm right, you're wrong, get with the program!" *even* and *especially* when you ARE right and they ARE wrong isn't an effective mechanism to get them to understand why and then advocate for the change themselves, especially when you don't give people time to _understand_ and just want them to believe you.

Like, if you want to convince wtarreau that Rust is the best thing since beer (and given the number of thoughtful competent people who are passionate about it, it probably is) then you need to *show* them and understand that they are a _beginner_ at Rust but not to computing and make your examples accordingly. If you get feedback that something was difficult to understand then you should *believe* them and not argue about their own experience, that is entirely foolish, but instead interrogate why it might be difficult for someone with a different background, empathize with them and try to learn from their experience. Just saying the same things again louder like like they didn't hear you the first time is insulting to both and not effective, "Oh now that you implied I must be stupid if I didn't understand this right away I totally get it, thanks Internet person!" said no one ever.

Compared to something like Python (sans type annotations) there's definitly a lot of syntactical complexity, but the only things that aren't in C syntax are the bits associated with the angle brackets, and the only thing that's not in C++ is the lifetime annotation. And importantly, the syntactic elements that are used are conceptually very close to what they mean in C/C++ - & means a reference to something, Foo<Bar> means a generic type Foo containing a Bar, both of which match the usage from C/C++, everything else is pretty much a one-to-one match.

The structure of the function definition is obviously different, but if you can't adjust to that change ("oh, the return type is at the end of the signature instead of in front of it") then I think it's probably reasonable to say the problem isn't the programming language so much as the programmer . . .

For highly optimised machine code with no corresponding debugging information or source code, there's very little chance that back-translating to /any/ higher level language will give you the original human-written code - optimising compilers just don't work that way. Any non-trivial code will be transformed quite drastically from the original source - it'll be a lot simpler in some ways (because the compiler optimised away a bunch of unnecessary stuff) as well as a lot more complex (because the compiler was doing stuff like unrolling loops or doing automated vectorising and what not); it may even be significantly different structurally (reordering blocks is allowed as long as it doesn't change the behaviour within the constraints of the language spec). Occasionally it just won't even be there at all! Back-translation won't undo those changes, it'll just give you one possible higher level language implementation of whatever came out of the final optimisation pass.

If the target is C that implementation may resemble something that a human would write, though it's probably not going to be anywhere near idiomatic human written C code; if you're targeting Rust it'll probably be /very/ different to what a human would write. But in either case the result should be human /readable/ (if the back-translation is of a similar quality), which is surely what matters in this scenario?

And you'll probably get Rust code that's far simpler than what a human would write, though almost certainly a lot more verbose - it'll be missing all the bits of the language that make it more human friendly to write. I imagine the result would be a lot easier for a C programmer to read, in fact.

It's not on purpose. I mean the more I'm reading the articles, the more I'm feeling like there are different jobs and some don't understand why others just don't want to switch jobs. It's exactly like here in europe where you're considered to have failed if you do tech stuff all your life instead of becoming a manager to manage people despite having zero skills for that.

I think that there are people who are at ease with thinking at low levels, the same way other people are at ease in mechanics and a lot of similar stuff, and there are people more at ease at higher levels and relying on tools to abstract the underlying levels. Both are equally fine and needed. But just like no python developer is asked to learn to program PIC or AVR in assembly, python developers do not expect those programming the microcontroller in their alarm clock to learn python package dependencies. I don't see why there isn't the same type of cross-respect between people doing lower-level stuff in C and those doing higher-level stuff in Rust.

> The real question about memory safe languages adoption would be question of liability. After usual disclaimers about “lack of liability” would be deemed illegal… insurance companies would kill C very quickly. By simply offering sharply different prices for things written in C and things written in other, safer, languages.

Most of the work being done in C these days is only extending stuff that already exists, it's not about writing entirely new stuff. That makes dropping the language quite hard, as is currently seen in the kernel by the way.