Hacker News Reader

Comment by 37ef_ced3 | Hacker News Reader

Complication without benefit.

Rust's popularity is pure mimesis. C is fine, but it's not the hot new tech, you can't get a cool job writing C because it's "unsafe", so now we have Rust. And Swift.

I don't think this is what you should take away from this post. Rust makes me very productive as a programmer, and reduces the "long tail" of debugging that I do when I write C and C++ (which I have for over a decade).

(And, for what it's worth, there are plenty of "cool jobs" writing C/C++. I have one!)

Very curious to hear your take on OpenSSL's Heartbleed bug and would you avoid it if you were the maintainer.

Other classes of bugs will take the place of memory safety bugs. For example, I don't think the recent Log4j exploit is a memory safety bug, but could be wrong.

Until that day we should make sure to eliminate the class of bugs that's #1 in all security problems -- namely buffer [over|under]flows. I'd be happy to hear this statistic has shifted towards the next #1 problem. But we're not there yet.

The problem is behavioral scope: bugs will always exist, but there is no particular reason for a buffer overflow to allow someone to run arbitrary code on my computer. It should, at the absolute worst, cause an uncontrolled program termination.

Without weighing in on Rust specifically, that's a fallacy, though I'm unsure of the formal name of it: "any solution that doesn't solve all problems is equivalent to the status quo".

Nobody is claiming all bugs will go away. But the claim that new classes of bugs will manifest specifically to take the place of memory safety bugs is extraordinary and needs justification.

It's a bit like going into the wilderness and packing survival gear: the argument "you don't need a warm jacket, because if you get lost the starvation will kill you even if the frostbite doesn't" doesn't hold up.

When you use simple metaphors to describe complicated politics in software development, that's when you lost the argument

Very curious to hear your suggestion on a native rust library with openssl’s functionality. Hint: there is none.

Not on topic though, not sure why you're bringing it up. The topic was: "C is fine". No, it really isn't.

You picked as an example a library without any safe alternative in rust. Used by a whole lot of rust projects dealing with tls. It’s ironic.

You call a "gradual migration path strategy" ironic? You do you, I suppose.

I call it a slow development pace caused by usability issues.

C is not fine, otherwise we wouldn't be getting all hardware vendors adopting hardware memory tagging as the ultimate mitigation solution.

However that doesn't mean Rust is the only answer, there are plenty of memory safe languages to chose from.

Do you think that the reason say Amazon is writing firecracker in Rust is because they just use whatever language is popular in HN and not because it's a good choice?

Yes?

Firecracker could be equally well done in many languages. It happened that the people assigned it at the time wanted production Rust experience, and were senior enough to be allowed to, despite the predictable risk of staffing difficulty after some other language steals away Rust's hipster cred. (Which one will, in time, as sure as seasons turn.)

It is a common experience for systems written in the a fad language to end up being re-implemented in a language easier to hire for. E.g. I see remarks on HN about this being a principal driver of Erlang hiring, lately.

Which other languages besides C/C++ were viable?

C/C++ is not a language.

I expect Firecracker could be done about as well in Rust, C++, Haskell, Java, Ada, or Typescript; or even in Common Lisp, C, or Assembly language.

Could or it would be a good idea?

Meaning, was it a good idea to have implemented Firecracker at all?

Every choice taken has consequences. Different choices have different consequences. Avoiding a choice has consequences.

Linux is (still) coded all in C. It is a terrible choice, but it works well enough to keep a billion phones and a billion websites operating. Language isn't fate.

Ok, firecracker could have been written in Assembly. It would have been a terrible idea. The fact that you legitimately suggested it makes me not want to engage in this conversation.

If we were talking about a startup, I'd agree with you. But given the vast resources at Amazon's disposal, I think assembly could be a legitimate option. Risky? Yes. But why not give it a shot? Assembly programmers are a dying breed, anything to incentivize people to write it is a win in my book.

Dude what sort of an argument is that? They should write it in assembly just to keep assembly programmers around? Don't they support a multitude of architectures? Are they supposed to port it for every given architecture? Are they supposed to do networking in assembly?

Yes.

You demonstrate you were not engaged to begin with. Obviously asm is the extremest choice, which is why it was last.

But Firecracker is not a difficult project, so if somebody really wanted, they could do it in asm. Likewise, Common Lisp. Not many would choose that, but it could perform as well as the others listed before it. Some people would even choose C.

> Firecracker is not a difficult project

...and Dropbox can be replaced with a few shellscripts + SFTP.

Come on. Something like Firecracker has got to be both complex and extremely hard to get right. Complex because it has to deal with the ultimate in simultaneous state changes: a captive entire virtualized operating system. Hard to get right because it has a tremendous number of integration points with obscure and quirky external systems (KVM, Linux itself) at an extremely low level.

Reply on news.ycombinator.com