Live data from Hacker News

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

twitter.com

361–370 of 929 posts

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

#361
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…

Unsafe is literally made for that. For cases when your wants can only be checked by your brain saying "I did the logic and it's all good". Ten lines of unsafe does not mean your program will blow up. If anything, it's here to encourage you to just be much more careful here.

Right, you don't have to be a purist to get safety benefits from Rust. If a Rust program is 1% "unsafe" code, it still has a far lower vulnerable surface area than an equivalent C program.

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

#362

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?

I was scared of C++ but Rust offered me some confidence to start.

Some languages (like C) are easy but using them is hard.

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

#363
post #109

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

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…

In complex apps and services, Rust is generally faster than C++ because (especially over the long term, as there's churn in teams) C++ developers copy around stuff way more than necessary.

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

#364
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 a very good point. A pointer dereferences its object, an index does not. So arguably having to switch from pointers to integers is going be a net drag on debugging since it will be no trivial to see what objects are being referenced.

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

#365
post #352

Earlier quoted context omitted.

> Get a build system that's easily workable without an Internet connection and recent TLS support. I'll say typing `cargo build --offline` can qualify as "easily workable".

How do you vendor to local, without the recent TLS support?

Copy it over from a normal computer.

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

#366

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…

No one's talking about your personal project here. The audience is teams of people building software to be used in production.

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

#367
post #193

Earlier quoted context omitted.

C/C++ is as naïve as ASM/C or Ape/Human. You come up with examples that are over 30 years old.

Yes my examples are old because the entire point I'm making is that this outrage over "C/C++" is a relatively recent phenomenon. People 10-20 years ago didn't really care or take issue with that term.

I was there and yes we did ;)

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

#368

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

How much slower would Rust be? If C++ delivers 4us and Java delivers 25us tick to trade for a particular strategy (say, book building, some calculations, then order sending), what could Rust get?

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

#369

Earlier quoted context omitted.

You don’t have to know about exception safety, move semantics, meta-template higgery jiggery, or the 30 years of cruft that C++ has accumulated. Good riddance.

You don't need to know about about 6 different string types, arcane borrow checker workarounds, RefCell complexity, massive async cruft - acquired by Rust in just 2 years. C++ will still be used heavily when Rust is buried 6 feet under and HN moves to the next hype language.

> You don't need to know about about 6 different string types

Eh, all these "different string" are different because... Well, they have different requirements. Path is not a normal string, it has platform-dependent implications, String/str are UTF8 strings, the byte-esque string have raw bytes, etc. I know I'm being brief, but I hope the differences I'm trying to illustrate are clear, and why it makes sense for these to be different types.

> arcane borrow checker workarounds

You often end up with these in portable/cross-platform C++ or in performance sensitive C++ code. Also, if you've not burdened yourself with OOP-style thinking and adjust your expectations to the fact you're not writing C++ anymore, but a different language, you'll have an easier time learning Rust. All that said, what you call workarounds is probably idiomatic to Rust developers. And even in the most pathological case of workarounds, the resulting Rust code will be much more succinct than any back-breaking efforts to make C++ readable/correct/performant (two of which you get for free in Rust; sans some complicated domains). Like, as examples: just working with std::variant is a nightmare and requires grotesque constructs with visitors patterns (and often lambdas), std::option is a joke that's marginally better than a raw pointer, etc.

> RefCell complexity,

It's no worse than just working with borrowing, and it's not that often you'd use this anyways.

> massive async cruft

Yes, you have a point here, and everyone's aware of this. And people who have ideas in the community about how it can be addressed can easily participate in the discussion and design process if they desire. Whereas C++ is designed by a committee of people who only barely still use the language in the real world (I know there's exceptions, but alas).

Also, if we got tooth for tooth, C++ has an abundance of more complexity than Rust does, and a lot of it isn't even obviously (hence can be dangerous, or just ruin your day/productivity)

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

#370

Speaking of Microsoft, it's time to halt starting any new projects in Windows and use Linux for those scenarios where an OS kernel is required. For the sake of security and reliability. the industry should declare that OS as deprecated.

get back to me when there's equivalents of KPP/Credential Guard/a stable driver API/etc
Post reply on HN