Live data from Hacker News

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

twitter.com

601–610 of 929 posts

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

#601

Earlier quoted context omitted.

> in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. That hasn’t been my experience. Rust (the language) doesn’t seem to get any more complex as programs get bigger. Lifetimes, while complex in isolation, tend to compose really well. Most of the pain of learning rust seems to be experienced up front. (Well, other than async but I don’t consider that ready yet). In comparison,…

If you didn't use C++ with the RAII paradigm, and had to write your own new/delete, your previous C++ experience isn't representative of the complexity of dealing with C++ since C++11. The new standards are a massive upgrade, and now a lot of other things are starting to get major quality of life improvements too (eg. template metaprogramming)

This is a really good point. Just like the Great and Powerful oz telling us not to look behind the curtain or you'll see a goofy old man - C++ is quite mighty if you don't look over there at the other stuff.

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

#602

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

> Programmers currently using Rust are superior to programmers using C++

> People learn C++ in college. People learn Rust because they love their craft

Wow... and rust programmers wonder why rust has a stigma? So I guess John Carmack is inferior and is not an ultimate craftsman.

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

#603

Earlier quoted context omitted.

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?

Theoretically, Rust can be as fast as C/C++ as long as you dive into unsafe when necessary, or skip string like UTF-8 string. However, a lot of the upside for using Rust will be gone as well, which will not make using Rust as compelling as in other domains. And when using Rust, people will probably incline to use more idiomatic Rust, which will be a bit slower. Thus I would say you would expect the actual Rust code you see will be to around 6us in scale, that is, a bit slower but still comparable to C/C++, at the same time with much better robustness (much fewer crashes).

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

#604
post #300

Earlier quoted context omitted.

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

LLVM is not a compiler frontend. It’s the middle- and back-ends; Clang is the frontend.

Neither Rust nor C is inextricably linked to LLVM either, as I’m sure you’re aware. And the former doesn’t align with the abstract machine assumed by the latter in important regards, like forward progress.

The rest of this is just a screed. I’m not here to defend his honor, and you shouldn’t waste your time posting about it on random sites on the Internet.

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

#605
I am still ok with plain and simple C for cross-CPU code, for now. c++ is lost in grotesque and absurd complexity (that's why gcc move to c++ was one of the biggest mistake in software, ever).

I am one of the guys who would like RISC-V to be successful, then "port" everything to RISC-V assembly, without excessive usage of the macro pre-processor, then forget about compilers.

Linus T. (more likely the guys pulling the strings of the linux fondation financing) green lighted rust in the kernel, I bet this is some horrible gcc extended rust, not core and simple rust (hope they have the decency to compile linux rust code with the rust compiler written in rust). A long time ago, I had a look at rust syntax and was disappointed by the strings hardcoded in the syntax and all that "package" management system hardcoded in the syntax, but most syntax looked like a re-arranged C. Were they able to keep it that simple? (no grotesque objet orientation or those horrible templates or garbage collector or hardcoded weird and expansive memory allocation model).

The pb is C syntax is too already too complex. I wonder if rust suffers from the same issue, hope they "fixed" C: only sized types, no integer promotion, no implicit cast (except for void*), compile-time/runtime casts (without that horrible c++ syntax), only 1 loop keyword, no enum/typedef/_generic/etc, etc.

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

#606

Earlier quoted context omitted.

> Wanting to weaken the economic position of a certain type of developer makes a lot more sense. Just more anecdata, but this isn't true for my company. We're hiring for Rust because we're seeing more and more clients take memory safety seriously (and ask specifically about it as a design consideration). These things have a way of balancing themselves out: developers like Rust, so there will probably be an eventual "…

> we're seeing more and more clients take memory safety seriously Running your test suite with asan, msan, tsan isn't sufficient? From my experience you need to start doing really nasty things (which shouldn't pass code review) before the sanitizers won't find your issues.

There are plenty of things that ASan won’t catch, like misuse between contiguous allocations.

But that’s sort of tangential: the goal is to write software that’s correct to begin with, not poke holes in it with the testsuite after the fact. With Rust, I can pick third-party dependencies that I can be (vanishingly) confident don’t have memory safety issues; when I start a greenfield C++ project, any dependencies I bring in are now potential sources of memory unsafety in my code.

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

#607

I am still ok with plain and simple C for cross-CPU code, for now. c++ is lost in grotesque and absurd complexity (that's why gcc move to c++ was one of the biggest mistake in software, ever). I am one of the guys who would like RISC-V to be successful, then "port" everything to RISC-V assembly, without excessive usage of the macro pre-processor, then forget about compilers. Linus T. (more likely the guys pulling the…

I don’t know what you mean by strings embedded in Rust syntax nor package management (unless you mean crates and modules, which are basically just namespaces; the only “package management” is done by higher-level tools like Cargo).

To answer your other questions: no, Rust has neither garbage collection, nor templates. I don’t know what you mean by hardcoded weird and expansive memory allocation model; Rust’s is basically the same as C++’s.

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

#608

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…

"We have to have to keep our systems unsafe so we can have rooting exploits for our devices" is an interesting viewpoint. I can understand why somebody would demand the ability to safely access root, but demanding unsafe code is just wild.

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

#609
post #602

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

> Programmers currently using Rust are superior to programmers using C++ > People learn C++ in college. People learn Rust because they love their craft Wow... and rust programmers wonder why rust has a stigma? So I guess John Carmack is inferior and is not an ultimate craftsman.

You cut out the words “statistically speaking”, which entirely change the meaning.

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

#610
post #484

Earlier quoted context omitted.

There's nothing unsafe about integer indices because access to the array they index will incur bounds checks.

Using integers as allocation strategy (as in the referenced use case) will fail when slots are reused.

To be fair pointers can (and are) also reused by the OS allocators which can lead to "fun" bugs if you aren't careful
Post reply on HN