Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday January 16 2017, @08:42PM   Printer-friendly
from the comparing-tools dept.

Eric S Raymond, author of "The Cathedral and the Bazaar", blogs via Ibiblio

I wanted to like Rust. I really did. I've been investigating it for months, from the outside, as a C replacement with stronger correctness guarantees that we could use for NTPsec [a hardened implementation of Network Time Protocol].

[...] I was evaluating it in contrast with Go, which I learned in order to evaluate as a C replacement a couple of weeks back.

[...] In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for [a simple IRC] server.

Even things that should be dirt-simple, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done.

The contrast with Go is extreme. By four days in of exploring Go, I had mastered most of the language, had a working program and tests, and was adding features to taste.

Have you tried using Rust, Go or any other language that might replace C in the future? What are your experiences?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by linuxrocks123 on Tuesday January 17 2017, @05:37PM

    by linuxrocks123 (2557) on Tuesday January 17 2017, @05:37PM (#454969) Journal

    - The collaboration stuff you mention is what coding standards are for.
    - Frameworks mostly don't make use of anything remotely obscure in their outward-facing APIs.
    - Regarding rvalue references, they cause no problems. They're specifically designed so that you can completely ignore them if you want; you just won't get the performance benefits if you do.

    Actually, even if you do ignore rvalue references, you'll still get the benefits when you use rvalue reference-enabled STL containers. What a deal.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by tonyPick on Wednesday January 18 2017, @08:04AM

    by tonyPick (1237) on Wednesday January 18 2017, @08:04AM (#455276) Homepage Journal

    - The collaboration stuff you mention is what coding standards are for.

    very true, but unless you're running the whole show then the assumption that they're going to fit with your specific view of modern C++ is optimistic; for example I've seen guidelines that heavily restrict the coders from implementing functionality using template metaprogramming, which is a feature you seem quite keen on.

    Everybody agrees you only need a "useful" subset of the language, but IME nobody actually agrees on what that subset is.

    - Frameworks mostly don't make use of anything remotely obscure in their outward-facing APIs.

    I wouldn't call unions (your example) as obscure; they're uncommon (mainly since C++ restricts you to default constructors for union members), but they're a routine part of the language, and quite common in places, particularly C-compatible style API definitions. Not to mention the wacky-hacky stuff you sometimes see on vendor specific APIs.

    (And if you think unions are obscure but variants aren't then I'm guessing that you've never written a DBus client and had to figure out what an 'oa{sa{sv}}' actually contains)...

    - Regarding rvalue references, they cause no problems. They're specifically designed so that you can completely ignore them if you want; you just won't get the performance benefits if you do.

    Since your OP mentioned them as "esoteric stuff" I'd figured to re-use them as an example - feel free to replace that with any feature of the language you personally hate, be that lambdas, assertions or whatever. It's not like C++ is exactly short on features to dislike :)

    Sooner or later you will meet someone who will agree with you on the whole "why can't we all just use modern C++" thing, but will then name your pet hated feature as an essential part of the "modern" language. (Outside of manual memory management, perhaps, because everybody hates that).