Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us (2019)

alexgaynor.net

Post reply on HN
Print view View original

231–240 of 266 posts

Re: Modern C++ Won't Save Us (2019)

#231

Post by nightowl_games »

flohofwoe wrote: post #159
nightowl_games wrote: post #104

Earlier quoted context omitted.

Game dev here. Try reading the Godot code base. It's tiny allocations all the way through. It's really quite bad. BUT I'm using it professionally and it's useful. It's hard for me to mentally reconcile how good and bad the creator of Godot simulatenously was (is?). Casey also goes way too far in his take (as usual). RAII is a method to guarantee safety and correctness. It's useful in many many scenarios. Game dev and…

As productive and useful as Godot is (it is an awesome engine), its design resembles game engines of the late 90s to early 2010s when OOP was all the rage. Back then, most game engines were written that way (lots of tiny heap-allocated objects, connected by shared pointers). It's really just since the 2010s that the CPU/memory gap is the main driving force of game engine design (which wasn't much of an issue in the l…

Hey Floh, love your work! It's validating to hear you say these things. For me, the biggest annoyance with Godot's code base is the lack of clear ownership semantics (no use of smart pointers), and the use of fully hand rolled collection types for everything. It makes it hard to inspect variables in a debugger! Also the performance of the collection types are bad because of all the allocations. Seems like those problems will never get solved as it would be too expensive to rectify.

Re: Modern C++ Won't Save Us (2019)

#232

Post by rhn_mk1 »

hctaw wrote: post #205
rhn_mk1 wrote: post #163

Earlier quoted context omitted.

While I agree with most of what you wrote, CMake feels supercharged compared to the build system part of Cargo. Cargo is failing hard on the integration front, both on integrating things, and being integrated. build.rs is a minimal substitute of a build system: "deal with it yourself". The way Cargo wants to have total control, on the other hand, makes it hard to integrate with existing projects: those which don't us…

Cargo is a package manager first and minimum viable build system in far second. Comparing it to CMake is a bit unfair. If you need a real build system use cargo make or CMake itself.

I would not be bothered by Cargo not being a build system, except it's the one build system underpinning the entire Rust ecosystem via crates.io, and its "rules" are not interoperable with other build systems.

As a result, you have to deal with Cargo's terrible build system whenever you want to use an external crate, whether you want it or not.

Re: Modern C++ Won't Save Us (2019)

#233

Post by notacoward »

kazinator wrote: post #226
notacoward wrote: post #217

Earlier quoted context omitted.

Um, yeah, but there are other issues that make it not so nice. And it's an inoperative concept for most kernel/embedded work. I'd say in most contexts where forking would be OK you should be using a GC language anyway.

> And it's an inoperative concept for most kernel/embedded work I recently integrated mini_httpd (a small forking server) into an embedded system as part of a solution for distributing updates across a cluster of these systems. You must be talking about 15 cent microcontrollers (that still have a TCP/IP stack with SSL) or something, not ARM cores with MMU's running Linux.

I said most kernel or embedded. It's lovely that there are all sorts of embedded devices nowadays capable to support a style of programming indistinguishable from a general-purpose system, but that's not the only or even most relevant case. There are also billions of devices out there - not just 15-cent microcontrollers either - that don't lend themselves to that style because of real-time or other requirements. Even within a conventional system, there's a ton of stuff in the kernel - pre init, board support, most storage and networking - that can still use a per-request-arena approach to good effect but can't fork a process.

As I said, if you can fork all the time you probably shouldn't be using a memory-unsafe language anyway. Nothing you've said so far has suggested otherwise. The basic techniques for implementing your own memory safety are still valuable and worth discussing for people who aren't in Easy Mode all the time.

Re: Modern C++ Won't Save Us (2019)

#234

Post by wdpk »

vineek wrote: post #149

I completely agree with the points from this article. It is fundamentally infeasible to make all C and C++ code safe. The main reason, PAST code. There are countless lines of unsafe code already written. However, there is nothing magical about Rust's facilities (e.g. borrow checker) that make them inapplicable to FUTURE C and C++ code. I believe this is the only way forward for C and C++. They need to offer mechanism…

by the same token you could say it's also fundamentally infeasible for Rust to be code safe, otherwise they would not have unsafe code... so in the end it's an article that says nothing interesting at all

Re: Modern C++ Won't Save Us (2019)

#235

Post by hctaw »

rhn_mk1 wrote: post #232
hctaw wrote: post #205

Earlier quoted context omitted.

Cargo is a package manager first and minimum viable build system in far second. Comparing it to CMake is a bit unfair. If you need a real build system use cargo make or CMake itself.

I would not be bothered by Cargo not being a build system, except it's the one build system underpinning the entire Rust ecosystem via crates.io, and its "rules" are not interoperable with other build systems. As a result, you have to deal with Cargo's terrible build system whenever you want to use an external crate, whether you want it or not .

I don't disagree, I find cargo insufficient for projects of any meaningful complexity (it doesn't even support post build steps...). But it's really good at one thing: compiling crates.

But I haven't had a ton of trouble integrating it into CMake projects. It falls into the category of "know your tools." Not everything can "just work" all the time.

Re: Modern C++ Won't Save Us (2019)

#236

Post by rhn_mk1 »

hctaw wrote: post #235
rhn_mk1 wrote: post #232

Earlier quoted context omitted.

I would not be bothered by Cargo not being a build system, except it's the one build system underpinning the entire Rust ecosystem via crates.io, and its "rules" are not interoperable with other build systems. As a result, you have to deal with Cargo's terrible build system whenever you want to use an external crate, whether you want it or not .

I don't disagree, I find cargo insufficient for projects of any meaningful complexity (it doesn't even support post build steps...). But it's really good at one thing: compiling crates. But I haven't had a ton of trouble integrating it into CMake projects. It falls into the category of "know your tools." Not everything can "just work" all the time.

> But it's really good at one thing: compiling crates.

Unless you're using "compiling" as strictly compiling, and not "building", then I don't agree either.

It falls flat on its face if you want a build time choice between dependency versions, for example. And build.rs means that Cargo washes its hands from compiling parts of crates that are not written in Rust, so it's arguably not good at compiling (of anything but pure Rust).

The way Cargo is integrating several concerns also makes it hard to create better build systems for Rust, because they would have to pull in the same kitchen sink in order to support Cargo.toml. So that's being bad at letting others compile as a bonus.

EDIT: Actually, that wouldn't be a problem if Cargo the decent package manager didn't mandate Cargo the awful build system.

Re: Modern C++ Won't Save Us (2019)

#237

Post by pastenpasten »

HexDecOctBin wrote: post #34
Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…

What asiachick wrote below.

Muratori has demonstrated to me one time too many that he hasn't a got a clue about the things he's talking about.

To be precise: He may or may not have a clue about some things he's talking about, but I don't know enough about them to form an opinion. But in more than one occasions he went on to talk (sometimes at great length) about things where I know he's mostly or completely wrong in what he said.

I don't have a way to know the scope of these things, the things he doesn't know or understand yet talks about. Maybe it's just when it comes to "systems programming". Maybe it's everything that isn't game design and programming. And maybe he's wrong about games too. As I said, I don't know enough to judge everything he says, but the things I was able to judge convinced me not to trust him and his opinions.

And since I can't set the scope safely, I have to not trust him regarding everything.

For example, while his post[1][2] on ETW being "the worst API ever made" is slightly amusing and has _some_ good points, it mostly demonstrates:

(a) Inability or unwillingness to read the documentation. It would have saved most of his problems. But let's say that to criticize the _design_ of an API we can disregard that for a moment.

(b) Inability or unwillingness to pick the right tool for the task or pure trolling.

(c) Worst of all: Complete lack of understanding of the goals, purposes, limitation, design goals and tradeoffs of the system.

You can't criticize the design as being too complicated, while offering an irrelevant alternative for a "glorified memcpy()" (his words), when you don't understand what it does or what it's supposed to do.

(I emphasize again: I'm not saying the API is a paragon API design and that all is perfect there. I am saying the criticism is both grossly exaggerated and demonstrates misunderstanding of what the API actually does.)

After a couple of those I don't trust him and you shouldn't either but you're welcome to.

[1] https://caseymuratori.com/blog_0025 [2] https://news.ycombinator.com/item?id=8146124 See the discussion there.

Re: Modern C++ Won't Save Us (2019)

#238

Post by 01100011 »

pjmlp wrote: post #117
01100011 wrote: post #109

Earlier quoted context omitted.

I agree, but some people don't. When I interviewed at Google a couple years ago, they were rewriting the Fuchsia network stack in Rust. It was currently written in Go. My jaw about hit the floor when I heard that. I'm guessing they realized it was a mistake, but then again maybe the Go version was just a temporary placeholder. IDK, didn't get the job.

Better hold your jaw with both hands while reading this, https://www.f-secure.com/en/consulting/foundry/usb-armory

Uh, if you think that's bad, I once worked at a company that made communications gear for first responders and the military. Most of their stack was written in Python 2. I'm not talking UI, I'm talking systems software level stuff. Python tied together with dbus on top of a shake-n-bake Yocto distro that was out of date. People's lives depended on that tower of crap.

Re: Modern C++ Won't Save Us (2019)

#239

Post by hctaw »

rhn_mk1 wrote: post #236
hctaw wrote: post #235

Earlier quoted context omitted.

I don't disagree, I find cargo insufficient for projects of any meaningful complexity (it doesn't even support post build steps...). But it's really good at one thing: compiling crates. But I haven't had a ton of trouble integrating it into CMake projects. It falls into the category of "know your tools." Not everything can "just work" all the time.

> But it's really good at one thing: compiling crates. Unless you're using "compiling" as strictly compiling, and not "building", then I don't agree either. It falls flat on its face if you want a build time choice between dependency versions, for example. And build.rs means that Cargo washes its hands from compiling parts of crates that are not written in Rust, so it's arguably not good at compiling (of anything but…

As much as I agree that Rust needs a better story for builds and interacting with other languages, it sounds like you have a misunderstanding over what Cargo primarily does and what crates are. A crate is a single compilation unit of Rust. Cargo is a tool for compiling crates and pulling in other crates that it references.

build.rs is a half measure to include foreign symbols in compilation artifacts like static/shared libraries and executables. I'd go so far as to advise against using it for anything but specifying linker flags.

I don't think I've ever had a use case for specifying dependency versions at build time. That seems insane, and I do insane things in cmake with regularity. There's a reason versions are pinned to a config file committed to repos in almost every contemporary language.

fwiw, Cargo is a crate itself and you can use it as a library. You can even compile it with C language bindings to call through FFI in other build systems if you felt like it. The lang tools team has done a great job with keeping the scope of Cargo manageable and putting in the ground work to make better tooling around it.

For complex Rust builds, check out cargo-make. It does most of what you'd need in a predominantly Rust codebase. For polyglot environments, cmake with custom targets is the least bad way I've found to do it - and it's not hard to do that by shelling out to Cargo.

Re: Modern C++ Won't Save Us (2019)

#240

Post by brhsagain »

asiachick wrote: post #126
tejohnso wrote: post #59

Earlier quoted context omitted.

Wow, Casey doesn't hold back. Clearly, without hesitating says that 100% of code written in RAII* style sucks. Interesting considering Stroustrup considers RAII to be "the basis of some of the most effective modern C++ design techniques." I'd like to hear Casey's comments on TDD. *RAII style is lumped together with try/catch, smart pointers, tons of malloc/free new/delete

Casey hasn't a clue. He's only written games and he hasn't actually had to solve the issues that are being solved by in other domains. If he actually did have that experience he'd see his ideas don't scale. Games are in generally, vastly different than other apps (word processors, video editors, browsers, etc) in for one, for the most part, they get to choose all of their data upfront. If you're making "The Last of U…

Is your argument that arenas don't scale because user-provided data is variable in size?

Although arena memory is casually described as "allocate one huge chunk of memory up front," you are not literally only allocating one block ever and praying it never runs out. If you run out, you allocate another block. The point is that you don't call malloc for every string, object, list, etc. Adhering to this largely eliminates the need for RAII. What about this doesn't scale?

Personal anecdote: I'm building an IDE, where literally all of my data is provided by the user, and arenas have worked perfectly. I don't think I have a single destructor except for dealing with things like file descriptors, etc.

Post reply on HN