Hacker News new | past | comments | ask | show | jobs | submit login

> The C side of this conflict will need better tactics if they're not going to just devolve into irrationality with false claims, baseless accusations and hysteria.

The "C side" don't need any tactics; it's their project and they are free to refuse entry of some other group of people.

They can make false claims, they can make baseless accusations and they can throw hysterics all they want to, because they don't have to convince anyone of anything.

The Rust side has to provide an argument more compelling than "you are using inferior tools", because even if true, it's irrelevant!

The Rust side has to do the convincing here, not the C side.




This response goes back to my first post on the topic: such attitudes and behavior have led to successful forks of major components that ultimately subsumed the legacy work. The Rust side doesn't even have to go so far as to reimplement the entire kernel, as Drew proposes. They can simply fork, govern the evolution of the fork as they see fit, including whatever adaptations they prefer to accommodate Rust and, should their efforts yield a compelling product (to one or all of Google, AWS, Microsoft, et al.,) they can win.

Also, I don't believe the "C side" has the degree of control over all of this that you hypothesize. The Linux BDFL isn't anti-Rust, and he is endowed with an inhuman degree of wisdom that will likely prevent him from supporting irrational C dogmatists. The acceptance by Linus of a possible future that included Rust in the kernel is the start of all of this. He knew then the road would not be trouble free; he's been calling these kinds of shots for too long to imagine otherwise.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: