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

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

twitter.com

Post reply on HN
Print view View original

291–300 of 929 posts

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

#291

Post by jupp0r »

gpm wrote: post #278
lenkite wrote: post #260

Earlier quoted context omitted.

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.

I just glanced through the small number of open issues, and none seem like actual issues so much as potential improvements. The maintainer seems to still be around, and I've never found that a standard library is faster at merging improvements than third party libraries, rather the exact opposite (for good reason, the standard library needs to avoid breaking changes at nearly all costs). While I think there are valid…

> the standard library needs to avoid breaking changes at nearly all costs

IIRC in Rust this is a little bit looser than elsewhere (let's say in C++) as the ABI is not stable. This allows improvements that change the internal structure of structs but not the API. As a counter example, in C++11 there was a breaking change that introduced a size field to std::list, making size() O(1) instead of O(n), breaking linkage between older and newer versions of C++ binaries. In Rust there is no such guarantee so changes like that could be introduced anytime.

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

#292

Post by Ygg2 »

ajross wrote: post #223
hgs3 wrote: 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…

> Even a doubly-linked list is impossible to get through the borrow checker.

https://github.com/rust-lang/rust/blob/master/library/alloc/...

It's part of standard lib. And you don't get more idiomatic than that.

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

#293

Post by pitaj »

gavinhoward wrote: post #257
synergy20 wrote: post #189

Earlier quoted context omitted.

"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…

Okay and what about preventing use-after-free and dereferencing null pointers?

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

#294

Post by dcow »

userbinator wrote: post #197
woodruffw wrote: post #185

Earlier quoted context omitted.

Hm? I'm not a particular fan of Microsoft, but his stated opinion here is reflective of a broader trend in software design, one that's coming from both companies and the open source community. I don't see the brainwashing.

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…

If you think memory-safe languages are some anti-jailbreaking/rooting conspiracy... well, have you heard of Java?

No. Rust saves countless hours of frustration by eliminating frustratingly-hard-to-debug mistakes that humans commonly make when writing programs. Rust is pedantic, so you don't have to be. Rust saves companies money because Rust software requires noticeably less maintenance. Try it sometime.

Don't worry, I guarantee that man will always be able to break what man can make. You don't need to demonize better software hygiene out of fear that companies will perfectly lock down their devices.

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

#295

Post by ephimetheus »

diego_moita wrote: post #198
foomatic wrote: post #184

Earlier quoted context omitted.

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

In what world is C++ harder to learn than Rust?

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

#296

Post by icybauhaus »

lenkite wrote: post #281
stackbutterflow wrote: post #237

Earlier quoted context omitted.

Sure. In the meantime that's a few decades of better developer experience.

More like a few decades of extreme churn. Hey dude are you using Crate #43? No, thats dead on github. Try Crate #999. No dude that uses a diff async runtime. Try Crate #888. No dude, that has protest-ware on it and the boss complained. Try Crate #888. No dude, that has incompatible dependencies. Try Crate #456. No dude, that lib causes "fearless concurrency" deadlocks with async. Try crate #999. No dude, that has a g…

Surely C++ doesn't have this problem when using external libraries

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

#297

Post by rufius »

ephimetheus wrote: post #295
diego_moita wrote: post #198

Earlier quoted context omitted.

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

In what world is C++ harder to learn than Rust?

This world - the one you exist in right now. I say that as someone that wrote C++ for 10 years before moving to Rust.

Rust was by far easier.

That said - that’s an extremely biased statement and I recognize that. I think it was largely the compiler that helped make it easier.

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

#298

Post by leidenfrost »

ReactiveJelly wrote: post #203
foomatic wrote: post #184

Earlier quoted context omitted.

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

Cause those person-hours have to come from somewhere. Am I spending 2x of the new hire's time making them learn a harder language? Am I spending 2x of a senior's time teaching the new hire? What's the payoff in sticking with C++? Better libraries? Better tools? IDEs? That stuff will all shift as time goes on, if popularity is against it.

Robert C Martin's book about software architecture made a point about the fleeting nature of software as a product.

Time goes on, business changes and computers become faster.

At some point, many developers started to see features like a garbage collector, become a good offer with few disadvantages.

Unless we really need the performance, do users really care if the program consumes a few cycles more, if those cycles are being spent on tools to make lives easier for developers, like a garbage collector?

90% of software wouldn't make sense to be written in C

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

#299

Post by WiSaGaN »

hackerlight wrote: post #274

Would Rust be able to replace C++ in HFT?

If you want the lowest software latency as in "latency arbitrage", then probably not. However, even in HFT industry, there are a lot of software that you want very low latency but would still trade a bit latency in exchange for much better productivity, maintainability, and especially robustness provided by the type system of Rust. You want to be fast, and also want to reduce the possibility of hitting a company-breaking bug in your billion turnover trading system.

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

#300

Post by ncmncm »

woodruffw wrote: post #190
ncmncm wrote: post #181

Earlier quoted context omitted.

It makes as much sense to talk about a language named "Haskell/Ocaml" as about "C/C++".

Nobody is talking about one language named "C/C++". It's a shorthand for two languages that are closely related at the abstract machine level, and in terms of co-existing compiler frontends.

Then you might as well talk about "C/Rust". Both go to LLVM. But nobody says it, because it would be BS in exactly the same way "C/C++" is.

What matters about a language as a technology, as in the context of this Mark guy's blurb, is how it works in use. There, C and C++ share hardly anything in common: what you do writing good code in one is nothing at all like what you do with the other.

You might get a C program compiled with a C++ compiler, but it would be utterly crappy code, considered as C++.

So, "C/C++" is an inherently dishonest construction. Anybody using it for a context outside of, say, ELF formats or peephole optimization is promoting a lie.

Lying says more about the speaker than about the supposed topic.

Post reply on HN