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

461–470 of 675 posts

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

#461

Post by tialaramex »

nailer wrote: post #269

> Before we go any further, let me just say he acknowledges floating point is not right for price and later talks about how he usually deals with it. But it makes for a nice example, bear with us. OK but "this makes for a nice example" is silly, given that the only reason the example throws an error is that you used a float here, when both `quantity` and `price` would have been ints. error[E0308]: arguments to this f…

Why are they "ints" ? One of the first things we realise, in both C++ and Rust, is that we mostly don't want these primitives like "int", we want our own user defined types, and Rust is better at that in practice.

In the C and C++ people tend to actually write the file descriptor will be an int, and the timeout will be an int, and the user account number will be an int, and the error code will be an int... because the language doesn't help much when you don't want that.

In the Rust people actually write the file descriptor will be an OwnedFd (from the stdlib) and the timeout will be a Duration (from the stdlib), and user account number might be their own AcctNo and that error code is maybe MyCustomError

This is a language ethos thing, C++ got string slices after Rust despite the language being much older. String slices which are a really basic central idea, but eh, C++ programmers a decade ago just had char * pointers instead and tried not to think about it too much. Still today plenty of C++ APIs don't use string slices, don't work with a real duration type, and so on. It's technically possible but the language doesn't encourage this.

What C++ does encourage is magic implicit conversion, as with this f64 versus i64 case.

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

#462

Post by icen »

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!

In K the arguments are named x y z by default, so you just write:

    { foo[x, bar] }

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

#463

Post by monkeyelite »

simiones wrote: post #403
monkeyelite wrote: post #384

Earlier quoted context omitted.

> You're giving up scalability massively you’re vastly over estimating the overhead of processes and number of simultaneous web connections. > only to gain a minor amount of safety What you’re telling me is performance (memory?) is such a high priority you’re willing to make correctness and security tradeoffs. And I’m saying thats ok, one of those is crashing might bring down more than one request. > one that is virt…

Please find one web server being actively developed using one process per request. Handling thousands of concurrent requests is table stakes for a simple web server. Handling thousands of concurrent processes is beyond most OSs. The context switching overhead alone would consume much of the CPU of the system. Even hundreds of processes will mean a good fraction of the CPU being spent solely on context switching - whi…

> Handling thousands of concurrent processes is beyond most OS

It works fine on Linux - the operating system for the internet. Have you tried it?

> good fraction of the CPU being spent solely on context switching

I was waiting for this one. Threads and processes do the same amount of context switching. The overhead of processes switch is a little higher. The main cost is memory.

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

#464

Post by blub »

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…

If the practitioners haven’t adopted what you’re offering for 50+ years, that thing can’t be good.

Rust is also struggling with its “too theoretical” concepts by the way. The attempts of the community to gaslight the practitioners that the concepts are in fact easy to learn and straightforward are only enjoying mild success, if I may call it that.

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

#465

Post by monkeyelite »

kevincox wrote: post #398
monkeyelite wrote: post #384

Earlier quoted context omitted.

> You're giving up scalability massively you’re vastly over estimating the overhead of processes and number of simultaneous web connections. > only to gain a minor amount of safety What you’re telling me is performance (memory?) is such a high priority you’re willing to make correctness and security tradeoffs. And I’m saying thats ok, one of those is crashing might bring down more than one request. > one that is virt…

> you’re vastly over estimating the overhead of processes and number of simultaneous web connections. It's less the actual overhead of the process but the savings you get from sharing. You can reuse database connections, have in-memory caches, in-memory rate limits and various other things. You can use shared memory which is very difficult to manage or an additional common process, but either way you are effectively…

You certainly can get savings. I question how often you need that.

I just said one of the costs of those saving is crashing may bring down multiple requests - and you should design with that trade off.

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

#466

Post by monkeyelite »

tialaramex wrote: post #393
monkeyelite wrote: post #351

This article compares onlye one specific feature of C++ with Rust - integral type conversions.

All of C++ has implicit type conversions. The language even has a keyword (explicit) to try to reign this in because it's so obviously a bad idea. In Rust what they'd do if they realised there's a problem like this is make explicit conversion the default, with a language Edition, and so within a few years just everybody is used to the improved language. In C++ instead you have to learn to write all the appropriate bu…

> because it's so obviously a bad idea.

Agreed. The history here is compatibility with C type conversion.

I just expected a more compelling Rust /C++ comparison but we got an emphasis of a poorly designed feature which the standard has taken steps to improve already.

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

#467

Post by globalnode »

notimetorelax wrote: post #333
globalnode wrote: post #327

My admittedly uninformed impression of Rust is that its a lot like Go (in spirit?), a language invented to shepherd novice programmers into not making mistakes with resource usage. I imagine faceless shameless mega-corps with thousands of Rust/Go peons coding away on the latest soulless business apps. Designed to funnel the ignorant masses down corridors of dark pattern click bait and confusing UX. Having exposed my…

Those mega corps that you talk about use C++ too. It’s just a false dichotomy argument you’re making.

True enough, I was going down a path there and got a little excited :S

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

#468

Post by tialaramex »

monkeyelite wrote: post #466
tialaramex wrote: post #393

Earlier quoted context omitted.

All of C++ has implicit type conversions. The language even has a keyword (explicit) to try to reign this in because it's so obviously a bad idea. In Rust what they'd do if they realised there's a problem like this is make explicit conversion the default, with a language Edition, and so within a few years just everybody is used to the improved language. In C++ instead you have to learn to write all the appropriate bu…

> because it's so obviously a bad idea. Agreed. The history here is compatibility with C type conversion. I just expected a more compelling Rust /C++ comparison but we got an emphasis of a poorly designed feature which the standard has taken steps to improve already.

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 adopted as a conversion for your new user defined type and by default without any action on your part the compiler will just invoke that constructor to make a Bar into a Foo whenever it thinks that would compile.

This is a bad choice, and it's not a C choice, it's not about "compatibility".

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

#469

Post by estebank »

imtringued wrote: post #362
Arnavion wrote: post #121

Earlier quoted context omitted.

>many functions allocate memory and what are they supposed to do when there is no memory left? Return an AllocationError. Rust unfortunately picked the wrong default here for the sake of convenience, along with the default of assuming a global allocator. It's now trying to add in explicit allocators and allocation failure handling (A:Allocator type param) at the cost of splitting the ecosystem (all third-party code,…

>Return an AllocationError. Rust unfortunately picked the wrong default here for the sake of convenience, along with the default of assuming a global allocator. It's now trying to add in explicit allocators and allocation failure handling Going from panic to panic free in Rust is as simple as choosing 'function' vs 'try_function'. The actual mistakes in Rust were the ones where the non-try version should have produce…

In order to have true ergonomic no_panic code in Rust you'd need to be able to have parametricity on the panic behavior: have a single Box::new that can be context determined to be panicky or Result based. It has to be context determined and not explicitly code determined so that the top most request for the no_panic version to be propagated all the way down to stdlib through the entire stack. If you squint just a bit, you can see this is the same as maybe async, and maybe const, and maybe allocate, and maybe wrapping/overflowing math, etc. So there's an option to just add try_ methods on the entire stdlib, which all the code between your API and the underlying API need to use/expose, or push for a generic language level mechanism for this. Which then complicates the language, compiler and library code further. Or do both.

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

#470

Post by monkeyelite »

tialaramex wrote: post #468
monkeyelite wrote: post #466

Earlier quoted context omitted.

> because it's so obviously a bad idea. Agreed. The history here is compatibility with C type conversion. I just expected a more compelling Rust /C++ comparison but we got an emphasis of a poorly designed feature which the standard has taken steps to improve already.

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.

Post reply on HN