Comment by restalis | Hacker News Reader

Comment by restalis | Hacker News Reader

Parent Full thread

That "safe (by default)" aspect of a given programming language isn't free. It's similar to the security of a system that comes at the expense of its usability. The direction C++ developed itself was to provide performance and usability. A programming language that puts safety first has to be more than a useful tool, it has to be a mentor at best and a bureaucrat at worst. When touting the safe languages people have to be aware of survivorship bias, that countless projects never got the chance to be developed due to the too high of a burden of doing it properly in them (i.e. in a safe manner, in the way "safe" is defined by language designers). But then again, there may be cases when this development cost may not be that bothersome compared to other aspects (e.g. a corporation willing to hire more developers to compensate for the lost effort if thus it gets to hire fast and cheap - pretty much whomever manages to please the compiler, no in-depth skills screening necessary, the shipped code guaranteed to be safe anyway).

Rust fans rely on the compiler to enforce safety, to the exclusion of other qualities. In C++, we rely on libraries to provide safety and also those other qualities, so library authors get powerful features to enable that.

In practice, people writing modern C++ code do not struggle with memory safety, so it has been a good trade.

People avoiding modern coding style, such as Lakos and his minions (and, apparently, Fuschia and Chrome authors) do not get that benefit.

Rust requires you to write correct code. And no, lots of people using modern C++ do struggle with safety, and specifically memory safety. That's why these new languages exist, and exactly why they are gaining users every single day. No matter what someone on hacker news says...

This doesn't mean c or c++ are bad or something. But, yea...

Rust does not, in fact, require you to write correct code. No language can do that. The best a language can do is make it harder to write certain kinds of incorrect code. And, libraries coded in a powerful language can do that, too.

You are right it does not gaurantee correctness. Libraries can also provide unsafe or incorrect code. C++ lacks a package manager and a community mindset. So I trust c++ library's less than many modern programming languages...

Rust makes it so you can do this yourself for most things. It's not always convenient but it's the best I've seen so far.

I'm interested to see how automatic formal verification of rust code is going. Super interesting area, think a team at AWS is working on it, and a few other groups.

Conan, vcpkg and NuGET already cover a lot of C++ workloads nowadays.

Yes there are several third party package managers, which is a pretty good smell that the situation is sticky at best. Out of the three my favorite is NuGET. Unfortunately the ecosystem last I checked anyway was weaker than say rusts' or go's(at the risk of comparing apples to oranges). Python also has multiple package managers, and the worst part of python when used appropriately is it's package managers and logical layout...

Most modern programming languages have one package manager dedicated to the language, and for good reason imo.

Part of the problem is, the c++ culture is kind of like the c culture, most people would rather write their own packages from scratch then leverage a community. I don't blame the languages, they were around before git was common.

I feel like I am bashing c++... I don't mean too, it's a great language and it does have good packages(some I prefer over what is available in say Rust), but most projects I've seen not using visual c++ do the 1990s thing and don't use these tools. Maybe it's their age, never looked hard at "why", being honest.

Surely it is weaker if we are counting npm like quantity of packages.

If on the other hand we are counting quality packages, all major ones are available.

> In practice, people writing modern C++ code do not struggle with memory safety, so it has been a good trade.

Then why do we have so many memory safety bugs in, for example, modern webbrowsers? I'm relatively sure that the Chrome team is pretty competent, and yet...

The Chrome team is evidently not writing modern C++ code.

"No true Scotsman...". Take string_view for example: perfectly cromulent modern C++. I use it daily to reduce the number of unnecessary copies. It's also very easy to code a use-after-free bug with it.

Only by storing it somewhere. So long as it is only passed down a call chain, no problem.

string_view really is no different from a naked pointer. Modern C++ treats naked pointers with well-deserved suspicion. I never have any trouble because pointers are always strictly evanescent values.

> In practice, people writing modern C++ code do not struggle with memory safety, so it has been a good trade

So you believe then, that the majority of C++ code written at e.g. Microsoft is not 'modern'?

Quote from [1]: "~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues."

[1] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

Have you seen WINAPI?

Note that while MSRC asserts that, Azure Sphere OS and Azure RTOS only support C (not even C++), and WinUI team likes to boost themselves how much of the underlying COM components are written in C++ (in UWP some of them were .NET Native).

Also Visual C++ team is quite keen in brigging Rust like safety (as much as possible) to their static analysis tooling.

> So you believe then, that the majority of C++ code written at e.g. Microsoft is not 'modern'?

Maybe some new code is modern - but there is a tremendous legacy code base that can’t possibly be (and Microsoft has released enough open source that you can verify this yourself). Also retrofitting isn’t magic - the boundary between old and new will always cause problems.

Microsoft coders are, as a rule, notoriously bad, always have been.

Are you implying that all past and current Microsoft employees are bad coders?

Obviously not. But an enduring large fraction are, and remain. And code there is practically never improved or modernized, only patched onto. It is a cultural thing: there is no perceived value in anything but new bullet-item features.

I was going to write a diatribe on rusts great features, but I don't have time.

Please go try rust, not for its memory safety but for all of its other qualities that make it better than c++ in my book.

This is one of those "...except when it does" takes. It's always been a bald faced No true Scotsman fallacy.

A: "Modern C++ has no problems with memory safety." B: "But what about X? X was written in C++ last year. X has problems with memory safety." A: "X is not modern C++."

That "memory unsafe languages produce vulnerabilities" is an empirical claim. I can give you gobs of data. If you actually think, "In practice, people writing modern C++ code do not struggle with memory safety", then you should produce some data that shows this to be the case.

So, my take is -- okay, prove it. Because, my guess is, your claim is mostly a feeling you have about your code (yes, simply good code vibes) rather than something you can demonstrate to others.

> survivorship bias, that countless projects never got the chance to be developed due to the too high of a burden of doing it properly

I would contend the cost of doing things “safely” is much higher in C++. since a human being has to mentally do all the work the compiler would do in a safe language.

Right. Op is saying an unsafe program that’s paying the bills and we can fix later is better than being a Rust evangelist on hn because your startup never got off the ground.

Somewhere out there, a startup is writing a browser in pure safe rust, and there won’t be any memory errors in it because they’re never gonna take on any tech debt and it’s never gonna ship.

Yeah I understand but I disagree.

If you race a skilled Rust team against an equally skilled C++ team to build some big complicated fast software, the Rust team would likely ship first, and with less bugs.

The C++ team will eventually ship too, but it will take much longer. The software will also be of high quality, and very slightly superior performance, but there will be a couple of memory leaks, maybe a couple of exploits, and possibly a tricky segfault, somewhere down the line. Maintaining the C++ team’s software without introducing further issues will require superhuman intelligence, so it won’t happen - there will increasing issues as the team turns over and the detailed understanding of the code is lost over time.

The Rust team will mostly suffer from frustration about how bad async is, go down the rabbit hole of using it, and then rip it out and replace it with hand-rolled state machines and epoll. Down the line at some point, future programmers will decide this is legacy garbage and replace it all with async again.

There will be no segfault or memory exploits, and a similar number of logic bugs to the c++ team.

I say this having worked on large C++ projects and large Rust projects, and with no particular religious love for Rust other than a grateful appreciation for the compiler.

You really can become productive in safe languages. It does take some practice, but it makes you a better programmer. Someone might turn the table and claim they are more productive in memory safe languages because when they hit production they can actually pivot to new projects rather then put out concurrency/parallelism fires.

Reply on news.ycombinator.com