4 ms·

Do you think maybe that Herb and Andrei might have a (completely understandable and probably unavoidable given human psychology) bias? Besides, appeals to autho

Do you think maybe that Herb and Andrei might have a (completely understandable and probably unavoidable given human psychology) bias? Besides, appeals to authority tend to be frowned upon. Now, I don't disagree that C and C++ are probably generally the "fastest languages"[0] at the current time. For most programs that's completely irrelevant -- what's more relevant is that the most dangerous security issues of the age almost exclusively come from these languages[1]. This is why, e.g. Rust matters, but also why languages without undefined behavior in general are a big deal. Undefined behavior is an abomination which has caused untold damage (even more than the billion-dollar mistake of "null"). [0] Somewhat of an absurd term, but let's just say that these languages encourage a style which leads to efficient machine code. [1] Lack of escaping (particularly SQL) is probably a close second. EDIT: Btw, if I were really performance-bound, I think I'd actually use a higher-level language to create a domain-centric DSL to describe my solution and then use that to generate a lower-level program (in C/C++, assembler or whatever) which solved my problem. People have been doing that kind of thing for a few years now. See e.g. https://hackage.haskell.org/package/atom https://hackage.haskell.org/package/atom

YZF 12y ago
It was not meant as an appeal to authority. It was meant as a reference to the experience of a larger software company who writes code in both languages. That said I'll agree they have a bias, everyone has. Full disclosure: I like C++. I also do like Python but it is my preferred language for specific scenarios. I also agree to some extent that languages themselves aren't fast or slow (though to some extent they are). In theory equivalent code in two languages should result in machine code that is just as efficient and it is sometimes a fluke or some implementation choices that make it not so. I can talk a little bit to the security question. One thing we need to consider is that we're dealing with systems, not strictly with bits written in some language. Various injection attacks are almost universally carried in platforms that are not C/C++ and their root cause is at the interface between systems (e.g. your web back end's interface to your SQL database). Even in systems that run in various isolated sandboxes there is always the possibility of penetrating that sandbox or to have other holes in the interfaces to the rest of the system. Honestly, the undefined behaviour bits in C/C++ isn't something that I've seen matter in practice. When all system code in the world is written in C you're bound to be able to point to some mistake causing security issues but we have no way of comparing that to anything (at least none that I can think of). There's always some way someone can screw things up. That said there's no harm in trying to do better- if we can get safer languages, where it's harder to make mistakes, and have all the benefits of the less safe language it's a win-win. No downside.
- lomnakkus 12y ago
  Fair enough. I apologize for the accusation -- it's just that you never know. For the record, I also like C++. Especially in its modern incarnation C++11. It's a vast improvement over plain C (if you care about generic programming, as I do). I just think we need an even better language to take its place -- hopefully Rust can deliver, in time. Re: Injection attacks: Most of the "holes" in e.g. VM emulation code also come from C/C++ legacy -- at least that's been my (admittedly anecdotal) experience. > Honestly, the undefined behaviour bits in C/C++ isn't something that I've seen matter in practice. This isn't exactly recent, but just for example: http://lwn.net/Articles/342330/ http://lwn.net/Articles/342330/ This happens all of the time, especially as optimizers get even better at exploiting the fact that undefined behavior "cannot happen" (per the semantics of the language.) Ultimately: Yeah, definitely agreed on striving for better and safer languages as long as they deliver what we need even if those are different languages and different needs -- as long as we each get better and safer and faster* code in the end! :)

YZF 12y ago

It was not meant as an appeal to authority. It was meant as a reference to the experience of a larger software company who writes code in both languages. That said I'll agree they have a bias, everyone has. Full disclosure: I like C++. I also do like Python but it is my preferred language for specific scenarios. I also agree to some extent that languages themselves aren't fast or slow (though to some extent they are). In theory equivalent code in two languages should result in machine code that is just as efficient and it is sometimes a fluke or some implementation choices that make it not so. I can talk a little bit to the security question. One thing we need to consider is that we're dealing with systems, not strictly with bits written in some language. Various injection attacks are almost universally carried in platforms that are not C/C++ and their root cause is at the interface between systems (e.g. your web back end's interface to your SQL database). Even in systems that run in various isolated sandboxes there is always the possibility of penetrating that sandbox or to have other holes in the interfaces to the rest of the system. Honestly, the undefined behaviour bits in C/C++ isn't something that I've seen matter in practice. When all system code in the world is written in C you're bound to be able to point to some mistake causing security issues but we have no way of comparing that to anything (at least none that I can think of). There's always some way someone can screw things up. That said there's no harm in trying to do better- if we can get safer languages, where it's harder to make mistakes, and have all the benefits of the less safe language it's a win-win. No downside.

lomnakkus 12y ago
Fair enough. I apologize for the accusation -- it's just that you never know. For the record, I also like C++. Especially in its modern incarnation C++11. It's a vast improvement over plain C (if you care about generic programming, as I do). I just think we need an even better language to take its place -- hopefully Rust can deliver, in time. Re: Injection attacks: Most of the "holes" in e.g. VM emulation code also come from C/C++ legacy -- at least that's been my (admittedly anecdotal) experience. > Honestly, the undefined behaviour bits in C/C++ isn't something that I've seen matter in practice. This isn't exactly recent, but just for example: http://lwn.net/Articles/342330/ http://lwn.net/Articles/342330/ This happens all of the time, especially as optimizers get even better at exploiting the fact that undefined behavior "cannot happen" (per the semantics of the language.) Ultimately: Yeah, definitely agreed on striving for better and safer languages as long as they deliver what we need even if those are different languages and different needs -- as long as we each get better and safer and faster* code in the end! :)