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

481–490 of 675 posts

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

#481

Post by burntsushi »

selfmodruntime wrote: post #411
kelnos wrote: post #67

Earlier quoted context omitted.

I wish more people (and crate authors) would treat panic!() as it really should be treated: only for absolutely unrecoverable errors that indicate that some sort of state is corrupted and that continuing wouldn't be safe from a data- or program-integrity perspective. Even then, though, I do see a need to catch panics in some situations: if I'm writing some sort of API or web service, and there's some inconsistency in…

Honestly, I don't think libraries should ever panic. Just return an UnspecifiedError with some sort of string. I work daily with rust, but I wish no_std and an arbitrary no_panic would have better support.

Example docs for `foo() -> Result`:

    # Errors

    `foo` returns an error called `UnspecifiedError`, but this only
    happens when an anticipated bug in the implementation occurs. Since
    there are no known such bugs, this API never returns an error. If
    an error is ever returned, then that is proof that there is a bug
    in the implementation. This error should be rendered differently
    to end users to make it clear they've hit a bug and not just a
    normal error condition.
Imagine if I designed `regex`'s API like this. What a shit show that would be.

If you want a less flippant take down of this idea and a more complete description of my position, please see: https://burntsushi.net/unwrap/

> Honestly, I don't think libraries should ever panic. Just return an UnspecifiedError with some sort of string.

The latter is not a solution to the former. The latter is a solution to libraries having panicking branches. But panics or other logically incorrect behavior can still occur as a result of bugs.

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

#482

Post by bunderbunder »

jeffparsons wrote: post #365
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've occasionally wondered about the lack of currying in Rust; it feels like something that can be done mechanically at compile time, so why not support it? Perhaps to do it cleanly (without more magical privileged functions in core) would require variadic generics?

You can absolutely curry functions in Rust. You just have to do it manually because there's no syntactic sugar for it.

I think that's a good thing. A curried function is a function that takes one argument, and returns a closure that captures the argument. That closure might itself take another argument, and return a new closure that captures both the original argument and the second one. And so on ad infinitum. How ownership and borrowing works across that chain of closures could easily become a touchy issue, so you probably want to be making it as explicit as possible.

Or perhaps better yet, find an easier way to accomplish the same task. Maybe use a struct to explicitly carry the arguments along until you're ready to call the function.

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

#483

Post by tialaramex »

monkeyelite wrote: post #470
tialaramex wrote: post #468

Earlier quoted context omitted.

No, implicit conversion is a deliberate C++ feature and no analog existed in C. Like a lot of awful things about C++ this is their own choice and it's frustrating that they try to blame C for their choices. In C++ when we define a class Foo (a thing which doesn't exist in C) and we write a constructor Foo(Bar x) (which doesn't exist in C) which takes a single parameter [in this case a Bar named x], that is implicitly…

> No, implicit conversion is a deliberate C++ feature and no analog existed in C No. > it's not a C choice, it's not about "compatibility". One of the design of C++ classes is that you can create a class as powerful as int - you can’t do that without implicit conversion.

It would have been perfectly possible - not to mention obviously better - to make people actually write what they meant when defining the new type and this has no impact on the dubious priority of being able to make your own int type by gifiting your type implicit conversions in use if that's what you want which it often is not.

This is just another thing on the deep pile of wrong defaults in C++.

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

#484

Post by bunderbunder »

tormeh wrote: post #425
andrepd wrote: post #381

Earlier quoted context omitted.

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.

From what I've seen, partial application tends to be used for utmost good in dialects of ML, and utmost evil most everywhere else. Chaotic neutral in R/tidyverse.

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

#485

Post by legobmw99 »

bunderbunder wrote: post #477

This is actually the point where Rust starts to frustrate me a little bit. Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management. A lot of my colleagues seem to primarily be falling in love with Rust because it's doing a good job at some basic things that hav…

Based on the rest of your comment I suspect you're already familiar, but a decent candidate for "Rust with a GC" is OCaml, the language the first Rust compiler was written in.

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

#486

Post by trealira »

o11c wrote: post #35
markus_zhang wrote: post #3

What if we have a C that removes the quirks without adding too much brain drain? So no implicit type conversions, safer strings, etc.

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?

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

#487

Post by thrwyexecbrain »

taylorallred wrote: post #158
thrwyexecbrain wrote: post #132

The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testi…

Cool that you're using areas/pools for lifetimes. Are you also using custom data structures or stl (out of curiosity)?

Nothing fancy, I found that one can do almost anything with std::vector, a good enough hash map and a simple hand-rolled intrusive list.

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

#488

Post by bunderbunder »

legobmw99 wrote: post #485
bunderbunder wrote: post #477

This is actually the point where Rust starts to frustrate me a little bit. Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management. A lot of my colleagues seem to primarily be falling in love with Rust because it's doing a good job at some basic things that hav…

Based on the rest of your comment I suspect you're already familiar, but a decent candidate for "Rust with a GC" is OCaml, the language the first Rust compiler was written in.

It's close. Perhaps there's an interesting conversation to be had about why OCaml hasn't taken over the world the way Rust has.

The toolchain might be a first candidate. Rust's toolchain feels so very modern, and OCaml's gives me flashbacks to late nights trying to get my homework done on the department's HP-UX server back in college.

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

#489

Post by Arnavion »

renox wrote: post #367
Arnavion wrote: post #208

Earlier quoted context omitted.

To be clear, the only difference between Rust and C here is whether the conversion happens by default or not. Rust doesn't do the conversion by default but will let you do it if you want to, with `as`. There are also more type-safe conversion methods that perform a more focused conversion. Eg a widening conversion from i8 -> i16 can be done with .into(), a narrowing conversion from i16 -> i8 can be done with .try_int…

That's funny, if memory serves 'as' should be avoided in Rust and other casts should be used. That's a Rust wart which cannot be fixed..

Yes that's correct, for exactly the reason that it is more likely to keep compiling and possibly not do what you intended if the original value's type changes due to refactoring. However there are still a few conversions that don't have alternatives to `as` - truncating conversions (eg i64 -> i32 that intentionally discards the upper half), int float conversions (eg i64 -> f64, both truncating and checked conversions), unsized pointer casts (eg *const [MaybeUninit] -> *const [u8], `.cast()` only works for Sized target), and probably a few more.

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

#490

Post by Starlevel004 »

bunderbunder wrote: post #477

This is actually the point where Rust starts to frustrate me a little bit. Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management. A lot of my colleagues seem to primarily be falling in love with Rust because it's doing a good job at some basic things that hav…

> Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management.

It also has half implementations of all the useful features (no distinct enum variant types, traits only half-exist) because you have to code to the second, hidden language that it actually compiles to.

Post reply on HN