Live data from Hacker News

It's time to halt starting any new projects in C/C++

twitter.com

251–260 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#251
You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine.

https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

He extensively reverse engineered and documented "Windows Internals" details before joining Microsoft (and before being "encouraged" to change the name of his business to Sysinternals).

His writings and talks on "The case of..." are master classes on reverse engineering.

https://youtu.be/GQ1EDqsA1yk

https://techcommunity.microsoft.com/t5/windows-blog-archive/...

I'm paying attention to him.

Re: It's time to halt starting any new projects in C/C++

#252
post #94

I don’t feel that his opinion is all-encompassing. If Rust is being used in the name of security and reliability, then C/C++ should remain king of game development, where those two aren’t as important.

Have you tried working with Bevy at all? It's very good: https://bevyengine.org/learn/book/getting-started/ecs/

What's the asset pipeline story? Is there an editor, even?

What it looks like is another Raylib, Allegro, Ogre, etc; an engine these days can be expected to have tooling for artists and designers first and foremost.

Re: It's time to halt starting any new projects in C/C++

#253
post #163

Earlier quoted context omitted.

> Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot. I can't imagine anyone ever describing vanilla JavaScript this way.

Yeah, made me reread the whole message with my sarcasm checker turned up. I can’t recall another widely used language of the era with as many foot-guns or one that went so long without a decent debugging experience. It really draws into question the claim that “it's easier to write super complex stuff in C++ than in Rust” when so clearly incorrect about JS. Especially when we have _decades_ of evidence from world-sto…

With JS I meant it was something to run in a browser, nothing serious (initially). So from the historic perspective it was correct as for the reason why it existed. It was not meant to write multithreaded system services where most bad/average devs struggle (and it's not multithreaded to this day outside webworkers).

Re: It's time to halt starting any new projects in C/C++

#254

Earlier quoted context omitted.

His "opinion" is not only reflective, but amplifying, and that's the scary part. The companies are the ones pushing this "security" stuff, because they want to stop us from doing things like jailbreaking --- and eventually running any software they don't approve of. See https://news.ycombinator.com/item?id=32905587 He used to write very useful utilities which did things that Microsoft didn't officially support or oth…

bizarre. not even sure what that linked comment is supposed to do for your argument here. The idea that rust is some plot by "companies" to "prevent jailbreaking" is ..... rough, man.

They're not trying to burn the frog but boil it slowly.

This is just another one of a series of small steps.

Re: It's time to halt starting any new projects in C/C++

#255
post #223
post #211

I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…

That's my take too. Idiomatic Rust is "safe" in the sense that... it disallows most nontrivial data structures. Even a doubly-linked list is impossible to get through the borrow checker. That's... not really that fatal. There's a lot of very useful code that can be written using only runtime-provided[1] containers and straightforward ownership trees. But obviously the big problem is that for applications that do need…

Random question, doesn't this then defeat the whole purpose of using rust? Memory errors, that is, pointer issues are the primary source of errors that ownership in rust claims to fix. If the only way you can make nontrivial data structures is use "a ton of unsafe blocks," then you'll still likely get the memory errors, only now it's in an unsafe block...so, now everyone can just blame the unsafe block?

This reminds me of those static provers which prove everything correct up until user input, you know, the place where an attacker will inject their payload.

Re: It's time to halt starting any new projects in C/C++

#256
post #109

Earlier quoted context omitted.

Dunno. Young devs can pick basic Rust constructs fast but when it comes to complicated stuff where performance is critical... There must be raw talent and lot of grind. IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. C++ for talented folks makes life easier there. Like JavaScript, yet another language written for bad…

> IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. It keeps you from compiling (many of) the bugs you'll happily write and deploy in C++. I don't think there's really much practical difference in "cognitive load" between modern C++ (which is painfully complex in ways that are largely not even useful) and rust. C++ jus…

Sure, but don't forget the inherent trade-off - Rust allows you to write safer code at the cost of getting in the way. It simplifies some things and makes other things very complex. It empowers average devs that can suddenly write certain types of system services easily and be reasonably sure they work as intended, but it gets in the way of advanced devs writing core systems.

Re: It's time to halt starting any new projects in C/C++

#257

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better…

"Oh, and it's possible to make C as good as Rust", do you have some concrete advice documented somewhere? Thanks!

I hate to admit this, but it took me a long time to do, mostly because I was not experienced when I started writing code, and the code has been rewritten several times over to get it right.

First off is the code in [1]. It's technically under several licenses, but I can give it to you under the public domain because bounds checking in C is important enough that I'll give it away.

The `y_ARRAY_TYPE()` macro generates a struct that is an array with bounds. Use it like this:

    typedef y_ARRAY_TYPE(uint32_t) uint32_t_arr;
`uint32_t_arr` is a bounded array of `uint32_t`'s.

You can then pass that array to functions and do bounds checks with the `y_i()` macro (for when the struct value is not a pointer) and the `y_ip()` macro (for when the struct value is a pointer).

To implement RAII, the code to do that is in the same repo, but it's...much more complicated: a full stack allocator. I just add the destructor as a parameter when allocating memory, and when the allocation is freed, the destructor is called when it's non-NULL. Then there are functions to allocate and free, but it is always done in a stack, to emulate the real stack.

By the way, the type of destructor is

    void (*y_Destructor)(void*)
and it takes a pointer to the item to be destroyed.

Structured concurrency takes the idea of a thread-local stack and sort of generalizes it across threads. The idea is that each thread has a parent, and that parent is not joined until all of its child threads are joined. All threads form a tree, almost exactly like process trees in Linux.

This means that if you want to have another thread borrow an item, you just have to make sure that thread is a descendant of the thread it is borrowing the item from, and you have a guarantee that the item will never go out of scope before the borrowing thread does.

Sometimes you need to change your code to do that. You can "push" things "down the stack" by passing function pointer callbacks to callees who then create the item to borrow and call the callbacks. Inside the callbacks, the borrowed item will always exist.

There's more to it than that (you can turn a thread tree into a DAG [2], allowing you to turn threads that are not descendants of a thread into descendants), but that's probably good enough to start you off.

[1]: https://git.yzena.com/Yzena/Yc/src/commit/cf4c96b3560d/inclu...

[2]: https://lobste.rs/s/8msejg/notes_on_structured_concurrency_g...

Re: It's time to halt starting any new projects in C/C++

#258

Earlier quoted context omitted.

I understand you think it's awful, but I do like it. Everyone has their preference.

You can like something and still admit that it is awful. I "liked" C for a long time before there were better options...

I still disagree that it's awful.

Re: It's time to halt starting any new projects in C/C++

#259

I'm waiting for Rust to support both static and dynamical link equally well. static link produces binaries too large for my embedded boards when stdlib is needed. dynamic link looks like a second class citizen to me in Rust. Is there some hope?

This is a tangent, but how do people comply with the MIT (or other) license when statically linking binaries? You have to include the copyright notice and license, but I almost never see that being done (and, based on the Rust projects I’ve seen, there are often tens, or even hundreds of MIT/BSD/Apache licensed dependencies).

People who use permissive licenses usually don't care about the license-inclusion clause, so most people just don't bother with it until someone comes asking. At the end of the day, fixing that problem is just a matter of including a new text file in the next release. It's nowhere near as big of a deal as when someone complains that you're not complying with the GPL.

By the way, whether you're linking statically or dynamically doesn't affect whether you ought to include the licenses of your dependencies. At least not for BSD, I'm less certain for MIT.

Re: It's time to halt starting any new projects in C/C++

#260
post #228
post #211

I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…

The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't quite right. Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own i…

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.
Post reply on HN