Hacker News Reader

Comment by marcosdumay | Hacker News Reader

Not long ago surgeons didn't have a rule of washing their hands before doing an intrusive surgery, and lots and lots of people died because of that.

At a point, one surgeon discovered that, with incontestable proof, and started advocating for hand-washing. When almost all surgeons noticed that something so simple and easy had that much impact, they immediately adopted it and saved a lot of suffering from their patients...

Ok, of course they didn't. Almost everybody fought the few wand-washing advocates, tried to shame and discredit them, tried to generate bullshit evidence saying that it didn't help, tried to convince everybody that it didn't matter, all the time denying to themselves that it worked. Surgeons only started washing unanimously their hands when that generation of them retired.

View on HN

https://en.wikipedia.org/wiki/Ignaz_Semmelweis

> Despite various publications of results where hand-washing reduced mortality to below 2%, Semmelweis's observations conflicted with the established scientific and medical opinions of the time and his ideas were rejected by the medical community. He could offer no theoretical explanation for his findings of reduced mortality due to hand-washing, and some doctors were offended at the suggestion that they should wash their hands and mocked him for it. In 1865, the increasingly outspoken Semmelweis allegedly suffered a nervous breakdown and was committed to an asylum by his colleagues. [...] His findings earned widespread acceptance only years after his death, when Louis Pasteur confirmed the germ theory, giving Semmelweis' observations a theoretical explanation, and Joseph Lister, acting on Pasteur's research, practised and operated using hygienic methods, with great success.

This analogy seems pretty disingenuous. Static memory safety isn't an unambiguous good like handwashing; it has tradeoffs. There are many projects where control over memory is critically important and using a language like Rust is a non-starter. Also, the implication that developers who don't switch to Rust are negligently harming people is unnecessarily moralistic and divisive.

You're right overall. But I don't think there's any project that needs control over memory that Rust can't provide. Maybe you mean it would be inconvenient and not provide significant benefit?

>There are many projects where control over memory is critically important and using a language like Rust is a non-starter

I am not very familiar with Rust, but I thought it permits full control over memory?

Only if you use unsafe and even then three are restrictions. The general idea of rust is that it will only let you do things it can verify are safe otherwise it won't compile.

> Only if you use unsafe and even then three are restrictions.

I can't think of any. The borrow checker still checks your code but you can forge, twiddle, and cast pointers, there's really nothing you can't do that I can think of.

From https://github.com/itfanr/rust-doc-en/blob/master/unsafe.md#...

> In both unsafe functions and unsafe blocks, Rust will let you do three things that you normally can not do. Just three. Here they are:

> Access or update a static mutable variable. Dereference a raw pointer. Call unsafe functions. This is the most powerful ability. That’s it. It’s important that unsafe does not, for example, ‘turn off the borrow checker’. Adding unsafe to some random Rust code doesn’t change its semantics, it won’t start accepting anything. But it will let you write things that do break some of the rules.

That doesn't change anything I said. Those unsafe functions include things like casting pointers. There's nothing you can't do through some composition of those 3 things.

Yes. It allows for more control over memory than C, where a lot of things are undefined behavior.

"More control over memory than C" is nonsense. C allows you to do anything the machine's instruction set is capable of, all the way down to inline assembly.

Undefined behavior is a completely separate conversation. UB is necessary to output performant code. If dereferencing a null pointer were defined behavior, then the compiler would need to insert a check for every dereference, which would slow down your code.

> C allows you to do anything the machine's instruction set is capable of

Hum, no, unless you count inline asm, it simply doesn't.

And for more control over memory than C, Rust allows mapping high-level types into fixed memory, so the compiler can actually use the correct asm primitives and make your access fast. On C you either have to use a general purpose array abstraction or try to map your types over the memory and pray the compiler resolves all the UB the way you want. Most C developers do the later.

I have no idea what you're talking about with "general purpose array abstraction" and "map your types over the memory". A struct in C is just a fixed size chunk of memory where the fields have a fixed offset. Access is a simple memory read/write. An array in C is also just a chunk of memory, where subscripting is some simple pointer math. There is no UB involved. If you could give a concrete example of what you're talking about and why it's better in Rust than in C, that might be helpful.

Projects where you need to think about memory are a pretty small percentage of projects. Even on embedded systems, I wouldn't be surprised if there comes a time when nobody even knows what a register is.

For projects where you do need rust, obviously "This is literally impossible to do any other way" takes precedence over "It's best practice to do it this way", but the rest of the time.... I'm not sure I see the tradeoffs unless you're doing some crazy hand optimized low level library, or you just have a strong preference for direct control.

The existence of Redox OS in my mind is enough to prove that Rust can do just about anything and lower level stuff is needed less than people seem to think

Then again, I haven't worked much with Rust, it's only just now supported on any platforms where I'd have a reason to use something lower than JS/Python.

>Projects where you need to think about memory are a pretty small percentage of projects.

Performance matters in every project, and the way you get performance on modern processors is by using the cache effectively. That requires a certain amount of control over memory layout and access.

It's not so much about what's possible in a given language, it's about what features you're using and what features are getting in the way. Sure, you can write a bunch of unsafe Rust, but at what point are you fighting against the language and adding unnecessary friction?

The way you get performance on modern processors is to use libraries that use the cache effectively for the stuff that actually eats CPU.

High level languages are good at enabling high level optimizations like caching and special case handling of things, which might be a bigger gain than anything to do with memory layouts except in a few inner loops.

High performance and reasonably focused low complexity stuff might be a good fit for C, until compilers get even better.

But in a web browser? I guess time will tell, but my guess is the ability to more effectively manage complexity will let people do more high level optimizations with less fear of buffer overflows from more code.

Things like "In this specific case I can fall back to this very simple plaintext rendering for this one section" might save more CPU than "We made all rendering a bit faster" especially if you just keep doing the performance critical stuff in C.

(And put him into a psychiatric ward and beat him to death..)

That is a story to fit a theory. Generations in a profession are not discrete units it is made of a blend of people born every year between the eldest and youngest.

Those that fought against a new idea are colleges of those that fought for an idea and colleges of those that are ambivalent to the idea

Reply on news.ycombinator.com