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

Matt Godbolt sold me on Rust by showing me C++

collabora.com

Post reply on HN
Print view View original

421–430 of 675 posts

Re: Matt Godbolt sold me on Rust by showing me C++

#421

Post by roelschroeven »

jeroenhd wrote: post #419
nerpaskteipntei wrote: post #378

Earlier quoted context omitted.

Now there is also std::from_chars function

std::from_chars will still accept "123abc". You have to manually check if all parts of the string have been consumed. On the other hand, " 123" is not accepted, because it starts with an invalid character, so the behaviour isn't "take the first acceptable number and parse that" either. To get the equivalent of Rust's if let Ok(x) = input.parse:: () { println!("You entered {x}"); } else { eprintln!("You did not enter…

I guess there's a place for functions that extract or parse partially, but IMO there is a real need for an actual conversion function like Rust's parse() or Python's int() or float(). I think it's a real shame C++ (and C as well) only offers the first and not the second.

Re: Matt Godbolt sold me on Rust by showing me C++

#422

Post by bluGill »

timbit42 wrote: post #203
bluGill wrote: post #174

Earlier quoted context omitted.

That is easy to say today, but I guarantee in 30 year Rust will have rough edges too. People always want some new feature and eventually one comes in that cannot be accommodated nicely. Of course it will probably not be as bad as C++, but still it will be complex and people will be looking for a simpler language.

How many rough edges will C++ have in another 30 years?

Who knows. It will likely have more than any other language. Though it will also continue to not get credit for things it got right.

There will always remain two types of languages: those that nobody uses and those that everybody complains about.

Re: Matt Godbolt sold me on Rust by showing me C++

#423

Post by fpoling »

jandrewrogers wrote: post #251
fpoling wrote: post #70

Earlier quoted context omitted.

Result type still requires quite a few lines of boilerplate if one needs to add custom data to it. And as a replacement of exceptions with automatic stack trace attachment it is relatively poor. In any case I will take Rust Result over C++ mess at any time especially given that we have two C++, one with exception support and one without making code incompatible between two.

FWIW, stack traces are part of C++ now and you can construct custom error types that automagically attach them if desired. Result types largely already exist in recent C++ editions if you want them. I use completely custom error handling stacks in C++ and they are quite slick these days, thanks to improvements in the language.

What I really like to see is stack traces annotated with values of selected local values. A few years ago I tried that in a C++ code base where exceptions were disabled using macros and something like error context passed by references. But the result was ugly and I realized that I had zero chances to adopt it.

With Rust Result and powerful macros it easier to implement.

Re: Matt Godbolt sold me on Rust by showing me C++

#424

Post by bluGill »

simonask wrote: post #323
bluGill wrote: post #174

Earlier quoted context omitted.

That is easy to say today, but I guarantee in 30 year Rust will have rough edges too. People always want some new feature and eventually one comes in that cannot be accommodated nicely. Of course it will probably not be as bad as C++, but still it will be complex and people will be looking for a simpler language.

Rust has rough edges today. The field of programming is still only a few decades old, and there's no doubt that something even shinier will come along, we just don't know yet what that looks like. That's not a good reason to stick with inferior tools now, though.

What does inferior mean?

Rust is inferior to C++ for my needs. This is just a reflection on we started a large project in C++ before rust existed, and now have millions of lines. Getting Rust to work with our existing C++ is hard enough as to not be worth it. Rewriting in Rust would cost 1 billion dollars. Thus despite all the problems we have with C++ that Rust would solve, rust is inferior.

(Rust is working on their C++ interoperability story and we are making changes that will allow using Rust in the future so I reserve the right to change this story in a few years, but only time will tell)

Re: Matt Godbolt sold me on Rust by showing me C++

#425

Post by tormeh »

andrepd wrote: post #381
Ygg2 wrote: post #357

Earlier quoted context omitted.

Sure, but it is pragmatic in other ways as well :) It takes ADT, but not function currying, and so on.

I don't think currying is that big a deal, it's just syntactic sugar that might or might not make things easier to read, unlike ADTs or closures which are important core concepts. I'd love to have a syntax like { foo(%1, bar) } standing for |x| { foo(x, bar) } though. I'm not aware of any language that has this!

I'd argue that currying is actively harmful (I suspect you agree). I've seen functions take one argument in one source file, and the next argument in another source file. In JavaScript no less. Horrendous stuff. One of my most hated anti-features, along with Scala's implicits. These kinds of features are mostly misused rather than used.

Re: Matt Godbolt sold me on Rust by showing me C++

#426

Post by pjmlp »

timschmidt wrote: post #380
pjmlp wrote: post #374

Earlier quoted context omitted.

C++ editions are -std=something, people keep forgeting Rust editions are quite limited in what they actually allow in grammar and semantic changes across versions, and they don't cover standard library changes. IDEs are wonderful tooling, maybe people should get their heads outside UNIX CLIs and MS-DOS like TUIs. Then there is the whole ecosystem of libraries, books, SDKs and industry standards.

I'm not sure who in your mind is forgetting that, or what the rest of your comment means to communicate. Who are you speaking to who hasn't explored all those things in depth? I see Rust's restrictions as a huge advantage over C++ here. Even with respect to editions. Rust has always given me the impression of a language designed from the start to be approximately what C++ is today, without the cruft, in which safety…

Many of the members of the Rust Evangelism Strike Force, as main audience. That is to whom it is targeted for, given the usual kind of content that some write about.

I agree that Rust is designed to be like C++ is today, without the cruft, except all languages if they survive long enough in the market, beyond the adoption curve, they will eventually get their own cruft.

Not realizing this, will only make that 30 years from now, if current languages haven't yet been fully replaced by AI based tools, there will be that language designed to be like Rust is in 30 years, but without the cruft.

The strength of C++ code today is on the ecosystem, that is why we reach for it, having to write CUDA, DirectX, maybe dive into the innards of Java, CLR, V8, GCC, LLVM, doing HPC with OpenAAC, OpenMP, MPI, Metal, Unreal, Godot, Unity.

Likewise I don't reach for C for fun, the less the merrier, rather POSIX, OpenGL, Vulkan,....

Re: Matt Godbolt sold me on Rust by showing me C++

#427

Post by tmoertel »

andrepd wrote: post #381
Ygg2 wrote: post #357

Earlier quoted context omitted.

Sure, but it is pragmatic in other ways as well :) It takes ADT, but not function currying, and so on.

I don't think currying is that big a deal, it's just syntactic sugar that might or might not make things easier to read, unlike ADTs or closures which are important core concepts. I'd love to have a syntax like { foo(%1, bar) } standing for |x| { foo(x, bar) } though. I'm not aware of any language that has this!

Mathematica has this:

    In[1]:  Map((1 + #1)&, {a, b, c})
    Out[1]: {a + 1, b + 1, c + 1}
See https://reference.wolfram.com/language/ref/Function.html.en for the full story.

Re: Matt Godbolt sold me on Rust by showing me C++

#428

Post by wffurr »

steveklabnik wrote: post #10
wffurr wrote: post #5

Earlier quoted context omitted.

This seems like such an obvious thing to have - where is it? Zig, Odin, etc. all seem much more ambitious.

There have been attempts over the years. See here, a decade ago: https://blog.regehr.org/archives/1287 > eventually I came to the depressing conclusion that there’s no way to get a group of C experts — even if they are knowledgable, intelligent, and otherwise reasonable — to agree on the Friendly C dialect. There are just too many variations, each with its own set of performance tradeoffs, for consensus to be possibl…

That was fascinating reading and a graveyard of abandoned "better C" dialects: SaferC, Friendly C, Checked C, etc.

Re: Matt Godbolt sold me on Rust by showing me C++

#429

Post by tormeh »

blub wrote: post #387
lmm wrote: post #350

Earlier quoted context omitted.

> I just almost never have problems with this sort accidental conversion in practice. 95% of C++ programmers claim this, but C++ programs continue to be full of bugs, and they're usually exactly this kind of dumb bug. > will be noticed by literally just running the code once. Maybe. If what you're doing is "tricky mathematical algorithms", how would you even know if you were making these mistakes and not noticing the…

It’s the sociology of software development. The guild of software developers has no real standards, no certification, no proven practices outside and while continuing to depend on the whims of project managers, POs and so-caled technical leaders and others which can’t tell quality code from their own ass. There’s usually no money in writing high-quality software and almost everything in a software development project…

Maybe. But I wouldn't diss better languages, linters, and other tool inprovements. These systematically increase quality at very low cost. It boggles my mind that the whole industry is not falling over itself to continuously embrace better tools and technology.

Re: Matt Godbolt sold me on Rust by showing me C++

#430

Post by affyboi »

CJefferson wrote: post #239
jchw wrote: post #228

Earlier quoted context omitted.

Assertions are debug-only. Exceptions are usually not guaranteed to be available and much of the standard library doesn't require them. You could std::abort, and that's about it. I think the issue is that this just isn't particularly good either. If you do that, then you can't catch it like an exception, but you also can't statically verify that it won't happen. C++ needs less of both undefined behavior and runtime e…

I agree these things would be better, but I don’t understand how anyone can think UB is better than abort. (Going to moan for a bit, and I realise you aren’t responsible for the C++ standards mess!) I have been hearing for about… 20 years now that UB gives compilers and tools the freedom to produce any error catching they like, but all it seems to have done in the main is give them the freedom to produce hard to debu…

> but why not just enforce that as standard

I don’t think people want that as standard. The whole point of using C++ tends to be because you can do whatever you need to for the sake of performance. The language is also heavily driven by firms that need extreme performance (because otherwise why not use a higher level language)

There are knobs like stdlib assertions and ubsan, but that’s opt-in because there’s a cost to it. Part of it is also the commitment to backwards compatibility and code that compiled before should generally compile now (though there are exceptions to that unofficial rule).

Post reply on HN