9 ms·
I was interested in learning Rust as a safer alternative to C a few years back, and have been observing its progress from afar. I'm much less optimistic about i
by daliwali 9y ago
I was interested in learning Rust as a safer alternative to C a few years back, and have been observing its progress from afar. I'm much less optimistic about it now, though I only have a layman's understanding of it. The language seems to be more cumbersome to write than many other languages due to its design choices. It may be safer, but not as "ergonomic" subjectively, which ultimately affects productivity. It's hard to think of a good reason to use it, other than the safety features.
- sqeaky 9y agoMost of the changes in this log, and past change logs I have read agree with you. They mention it often and much of the changes work on that. That have chosen safety first and appear to be working on ergonomics without sacrificing that.
- mathw 9y agoErgonomic improvements are a major focus for the Rust team's 2017 roadmap, both in language changes and tooling. But they'll never sacrifice the core safety principles of the language to do it.
- pcwalton 9y agoI'm far more productive in Rust than I am in C. The amount of time I spend writing for loop boilerplate alone is worth the price of admission. Pretty much all of the ergonomics improvements this year have been improving on things you can't do in C to begin with. Like automatic serialization (serde). Or const generics. Or error handling via ?. Or pretty much any reasonable string manipulation ever. There's a legitimate debate to be had with the ergonomics of C++ vs. Rust (though I think Rust wins there too). But not with C. C, as a language that makes you jump through hoops to even get a hash table, doesn't even come close.
- goalieca 9y agopeople write better c than c++ because they are less tempted to over-architect. We've all come across terrible meta-templated c++ code with abuse of OOP all in the name of "information hiding". The main problem against c is the puny standard library. It would be nice to have a few more built-ins. I think c++ without inheritance would be a very nice language.
- pcwalton 9y agoC has so many design flaws, from the lack of reasonable iterators to null pointers to the preprocessor to bizarre type syntax to switch fall through to terrible error handling to no generics, etc. The attempts to patch the more broken parts of its design (e.g. ergonomics favoring signed induction variables in for loops) have resulted in more problems (e.g. signed overflow being undefined behavior). As a language from 1978, it was good in its day, but it's not worth saving anymore. It should become a respected piece of history.
- milesrout 9y ago>from the lack of reasonable iterators p = p->next; and p++ are perfectly reasonable iterators.
- pjmlp 9y agoC was already quite poor in 1993 when I got to compare it with Turbo Pascal 6.0 for MS-DOS, my main tool at the time. With all these years the amount of UB, memory corruption issues and security exploits only got bigger. We need a major IoT meltdown to get rid of it, unfortunately it won't happen until the industry lets UNIX clones go.
- btrask 9y agoI suppose pretty much everyone here already knows, but when making this specific type of comment ("I'm far more productive in Rust than C"), can you please disclose that you are one of the core people involved in Rust/Servo? It's almost like Chuck Moore coming on HN and saying he finds Forth to be the most productive language. Of course it is, for you. (Nothing against the productivity of Forth or Rust.)
- hawkice 9y agoI'm a relative beginner in both Rust and C and I'd like to say that, as much as the learning curve for Rust could be better, even for a beginner, Rust is light years ahead of C, especially if you've used a more modern language. And using a hash table as an example is actually pretty sharp. Someone used to python might not know how much of a pain any type of container is in C. You could reasonably make the case it's easier to use hash tables in assembly -- the C language does you essentially no favors. Rust is quite amazing, though. Very slick, to the point where I use it and I don't care that much about things running fast or with low memory requirements, I just want something with the syntax and comprehensibility of python/ruby/etc (at least compared to erlang/elixir, which I'd otherwise use -- not having local mutable variables makes things a bit more puzzling for no reason like three times a day) and the sweet tools from haskell, and Rust fits the bill.
- goodplay 9y agoI've personally experience very tangible productivity gains once I got past the (very steep) learning curve. The compiler will catch many errors that other languages consider logic errors; if your source code compiles, it tends to run as expected. As for the disclosure: I'm a normal software programmer, and haven't written a single line of code for rust's compiler and tooling.
- flukus 9y ago> The amount of time I spend writing for loop boilerplate alone is worth the price of admission. This can be solved with a templating system, not a new language.
- dragonwriter 9y agoA templating system is a new language.
- flukus 9y agoAn extremely minimalist one that will transfer to an language, including creating rust boilerplate.
- pcwalton 9y agoObviously, I wasn't implying for loop boilerplate is the only problem with C.
- epage 9y agoWhich languages are your point of comparison? Its a different conversation to have to talk about C, C++, D, Swift, Nim, Crystal, or Julia? Which ergonomic issues are your main concerns? Some things I can think of - Libraries focusing on optimal performance over ergonomics - Lifetimes - Results not being quite as ergonomic as exceptions While it has rough spots now, I'm hopeful for the future. The impression I've had watching Rust's evolution is they want to push the language to its limits, find the weak points, find ways of fixing it, and repeat. They don't want to speculatively throw in features. For example, we started off with try!() and later got .?. Improving the documentation would also improve people's perceptions. I've gone through waves of feeling like Rust's error handling is close enough to the ergonomics of exceptions. When I had surface knowledge, it seemed great. I then started using it and running into problems. I then came across random blog posts and it became easy again. For a further discussion on documentation, see https://www.reddit.com/r/rust/comments/67fb8e/rust_tribal_knowledgecollect/dgpztuj/?st=j20s2uaq&sh=52d71c8b https://www.reddit.com/r/rust/comments/67fb8e/rust_tribal_kn... The next step is creating ergonomic libraries. ezstring is an example of people experimenting with this. ezstring: https://github.com/Storyyeller/easy_strings https://github.com/Storyyeller/easy_strings
- jcranmer 9y ago> It may be safer, but not as "ergonomic" subjectively, which ultimately affects productivity. For my first large project in Rust, I ran into several issues where the type system was complaining that I couldn't take the references of certain variables in certain ways. Most of the time, it was clear to me (eventually) that what I wanted to do was actually unsafe. It takes some time, but a lot of the pain involved with starting out with Rust is realizing that the patterns you've been using all along in C/C++ were fundamentally unsafe from the beginning. The rest of the time, though, what I wanted to do was safe, but I couldn't figure out how to structure the code to get Rust in a position where it could guarantee that safety.
- IshKebab 9y agoI just spent an entire week debugging a timing-dependent stack-smashing bug that Rust would have never allowed. On the other hand, closures in Rust are really awkward. So... maybe.
- saghm 9y agoPersonally, I give closures in Rust to be much less awkward than lambdas in C++. What issues do you have with them?
- IshKebab 9y agoIt's the combination of the lambdas and the borrowing system. You have to move all resources into them and then you can't use them from anywhere else. What I mean is, it's not the closures exactly that are the problem. It's just that closures are one of the times it would be really really convenient if you could have multiple mutable references to something. You end up having to use `Rc<RefCell<>>` as described here: http://gtk-rs.org/tuto/closures#using-non-gtk-rs-object-into-a-gtk-rs-closure http://gtk-rs.org/tuto/closures#using-non-gtk-rs-object-into... This is also mentioned in the Tock PDF: https://sing.stanford.edu/site/publications/levy-plos15-tock.pdf https://sing.stanford.edu/site/publications/levy-plos15-tock... in section 3.2. I'm not really sure how they overcame that in Tock. I guess using RefCell? Anyway it all seems very awkward.
- saghm 9y agoAh, I see. I think my perspective tends to be outside the norm when it comes to things like this, since I learned Rust before learning C++, so the Rust way feels "natural", for lack of a better word. I find myself wishing I could do things the Rust way in C++ far more often than vice-versa.
- steveklabnik 9y agoThey invented some new interior mutability things, if you check the recent Tock discussion on HN via search you should see some things, and a link to Reddit about it.
- outworlder 9y ago> I was interested in learning Rust as a safer alternative to C a few years back Well, there you go. It's an alternative to C. Those tend to get messy (see also, C++).
- kbenson 9y ago> It may be safer, but not as "ergonomic" subjectively Perhaps what we really need for the engineering that really calls for this class of product (a systems language), is not more ergonomics, but an acceptance that some small sacrifice in ergonomics and possibly productivity is a small price to pay to make some real headway in the problem of actually providing correct software? Cutting of entire classes of errors and subsequent exploits is an enormous gain for such a small price. Put another way, every bug you allow through that could have been found with more diligence is really you offloading development time, effort or cost onto your users. That's not to say unlimited time should be spent during development to find bugs, but there is a trade-off happening, and I would hazard that most developers spend less time than they should. In these terms, I think Rust is an amazingly productive language regardless of whether it seems harder to use and makes you feel somewhat less productive.
- w8rbt 9y agoI agree 100%. The Rust syntax is so different from C, C++, Go and Java that it's very difficult for me to use. I love the idea of Rust, but I wish the syntax was more similar to traditional languages. If it were, I think it would be a very easy transition for many of us.
- sanderjd 9y agoI'm curious: what is so different about the syntax? It seems very similar to me.
- majewsky 9y agoI think the thing that puts me off the most is the lifetime specifiers: let foo:'static str = "foo"; Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing. Just like for parentheses; imagine how confusing it would be if ' would have been ( instead. let foo:(static str = "foo";
- kbenson 9y ago> Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing. In fairness, you should never be searching for matching apostrophe. Single quote, maybe. The fact that it's an apostrophe should also trigger that it might have something to do with possession... (or that something was omitted).
- int_19h 9y agoThis particular convention is inherited from the ML family, where it has been very popular for a very long time. For what it's worth, there are many cases even in the natural language where ' is not supposed to have a "closing" counterpart - indeed, the "it's" in this very sentence is one such example. Then you have the use of ' to denote feet and minutes of arc. Now, technically these are all actually different symbols, with their own Unicode codepoints etc - but in practice, people use ' for all of them, and it doesn't seem to be confusing anyone. You could treat the ' in Rust as something along these lines.
- josteink 9y ago> It may be safer, but not as "ergonomic" subjectively, which ultimately affects productivity. Tit for tat. When you gain particular categories of guaranteed correctness there are things you needn't worry about, and that saves you lots of trouble down the road. How much ergonomical pains such a gain is worth is obviously debatable, but I think it's absolutely reasonable to say that trading guaranteed correctness for comfort more often than not is going to be the right thing to do in systems-level programming. And the lower-level you go, more so.
- pornel 9y agoThe language is hard to learn, so it is very tedious in the beginning. But once you "get" it, it's a very productive power tool. It's sort of like SVN vs git. When you start you might wonder how can anybody manage to commit a line of code with it, but once you know it, you can't believe you've lived without rebase. I've been programming in C for 17 years, and in Rust for 2 now. In the first year I had to get help from StackOverflow or IRC for every function I wrote. Now I'm past that, and I'm much much more productive in Rust. I have full control of memory, but no `free()` to write! Strings are easy! Dependencies are easy! I can iterate over BTreeMap with 1 line of code (which inlines to code as efficient as I'd write manually). It's great, once you know it.