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

491–500 of 675 posts

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

#491

Post by craftkiller »

aaronmdjones wrote: post #452
bionhoward wrote: post #434

Earlier quoted context omitted.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…

Indent by 4 spaces to get code blocks on HN. Like this

You only need 2 spaces: https://news.ycombinator.com/formatdoc

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

#492

Post by steveklabnik »

aaronmdjones wrote: post #452
bionhoward wrote: post #434

Earlier quoted context omitted.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…

Indent by 4 spaces to get code blocks on HN. Like this

You only need 2. https://news.ycombinator.com/formatdoc

> Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)

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

#493

Post by steveklabnik »

fooker wrote: post #372
dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

One of the strengths of C++ is the ability to build features like this as a library, and not hardcode it into the language design. Unless you specifically want the ‘?’ operator, you can get pretty close to this with some clever use of templates and operator overloading. If universal function call syntax becomes standardized, this will look even more functional and elegant.

Rust also started with it as a library, as try!, before ?. There were reasons why it was worth making syntax, after years of experience with it as a macro.

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

#494

Post by genrilz »

codedokode wrote: post #355
ultimaweapon wrote: post #300

Earlier quoted context omitted.

Rust is the only language I can easily control how integer overflow should behave. I can use `var1.wrapping_add(var2)` if I want the result to be wrapped or `var1.checked_add(var2)` if I don't want it to overflow.

The functions are so verbose and inconvenient that even Rust developers themselves do not use them. For example, in this code [1] they used a wrapping addition instead of "checked_add" because it is faster to write. For comparison, Swift uses "+" for checked addition and as a result, majority of developers use checked addition by default. And in Rust due to its poor design choices most developers use wrapping additio…

The reason '+ 1' is fine in the example you gave is that length is always less than or equal to capacity. If you follow 'grow_one' which was earlier in the function to grow the capacity by one if needed, you will find that it leads to the checked addition in [0], which returns an error that [1] catches and turns into a panic. So using '+1' prevents a redundant check in release mode while still adding the check in debug mode in case future code changes break the 'len Of course, if you don't trust the standard library, you can turn on overflow checks in release mode too. However, the standard library is well tested and I think most people would appreciate the speed from eliding redundant checks.

  [0]: https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#651
  [1]: https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#567

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

#495

Post by bigbuppo »

choeger wrote: post #295

All this has been known in the PL design community for decades if not half a century by now. Two things are incredibly frustrating when it comes to safety in software engineering: 1. The arrogance that "practitioners" have against "theorists" (everyone with a PhD in programming languages) 2. The slowness of the adoption of well-tested and thoroughly researched language concepts (think of Haskell type classes, aka, Ru…

It's weird that this sort of debate around C++ often leaves out the fact that many of the problems with C++ were known before C++ even existed. Outside of a few specific buckets, there is no reason to use C++ for any new projects, and really, there never has been. If you can't stomach Rust for some reason, and I'm one of those people, there are plenty of choices out there without all the pitfalls of C++ or C.

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

#496

Post by groos »

sanderjd wrote: post #456
choeger wrote: post #295

All this has been known in the PL design community for decades if not half a century by now. Two things are incredibly frustrating when it comes to safety in software engineering: 1. The arrogance that "practitioners" have against "theorists" (everyone with a PhD in programming languages) 2. The slowness of the adoption of well-tested and thoroughly researched language concepts (think of Haskell type classes, aka, Ru…

Yep, this article is a good example of one way that c++ is bad, but it's not really a great example of rust being particularly good; many other languages support this well. I'm very glad Rust is one of those languages though!

I had the same thought - what Matt's examples required was strong typing and that has existed for very long time outside of the C family world.

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

#497

Post by craftkiller »

hoppp wrote: post #480
dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

Its true but using unwrap is a bit boring , I mean...boring is good but its also boring.

You shouldn't be using unwrap.

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

#498

Post by J_Shelby_J »

bionhoward wrote: post #434
zozbot234 wrote: post #40

Earlier quoted context omitted.

> The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions This isn't really true since Rust has panics. It would be nice to have out-of-the-box support for a "no panics" subset of Rust, which would also make it easier to properly support linear (no auto-drop) types.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…

But can deny the use of all operations that might panic like indexing an array?

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

#499

Post by runevault »

kylereeve wrote: post #476
runevault wrote: post #253

Earlier quoted context omitted.

When I've dabbled in C++ recently it has felt like using CMake fetching github repos has been the least painful thing I've tried (dabbled in vcpkg and conan a bit), since most libraries are cmake projects. I am no expert so take it with a grain of salt, but that was how it felt for me.

Do you have CMake actually run `git clone`, or do you clone separately and point CMake at the `FIND_X` files?

I was using fetch content or the like, there is a package that comes after a certain version of cmake where you can tell it this is a git repo and it handles all that for you. It has been a few months since I did this so I don't remember the details fully

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

#500

Post by o11c »

trealira wrote: post #486
o11c wrote: post #35

Earlier quoted context omitted.

I too have been thinking a lot about a minimum viable improvement over C. This requires actually being able to incrementally port your code across: * "No implicit type conversions" is trivial, and hardly worth mentioning. Trapping on both signed and unsigned overflow is viable but for hash-like code opting in to wrapping is important. * "Safer strings" means completely different things to different people. Unfortunat…

> The lack of proper C99 floating-point support, even in $CURRENTYEAR What do you mean? What's wrong with floating point numbers in C99?

I mean things like: compilers don't support the pragmas, and if the compiler can "see" constants they are often evaluated with the wrong rounding mode.

I'm far from an expert but I've seen enough to know it's wrong.

Post reply on HN