Live data from Hacker News

Switching from C++ to Rust

laplab.me

271–280 of 289 posts

Re: Switching from C++ to Rust

#271
I read the article only not to be able to to find any meaningful notes. I did not expect versus so I support the writer that it's weak point to compare on the versus basis, but still as a person who actively maintains C++ experience since 1996 and been through Borland, Watcom, Visual C, old standards, C++11, C++14, and tries to follow isocpp.org standard discussions to understand where C++ is heading as standard and still use clang, cl and gcc regularly and.. I have zero experience in RUST, I only heard from many seasoned C++ developers that this platform comes with significant value proposition.

I had no chance to meet it yet, nor I have currently time to experiment, thus I was curious about the article to help me understand the differences. The only thing I remembered from the article is that compiler error messaging are different in the two and more clearly defined in RUST. Plus classical anti C++ example => memory management. C#, Java already addressed that, so I expect RUST has something more unique than that. Can somebody point to better article that shows some practical appliances why to switch to RUST if you have significant C++ experience?

Not that I want to bitch the author. Nice try explaining something, bue you know fixing error messages in C++ code was never a random staring at the code in my case.

Re: Switching from C++ to Rust

#274

Earlier quoted context omitted.

The article specifically mentions not holding said candle as a positive. I would too. They're confusing at best and undebuggable at worst, and virtually everything you can do with them that you can't do with generics is something it'd be better for everyone if you didn't do.

Oh here we go again. “Everything rust can’t do is an antipattern” is not a valid argument. Tuples for instance are a library feature in C++ but have to be a language feature in rust. Plenty of other useful things that C++ can do and rust cannot. https://youtu.be/gOdcNko2xc8 https://youtu.be/tiAVWcjIF6o

[deleted]

Re: Switching from C++ to Rust

#275
post #232

Earlier quoted context omitted.

I just wish that Rust’s enum Variants were types… maybe someday! :)

It's not exactly what you want but you get most of the benefit by just wrapping types in enum variants.

It's a request for the following to be valid

    enum X {
        A,
        B,
    }
    fn foo() -> X::A {
        X::A
    }
which helps a lot when composing state machines. In the meantime, you can indeed do what you propose:

    enum X {
        A(Foo),
        B(Bar),
    }
    struct Foo;
    struct Bar;
    fn foo() -> Foo {
        Foo
    }

Re: Switching from C++ to Rust

#276

Earlier quoted context omitted.

The article specifically mentions not holding said candle as a positive. I would too. They're confusing at best and undebuggable at worst, and virtually everything you can do with them that you can't do with generics is something it'd be better for everyone if you didn't do.

Oh here we go again. “Everything rust can’t do is an antipattern” is not a valid argument. Tuples for instance are a library feature in C++ but have to be a language feature in rust. Plenty of other useful things that C++ can do and rust cannot. https://youtu.be/gOdcNko2xc8 https://youtu.be/tiAVWcjIF6o

So, in response to 'templates are generics + things you shouldn't do', your counterargument is a non sequitur about tuples, a video titled 'Code You Should Learn From & Never Write', and a video about introductory templates which doesn't actually contain any counterexamples?

Re: Switching from C++ to Rust

#277
post #198
post #188

Earlier quoted context omitted.

Rust’s memory management is not hard, it’s just tedious. If programming in the future will mean annotating the crap out of everything then garbage-collected languages start to become attractive - see golang competing with Rust in unexpected areas. Perhaps the only hard part is storing and passing references everywhere, which may mean that one has to act like an automaton and patiently type their lifetimes to the Rust…

Well, a huge swath of the developer community did realize it like 20 years ago — the vast majority of applications can absolutely get away with a GC, and that’s the correct choice from the perspective of developer productivity and safety. Rust is a huge win for the small niches where the GC overhead is unacceptable, because it is completely novel in its memory safety, which is absolutely a must and was neglected for…

All true, but I suspect the end goal Rust's type system wasn't to eliminate GC. It was "fearless concurrency". You can see this in languages that encourage multithreadeding and have a GC. In Go memory allocation is easy because of GC, but even so naively put working single threaded Go code in a multithreaded environment and it will likely segfault. GC doesn't solve the currency problem.

I suspect it was just happy circumstance that a type system so strong it makes memory access compile time checkable is also strong enough to eliminate the overheads of GC. So they did that too.

But the claim that all this tediousness is there to eliminate GC sort of misses the point - that's not the reason they introduced it. Rust's complex type system is a type of formal proof system that eliminates a lot of bugs at compile time. The "sum types" discussion above talks about another class of bugs it eliminates. Eliminating bugs at compile time is the point - not making memory allocation easier.

Re: Switching from C++ to Rust

#278
post #198

Earlier quoted context omitted.

Well, a huge swath of the developer community did realize it like 20 years ago — the vast majority of applications can absolutely get away with a GC, and that’s the correct choice from the perspective of developer productivity and safety. Rust is a huge win for the small niches where the GC overhead is unacceptable, because it is completely novel in its memory safety, which is absolutely a must and was neglected for…

All true, but I suspect the end goal Rust's type system wasn't to eliminate GC. It was "fearless concurrency". You can see this in languages that encourage multithreadeding and have a GC. In Go memory allocation is easy because of GC, but even so naively put working single threaded Go code in a multithreaded environment and it will likely segfault. GC doesn't solve the currency problem. I suspect it was just happy ci…

Well, Rust doesn’t solve concurrency issues either, it can only prevent data races which is a tiny subset only. There are different kinds of race conditions as well, deadlocks, livelocks, etc which are generally unsolvable.

And to be honest, Rust doesn’t have all that strong type system compared to Haskell/ML which introduced these concepts in the first place. Also, there are plenty of languages in the category of “managed, with a strong type system”.

Re: Switching from C++ to Rust

#279
post #225

Earlier quoted context omitted.

Esp-wifi is very actively being updated, looks like C3 is supposed to work[0][1], so if you tried more than a few weeks ago it probably changed. [0]: https://github.com/esp-rs/esp-wifi#current-support [1]: https://github.com/esp-rs/esp-wifi#ble

Thanks for mentioning it. I already tried using it a few months ago and brushed it off as still being a WIP, but it still didn't work when I tried again just a few days ago. Asking in the Matrix chat when first trying it sadly only got me a "works for me" from the developers. What Espressif is doing with their esp-idf and porting it to Rust is promising, but overall it still needs work. Using the toolchain to develop…

That’s about my experience too. Which is far too fiddly for us to rely on at work for production tasks. I basically keep checking back every six months or so: I’m hopeful that in a year, year and a half, I could replicate what we’ve done with our project on esp-rs entirely. Fingers crossed anyway, but right now there are quite a few showstoppers.

Re: Switching from C++ to Rust

#280

The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…

… or sealed classes in Java
Post reply on HN