Re:Zero-days in Cisco Discovery Protocol
by big_chungus on Thursday February 06, 2020 @05:10PM
(#22260964)
This is true, largely because no one outside the HN bubble knows Rust/Zig/ATS/whatever. Most companies and people want to get stuff done, and a new language can get in the way of that. It'll take a while for those newer languages to pick up main-stream traction, and by a while I mean a few years of pushy college grads who used it in CS 101, 202, or 303.
[ Parent
| on HN ]
Re:Zero-days in Cisco Discovery Protocol
by jupp0r on Thursday February 06, 2020 @08:18PM
(#22262316)
Don’t be so sure about that. I don’t know any C++ dev who hasn’t heard (good things) about Rust. It’s definitely well known in the systems programming community at this point. That’s different from using it in production though.
Re:Zero-days in Cisco Discovery Protocol
by alfalfasprout on Thursday February 06, 2020 @09:32PM
(#22262743)
And that's precisely the point. You don't use C++ because it's the best thing since sliced bread. You use it because you want to easily use decades of optimized libraries and get a result that's highly performant without spending a long time creating wrappers in Rust (that may not even be easy to do w/ libraries that rely on a lot of templating).
Re:Zero-days in Cisco Discovery Protocol
by vardump on Friday February 07, 2020 @12:54AM
(#22263554)
A lot of C++ projects (not all!) have relatively few dependencies. I think this "decades of optimized libraries" is a bit hyperbole.
Besides, libraries that were optimized for HW 20-30 years ago don't age all that well and are far from optimal these days. They also tend to still have a ton of bugs.
Now, I'm not saying there aren't cases where you really need to build on legacy library base. Merely that it's a bit rare case.
Re:Zero-days in Cisco Discovery Protocol
by tsimionescu on Friday February 07, 2020 @02:45AM
(#22263972)
Libraries that are 20-30 years old and that people still use today are generally in continuous development over that time period, often with the same team (in a ship-of-Theseus sense). That means that they have been optimized for today's hardware for about 20 years worth of todays.
Now there are cases where libraries have ossified and there is room for a new library to come and eat their cake (look at ripgrep for an example), but there are also a lot of cases where they are going to be very hard to beat (a lot of boost is in this area, I believe, and there are many other examples in specialized domains).
boost fills more of a role that standard libraries play in other languages (think go).