16

Are there any normal people who like RUST? Seems like RUST enthusiasts only consist of people with C++ PTSD, raving fanatics and cringe-worthy hipsters :S

Comments
  • 2
    Exactly my fetish... not 😄
  • 4
    Although there are many hipsters, the language is really nice to work with.
  • 4
    Yeah, Rust is pretty over-hyped (especially against C++). But then, it's a nice language with some cool ideas.
  • 1
    Always apprehensive about new languages because of library support
  • 2
    There's just so much syntax with c++. The tooling and compiler support is second to none but the language standard itself is just unpleasant IMO
  • 1
    LOL C++ PTSD :-) Well yeah that's what you get with a language that is a trashbin of all mutually incompatible ideas that ever came along.

    I'm not yet into Rust, but I'm quite excited because out of all these new hipster languages, Rust doesn't require an expensive runtime and is basically suited for embedded.

    The toolchain you need for reliable embedded systems in C is actually insane, like expensive static code checkers with interprocedural analysis because arrays in C decay to pointers when passed to a function. Something like CppCheck on steroids.

    ADA is a total failure - design by government committee and initial idiotic tool pricing. Rust could come to fill that void. And it has C bindings for parts that are so low level that you need either C or assembly.
  • 0
    Rust is nice btw. The toolkit seems very well thought. And syntax-wise also it is a charmer.
  • 1
    @Fast-Nop hey hey, no need to hate on C++ so much, it already has a well established toolchain and you can do some seriously crazy magic with templates and stuff :)

    And Rust as a language still has a ton of pain points.

    If you're interested in a better-designed language which doesn't need an expensive runtime either may I suggest having a look at D? It's like an experienced C++ user made C++ like language with a saner and more consistent approach (which is exactly what happened). I've been using it for a while, it's really nice.
  • 3
    @RememberMe exactly the crazy template stuff is one of the big red flags because it boils down to write-only-code. That's why using templates besides those in the STL is actually forbidden in quite some C++ shops.

    With D, can you disable the garbage collector completely and still write useful code? GC is a no-go for reliable embedded systems because dynamic memory allocation itself is a no-go.
  • 1
    @Fast-Nop wait what, no
    There are tons of useful and widely used libraries like Eigen that rely on templates and honestly it's pretty easy to read once you get the hang of it (having never worked in a high-safety embedded systems place I can't really say much about that, but plenty of C++ people use them).

    Yes, it's possible to have D code that doesn't use the GC (though whether you can avoid stuffing the GC in when deploying D code is something I don't know, I would actually like to check that). The GC only runs when you dynamic allocate stuff via GC managed memory.

    Also, question, how is it that secure systems development isn't done in, say, Lisp or ML or some other language where static analysis is much, much easier than in C-style languages? Then all you have to verify is the runtime, and Lisp implementations can be pretty small.
  • 1
    @RememberMe Nothing against using libraries - especially for numerics, it makes sense not to reinvent the wheel, just like for crypto.

    The issue with dynamic memory management is not just real time. It's also memory fragmentation on a CPU that typically doesn't have an MMU. So the system accrues invisible state under the hood and isn't really testable anymore.

    As for LISP, it's because the language sucks and most idiomatic LISP code is write only throw away code, especially because of the "mysterious tuple problem": https://codeproject.com/Articles/... . And of course there's also dynamic memory stuff going on behind the scenes.

    On top of that, "secure" stuff that tries to avoid state is often useless for embedded because the point isn't computation, it's the exhibited behaviour - which in turn is based on state.
  • 1
    @Fast-Nop right, makes sense. I've seen the headaches caused by dynamic memory in high performance C++ programs too, it's a giant headache to keep fragmentation down without much overhead.

    May I also say that I really appreciate you writing such detailed replies to my comments, I'm really learning a lot here :)
  • 2
    I am 2nd grade student. My first project that is more than something is written in Rust. It is most restrictive language I have ever used but it is not necessarily bad. I think biggest reason I use it has built in build and testing tools.
  • 1
    Rust is the first language I used that actually enforces the type system. That alone stops a lot of bugs. Mainly null pointers. And I like to think that the rust compiler makes me write better code than I would without it.
  • 0
    I really like a lot of the ideas behind Rust, especially ownership and deterministic destruction.

    However what ended up turning me off it was its lack of proper object-orientedness. Doing things like inheritance and polymorphism in Rust does not look straightforward at all.

    I love OOP. I don't understand why so many new languages feel they need to fix what imo isn't broken.
  • 0
    @devios1 when I looked at the class diagram of javafx i realised that OOP is broken...
  • 0
    @Lythenas There's a difference between not overdoing your class hierarchy and not having any inheritance at all.
  • 1
    @devios1 yes maybe javafx overdid it. But I think stucts and traits fits rust a lot better than inheritance. Because it is a systems programming language you need controlled over how your data is structured. If a subclass can add fields you don't have that control.
  • 1
    @Lythenas I haven’t written off Rust entirely yet, but I’ve decided it’s different enough that I won’t try to learn it until I have something more concrete to work with. Which means I’m sticking with C++ for now.
Add Comment