40 ms·

Rust 2019 and beyond: limits to some growth

429 points by janvdberg 8y ago

cryptonector 8y ago
> Reputation for overcomplexity, loss of users. Becoming the next C++ or Haskell. I think Rust is already there. It's a concern, but I'm not sure you can or should try too hard to avoid this. What you can do is look to make simplifications as you add complexity. And sometimes innovations can have simplifying effects. For example, the various "effects" libraries for Haskell simplify I/O code compared to not having them.
- gpderetta 8y ago
  There are only two types of languages, those that are too complex and those that aren't yet.
  - tzjmetron 8y ago
    Nonsense. Take the favourite punching bag of many ubercool hipsters - Java. The language is dead simple, and extremely successful.
  - augustk 8y ago
    There is at least one language that evolves in the opposite direction. The philosophy of Oberon is that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
    - pjmlp 8y ago
      And sadly lost its opportunity to Java in the late 90's. So whatever Wirth has done was quite of interesting in terms of language research for the language geeks among us, but hardly with any market relevance.
      - augustk 8y ago
        If you are interested, I can recommend the Oberon compiler OBNC: https://miasap.se/obnc/ https://miasap.se/obnc/
        pjmlp 8y ago
        Thanks for the heads up, I am quite aware of Oberon's ecosystem though. You can check Oberon's history on my website.
    - cryptonector 8y ago
      So we should be using Forth then, got it :)
- wasted_intel 8y ago
  Rust 2018's non-lexical lifetimes are a good example of this.
- jules 8y ago
  It's quite difficult to simplify an existing language, even when adding a feature could theoretically simplify a language. For instance, higher kinded types are simple in principle: it's just removing an arbitrary restriction about what you're allowed to pass to a type constructor. However, when adding them to an existing language it doesn't always work that way. In the limit of removing type system restrictions you end up with dependent types, which are very simple in terms of the number of type system rules that they require, but try adding them to Java and you'll get a monstrously complicated beast.
  - cryptonector 8y ago
    You're not wrong. Rust is a very fluid language though, and now is the time to get these things right for Rust. Java feels like a lost cause.
CJefferson 8y ago
I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of length 3 you still need to use the old style (3) notation. So now there is just one more thing to learn. It is much easier to add "one more thing" to a language than it is to later take it out.
- aaaaaaaaaab 8y ago
  Let’s revisit this when Rust has... - the number of users - the amount of mission-critical legacy code that has to compile - the number of compiler vendors - age ... comparable to C++’s.
  - paulddraper 8y ago
    > ... comparable to C++’s. When? 2018? 1990?
    - pjmlp 8y ago
      In the 1990's we already had a couple of OS vendors shipping C++ compilers on their OS SDKs (Apple, IBM, Microsoft, Be, Symbian). So far that is only true of Redox.
      - noir_lord 8y ago
        To be fair though 1990's C++ written in the recommended way is almost a completely different language to 2018 C++. The change isn't as marked as say perl5 and perl6 but it is still huge. I've no dog in either fight though, I moved to managed languages a long time ago (Object Pascal was the last compiled language I used in anger).
        pjmlp 8y ago
ahartmetz 8y ago
Excellent. These are things designers of other languages should have considered but didn't. Looking at you, C++. I write mostly C++...
- maxxxxx 8y ago
  To be fair, C++ did a lot of research that the Rust designers then could learn from. I hope that C++ will get replaced by something simpler but it's a phenomenal success story.
ben0x539 8y ago
Sure, we can limit the language growth, as soon as we get all the critical features in!
- cesarb 8y ago
  Every feature is a "critical feature" to someone. You have to know when to stop.
  - gdy 8y ago
    That was a sarcastic comment
  - galangalalgol 8y ago
    Async/await isn't stable yet, that seems to be making many commenters here wait to adopt, so at least that should make it in before they lock it down. I'd like the platform independent SIMD but that I can admit is niche and could live in nightly for a long time without harming adoption. They have polls to get a feel for the difference between those two categories and which features fall into them.
    - topspin 8y ago
      Landing async/await will be a watershed. Fast, safe, low resource communications applications implemented in Rust will proliferate.
      - cryptonector 8y ago
        It's absolutely essential. A sine qua non for a serious new language.
      - ajross 8y ago
        Or maybe it's just a fad. There have been far more failed IO paradigms than watersheds... I mean, I like it too, but the point upthread is that you can't just suck in every nice-looking idea or you'll end up like C++.
the_clarence 8y ago
I ran into the Failure crate today. It was hard for me to figure out if it was something official that was going to make its way into the core language or just a third party crate. If the former, should I avoid learning failure patterns that are not using this crate? It sometimes feel like the language is moving too fast for me to learn it.
- epage 8y ago
  `failure` captures common error patterns in Rust and provided a test bed for experimenting on them while working to improve `trait Error`. There is an RFC for pulling some of the trait improvements into the language. After that, I believe they plan to continue to iterate on the design of the failure crate. The general recommendation I make and see from others is that `failure` is far from stable. Feel free to use it in applications but avoid it for libraries.
  - the_duke 8y ago
    That RFC was accepted and merged quite a while ago! https://github.com/rust-lang/rfcs/pull/2504 https://github.com/rust-lang/rfcs/pull/2504
  - zanny 8y ago
    Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. Coinciding with the 2018 edition release I ported one of my libraries to it that was using vanilla std::Error impls for two years and dropped about ~400 LOCs out of 600 lines of error handling. It still does all the exact same stuff, and if you use its generic Error impl it behaves the exact same way as the std trait. If Failure stops getting updated.. fine? It doesn't need changing if it works right now, on the 0.1.3 release, for you. If Rust's error trait changes it breaks all libraries anyway and would only happen in the next edition. Thats probably three years out!
    - epage 8y ago
skybrian 8y ago
As a newcomer to Rust and perhaps having been spoiled by Go's very readable specification, I was surprised that Rust doesn't have a definitive language spec. How do the people working on Rust ensure everyone has a common understanding of the language without one?
- deleted 8y ago
  [deleted]
- steveklabnik 8y ago
  Some stuff is quite nailed down, some stuff is not. In the end, not breaking existing code is the most important thing. These things are always on a spectrum. Just because a spec exists doesn’t mean that it has holes; Go’s spec isn’t formally proven, for example, so you could make a similar claim: how can people know that it all works without a proof? The answer is that it’s all a spectrum. Many languages don’t have anything resembling a spec at all! (We are interested and actively working on such a thing for Rust, but we’re shooting high. It’s gonna take a while.)
  - gameswithgo 8y ago
    I have many times run into issues where a written down language spec would have been a big help. The are very useful features in the language that aren't mentioned anywhere in The Book, discovering them requires hoping someone on twitter mentions it, which is crazy. I would love to see a feature freeze and focus on writing down a spec and speeding up the compiler.
    - steveklabnik 8y ago
      Absolutely! We’re working on it for a reason. The only thing not mentioned in the book should be HRTB. Did you run into something else?
      - lambda 8y ago
        Conditional compilation? There's still just a placeholder referring to the first version of the book or the reference. https://doc.rust-lang.org/book/conditional-compilation.html https://doc.rust-lang.org/book/conditional-compilation.html pub(crate) doesn't seem to be mentioned in https://doc.rust-lang.org/book/ch07-02-modules-and-use-to-control-scope-and-privacy.html https://doc.rust-lang.org/book/ch07-02-modules-and-use-to-co.... Some things that are covered are a bit hard to find. For example, I didn't know if operator overloading was covered; it turns out, it's mentioned in https://doc.rust-lang.org/book/ch19-03-advanced-traits.html https://doc.rust-lang.org/book/ch19-03-advanced-traits.html, but it's not in the outline and there's no table of contents on that page, and it's only actually mentioned as an example of how default generic type parameters work. The topic it is covered well by the `std::ops` docs (https://doc.rust-lang.org/std/ops/index.html https://doc.rust-lang.org/std/ops/index.html), but since it's a language feature as well as a library feature, I'd expect it to be covered by the book as well. Raw string literals are only covered very briefly in the appendix: https://doc.rust-lang.org/book/appendix-02-operators.html https://doc.rust-lang.org/book/appendix-02-operators.html #[path = "path/to/file.rs"] doesn't seem to be mentioned; there are probably a bunch of other obscure attributes like this that aren't mentioned. repr? I didn't find any mention of #[repr(C)], #[repr(packed)], #[repr(align)] etc. I also didn't find union. simd? Seems to only really be covered by the 2018 edition guide. Googling "rust simd" turns up references to the old, unstable std::simd. The first two examples are a couple of things I've recently looked for and couldn't find; the others are ones that I noticed browsing around just now looking for other things that might have been missed. Now, some of these are documented in the reference, in the nomicon, in the 2018 edition guide, or in the standard library docs. But that's one of the problems; that there's no one, or even two or three, places you can go to find everything you need. The reference has large warnings at the top about being incomplete, although it's actually not as incomplete as I remember, it might be a good idea to remove the scary warning from it, or to do an audit of it and only put the warning on the sections that are found to be incomplete (like the memory model, which is clearly incomplete as it hasn't actually been formalized yet), but take it off of the sections that actually are up to date. And Google doesn't always help. It still sometimes gives me first edition book links at the top. When I was trying to look up all of the `#[cfg(target_...)]` forms I could use, I tried to search for "rust cfg target", https://www.google.com/search?q=rust+cfg+target https://www.google.com/search?q=rust+cfg+target, but that gives me Rust By Example, a first edition link, and a link to a placeholder that refers to both the first edition and the reference. It took a lot of clicking through to actually find the reference page on it.
rossdavidh 8y ago
I think that, in not only languages but anything related to code (frameworks, packages, etc.), there is a tendency for things to overshoot because that is likely to make those who know the most, more powerful (they know how to use all the features), and its negative impact is on new learners, i.e. those who have little or no voice in these decisions (for obvious and often good reasons). Thus, it becomes a form of pulling up the ladder after you. Not that this phenomenon is in any way limited to coding, of course.
- dccoolgai 8y ago
  As a longtime JS dev, I sometimes cringe for this reason when I see new features in ES. Even though I'm excited about them, when I think about experiencing them as a learner I feel intimidated. One good point the article makes that I wish more language designers accounted for is the fact that in a shared language you can't just pick and choose - to reach a level of expertise you basically have to know all of it.
  - Groxx 8y ago
    JS especially has been a rocket-ship of new language features lately. It used to be my go-to language for new people since it was so simple (when used with a few boundaries (like every language needs)) that it could be picked up and the basics understood fairly quickly, and you can set people free to look at other people's code, and gradually learn DOM APIs and whatnot as needed. Not any more. Not even close. The amount of stuff you have to deal with immediately is far larger now. I actually miss the days when people added this kind of stuff to their transpiler of choice (e.g. coffeescript) and just used that - it doesn't need to be in the language, because it can never be removed from the language. Let fads appear and die outside that barrier, not inside.
    - dccoolgai 8y ago
      Case in point the "how to deal with asynchronous stuff" problem. Callback pyramids weren't great, but the pastiche of approaches that followed (promises, generators, async functions, etc.) Is starting to feel worse.
Ericson2314 8y ago
The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this: GHC Haskell and Rust with have an intermediate language (Core and MIR + Chalk, respectively), which keep the rest of the language in tight check. No other mainstream language has this (Java bytecode doesn't really speak to high level safety properties). This ensures the vast majority of the languages are forgettable sugar, and making consistencies of various sorts tractable. I would argue that even outside of languages as we conventionally think of them, the lack of separating functionality into core languages/interfaces and sugar is the central failure in letting complexity spiral out of control. And indeed, just about everything has.
- Ericson2314 8y ago
  Also the Dependent Haskell work of Richard Eisenberg I'd argue is more important as an attempt to shrink the language than add expressive power. The main thing it does is combine existing language features, which only yields more constructs insofar as the old features had friction. You can think of it roughly as taking the convex hull (or probably better bounding parallelepiped) of the existing feature space. Seen in this light, I've never such a thing attempted at this scale (GHC's size and GHC/Haskell's age), and very much commend it. Hope other things can do the same thing someday.
- kccqzy 8y ago
  I agree with you, but complexity is perceived by newcomers through the surface syntax of the language, not through an internal, mostly invisible IR. It's great that as advanced users, most of the perceived complexity can simply be thought of as sugar, but to a newcomer without an understanding of the core of the language yet, the complexity is often intimidating. It's easy for a language designer to say things are just "forgettable sugar" whereas in the eyes of the users, they are anything but forgettable.
  - Ericson2314 8y ago
    For starters, I think newcomers should look at the core languages more. It's a great way to develop a (shared) mental model, rather than do so independently, reinventing the wheel and then maybe finding that yours disagrees with others'. But even discounting that, I think it's still meaningful. Sugar is easier to deprecate; The desugaring can be used to remove deprecated sugar in the wild too. Core language complexity is a lot harder to eradicate.
zanny 8y ago
Since when did you need to read, comprehend, and digest every language feature in Rust to ever use the language? The absence of HKT / GATs / overloading / default arguments from the language doesn't make it easier for a newbie to learn. These aren't topics someone new, or even intermediate, should ever be touching until they need them. And in the absence of having this functionality (example - we JUST got const fn this month in stable) you have to work around the weaknesses of the language in often obtuse and cumbersome ways... such as hacking the macro system with lazy_static. I think a lot of this sentiment comes back to what makes a language hard. I recently started learning CSS properly for once, now that Grid is in and I can just do all my styling by hand again in the same way I can use ES6 instead of JS frameworks. I needed Bootstrap and JQuery back in the day because despite the simplicity of the fundamental languages there were things I wanted to do that I could not do in an intuitive way. So other people wrote thousands of lines of code to make what should have been simple and accessible but the languages weren't expressive enough. On the inverse, you need some degree of intuitiveness to your design. If I didn't read about the syntax of [<name>] col [<name>] col in CSS Grid I would have never intuitively thought you could name Grid regions. The syntax is completely arcane and arbitrary, isn't based on anything else common to CSS, and just happens to be. That is the source of real complexity in a programming language, not how long the book is or how many pages long the standard library is. Nothing worth learning or doing is so simple as to be digested in a weekend and trying to make a programming language like that, especially a systems one - one that has to expose all the jank complexities of how computers actually work - would have you make a really pretty paper weight nobody could use to get real work done. The complexity in C++ is not in how big the template library is, or how many glyphs the syntax uses, but in how much mental stress it is to see void* = 0 or new Foo and have to juggle all the edge cases and eccentricities of the grammar and model on every single line. Its a massive weight on ones shoulders and that is what will drive a newbie away, at least a newbie with the mindset to take advantage of what they learn. Not the length of your book, so long as all those chapters are about things people want, need, and that are beneficial to the user, rather than warning them about all the ways they can break everything with a single character or how arbitrary decisions were made incongruent with the rest of the language because thats just the way it is. C++ and C are not complex for their expressiveness, they are complex for their arbitrariness and lack of consistency. Same way Javascript and CSS are complex. Same way an actual, legitimate newbie to Rust is going to have much more difficulty processing why :: is the namespace delimiter or why you need curly braces to deliniate scope than how having the option to declare your function const would. Until they need const functions they don't need to touch them and can write all the non-const Rust they want. But now they have const when they need it and can often never touch something crazy like lazy_static again.
fpoling 8y ago
Have other languages or libraries anything like the proposed anti-feature RFC that bans adding features in a particular direction? Go with its ban on generics that they hold for 10 years comes to mind. Anything else?
- MBlume 8y ago
  Not exactly the same thing, but PEP-404 made a negative commitment. [https://www.python.org/dev/peps/pep-0404/ https://www.python.org/dev/peps/pep-0404/]
- dullgiulio 8y ago
  Go never banned generics, it just set a very high bar of integration with the rest of the language. The idea is that Go is one language with a very specific personality: if it changes that much it just becomes another language and can as well be called something else.
Animats 8y ago
It's interesting to see this critique of the Rust language's development process. There's a lot of process. Most of it aimed at adding new features. That may be part of the problem. The Go crowd seemed to know when to stop. I've criticized Rust's growth here before. The big breakthrough in Rust was the borrow checker. Finally, one could have memory safety without garbage collection or reference counting. Huge improvement. "Unsafe" opened too big a hole. I was looking forward to seeing more work on eliminating almost all need for "unsafe". Backpointer support. A way to talk about partially initialized objects. More static analysis. But that didn't happen. Instead, feature after feature was piled on, like C++. Individually, the features aren't bad, but cumulatively, Rust is now a very big language. Meanwhile, C++ has been trying to retrofit Rust ownership semantics using templates. There's too much "be very careful" associated with that.
- dbaupp 8y ago
  All of those unsafe "hole fixes" are features, meaning your desires are for adding even more features. Additionally, useful back pointer support (i.e. for anything more than a toy doubly linked list) is probably a bigger feature than anything else added since Rust 1.0, and probably harder to work with.
  - steveklabnik 8y ago
    ... and basically an open research question, whereas the features we're talking about adding are generally less novel.
- kccqzy 8y ago
  The C++ lifetime proposal doesn't seem have to a lot to do with templates. https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs... Are you talking about something else?
jacquesm 8y ago
That is a super mature post whose content should be read by any language and/or eco-system component (libraries, frameworks and so on) creators and maintainers. I love the intentionally limited scope and the amount of thought that went into writing this, and I wished I had the clarity required to be able to do this. Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. And there already is one example from a company whose founder I knew that made serious bank on just knowing what they were not, so this advice has applicability far outside of computer programming language design. Thanks for posting this.
- munificent 8y ago
  > Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. One of the most profoundly useful things I've ever realized in my life is that the most important choices are often about deciding what not to do. Creativity is deeply wedded to the idea of constraints and pragmatically, there are only so many hours in the day. Deliberately deciding to not investing in one thing is the clearest way I know to free up mental capacity for the things I do want to put care into.
  - mehrdadn 8y ago
    I see the value of deciding what not to do for version(s) X of something, but ruling something out for all eternity seems a little... short-sighted? Who's to say that what you're ruling out won't become the next big concern for everyone and your technology won't be the odd one out without it?
    - usrusr 8y ago
      There are two possible ways to deal with that situation: create something new that is the old thing plus the feature that had been ruled out for it, or simply revoke that decision. Eternity can be surprisingly short when everybody agrees that it is time to move on. Both ways are perfectly possible, and both would in many cases be much preferable to having an implicit "is it time yet for X?" on the agenda every time the version number is incremented. "Not in the foreseeable future" is effectively understood as a far out roadmap item, no matter how much you don't mean it that way. I'd rather see a humble "we thought that we would never X, but we were wrong" repeated for many different X than a single misleading "we absolutely commit to not be adding GOTO before 2025".
sudeepj 8y ago
I have written non-trivial code in Go and Rust. My situation is C++ dev -> Go -> Rust -> Go (current day job). The shifts have been due to various circumstances on my day job. The thing is when I moved back from Rust to Go, I had forgotten how productive Go is and I felt something like this: https://youtu.be/1i_Eqj7wu88?t=50 https://youtu.be/1i_Eqj7wu88?t=50 (20-30 sec video) As someone who tried to "sell" rust in my org, I see the biggest issue is: 1. Steep learning curve (it is true) 2. When lot of people talk about #1 it gets amplified in the minds of people who make calls on the tech to be used A great effort has been spent on #1 and I agree the payoff is worth it. But #2 is perception/marketing issue. PS: I am huge fan of both Rust & Go.
- the_clarence 8y ago
  Big fan of Rust as well, but this is why both Go and Rust are going to co-live. They are both amazing languages.
  - akavel 8y ago
    Personally, in my heart, I'm kinda keeping fingers crossed for a future where if one needs to/has to, one uses Rust (mostly where one would use C/C++ today, including for "squeezing the last drop of performance", and especially high risk everpresent libraries like libpng; plus as an extra, probably for highly ambitious parallelism like in Servo); otherwise, one just goes with Go (for the amazing general productivity and readability). Though then there's also Luna-lang, which I'm hoping even stronger to become long-term a new breakthrough paradigm/tech in programming & scripting... On a mostly unrelated note, but continuing with off the sofa predictions, I'm curious on a few more developments: - whether WebAsm will become the new de-facto universal architecture — at least for VMs, but I wonder if we won't eventually end up living on purely WebAsm CPUs at some point in future? (Unless WebAsm has some inherently hardware-hostile design decisions; I'm not a CPU/ISA guy to know that.) - then RISC-V; will it become the ultimate personal computer/device CPU in the meanwhile? Also, what may happen if both RISC-V and WebAsm start naturally competing in this domain eventually? - Fuchsia off-handedly dethroning the Linux kernel & ecosystem (and maybe even Windows) as the sudden standard mainstream OS (and thus also, amusingly, suddenly swinging the Tannenbaum's argument up through a semi-random caprice of Google's deep pockets)? Especially per the last point, I wonder if we'll eventually end up in a world with much more... "secure"... personal devices. And if yes, will it end up being net good or bad (or just neutral/hard to say/nuanced, a.k.a. both, as usually) for humanity. Given that I'm recently realizing that "secure" unfortunately seems to be a very close sibling, or even maybe just an other face of, "closed" — think DRM, walled-garden ecosystems, no more rooted Android or XBOX... or even no more control at all over your PC, a.k.a. no general computing for the masses, potentially. Though I personally stay mostly hopeful on this front; in part because I think I believe people are as a sum too chaotic for this to be able to happen completely.
fhrow4484 8y ago
The Rust documentation is a bit outdated: https://www.google.com/search?q=rust+tour https://www.google.com/search?q=rust+tour the 1st result is "A 30-minute Introduction to Rust". Going through it requires 4 navigations from the user to get to a valid page, everything in between is deprecated
- steveklabnik 8y ago
  Interesting! That page has been deprecated for something like four years... thanks for pointing this out. I've seen people mention other pages before, but never this one.
  - laszlokorte 8y ago
    It's also confusing that there are: 1. A first edition that is marked as outdated [1] 2. A second editions that seems to be not outdated [2] but 3. also the book without any edition marker that differs from the second edition [3] 4. As well as the second edition for various rust versions (eg [4] or [5]) And all of them are only distinguishable via the url. I guess the book without any version or edition marker [3] is the nightly version? But I am not sure. I guess the second-edition does not differ much between the rust versions as the chapters look the same, except for bug fixes? I am not sure. As a beginner learning rust that is really confusing because I am never sure if I am reading the correct book or if there is some other version with more information. Eg why differs [6] so much from [7] when both are the "second edition"? Ok, while writing this comment I now see that [2] are only empty pages linking to [8] and that all that books and documentation are generated for each rust version. But my point still stands: When coming from the google search result page to the rust documentation there is some confusion of what I am looking at. [1]: https://doc.rust-lang.org/book/first-edition/index.html https://doc.rust-lang.org/book/first-edition/index.html [2]: https://doc.rust-lang.org/book/second-edition/index.html https://doc.rust-lang.org/book/second-edition/index.html [3]: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ [4]: https://doc.rust-lang.org/1.28.0/book/second-edition/foreword.html https://doc.rust-lang.org/1.28.0/book/second-edition/forewor... [5]: https://doc.rust-lang.org/1.29.0/book/second-edition/foreword.html https://doc.rust-lang.org/1.29.0/book/second-edition/forewor... [6]: https://doc.rust-lang.org/book/second-edition/appendix-04-macros.html https://doc.rust-lang.org/book/second-edition/appendix-04-ma... [7]: https://doc.rust-lang.org/1.30.0/book/second-edition/appendix-04-macros.html https://doc.rust-lang.org/1.30.0/book/second-edition/appendi... [8]: https://doc.rust-lang.org/1.30.0/book/second-edition/ https://doc.rust-lang.org/1.30.0/book/second-edition/
Santosh83 8y ago
Rust can force a programmer to be disciplined and that's good as far as it goes, but sadly no current language can force (or even encourage) a programmer to think critically at an architectural level. Indisciplined coding leads to security issues (at least immediately), but a poor architecture can mean a complete failure of the project to meet its goals, never mind exceeding them.
- steveklabnik 8y ago
  One claim about Rust that's increasingly common is that its language constraints do require you to reconsider architecture. See https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html for example.
dmos62 8y ago
I'd read the other two latest posts on this blog for context: The Planning System: hhttps://graydon2.dreamwidth.org/262512.html https://graydon2.dreamwidth.org/262512.html More Galbraith: https://graydon2.dreamwidth.org/262669.html https://graydon2.dreamwidth.org/262669.html
Zelmor 8y ago
>Magnifying inequality: only the most-privileged, available, energetic, well-paid or otherwise well-situated participants can keep up. >privilege this privilege that Shit like this is why I will never touch this language.
MichaelMoser123 8y ago
any shop that is considering Rust would need to consider the question of how to hire or train a sufficient number of programmers. With any mainstream language you have a big pool of programmers up for hire, my guess is that this is more of a problem with a new languages like Rust. Maybe that's the reason why they did hype Java to such an extent when it was a new platform, i think SUN understood that it is quite difficult to gain acceptance as a mainstream player in this game.

429 points by janvdberg 8y ago

> Reputation for overcomplexity, loss of users. Becoming the next C++ or Haskell. I think Rust is already there. It's a concern, but I'm not sure you can or should try too hard to avoid this. What you can do is look to make simplifications as you add complexity. And sometimes innovations can have simplifying effects. For example, the various "effects" libraries for Haskell simplify I/O code compared to not having them.

gpderetta 8y ago
There are only two types of languages, those that are too complex and those that aren't yet.
- tzjmetron 8y ago
  Nonsense. Take the favourite punching bag of many ubercool hipsters - Java. The language is dead simple, and extremely successful.
- augustk 8y ago
  There is at least one language that evolves in the opposite direction. The philosophy of Oberon is that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
  - pjmlp 8y ago
    And sadly lost its opportunity to Java in the late 90's. So whatever Wirth has done was quite of interesting in terms of language research for the language geeks among us, but hardly with any market relevance.
    - augustk 8y ago
      If you are interested, I can recommend the Oberon compiler OBNC: https://miasap.se/obnc/ https://miasap.se/obnc/
      - pjmlp 8y ago
        Thanks for the heads up, I am quite aware of Oberon's ecosystem though. You can check Oberon's history on my website.
  - cryptonector 8y ago
    So we should be using Forth then, got it :)
wasted_intel 8y ago
Rust 2018's non-lexical lifetimes are a good example of this.
jules 8y ago
It's quite difficult to simplify an existing language, even when adding a feature could theoretically simplify a language. For instance, higher kinded types are simple in principle: it's just removing an arbitrary restriction about what you're allowed to pass to a type constructor. However, when adding them to an existing language it doesn't always work that way. In the limit of removing type system restrictions you end up with dependent types, which are very simple in terms of the number of type system rules that they require, but try adding them to Java and you'll get a monstrously complicated beast.
- cryptonector 8y ago
  You're not wrong. Rust is a very fluid language though, and now is the time to get these things right for Rust. Java feels like a lost cause.

CJefferson 8y ago

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of length 3 you still need to use the old style (3) notation. So now there is just one more thing to learn. It is much easier to add "one more thing" to a language than it is to later take it out.

aaaaaaaaaab 8y ago
Let’s revisit this when Rust has... - the number of users - the amount of mission-critical legacy code that has to compile - the number of compiler vendors - age ... comparable to C++’s.
- paulddraper 8y ago
  > ... comparable to C++’s. When? 2018? 1990?
  - pjmlp 8y ago
    In the 1990's we already had a couple of OS vendors shipping C++ compilers on their OS SDKs (Apple, IBM, Microsoft, Be, Symbian). So far that is only true of Redox.
    - noir_lord 8y ago
      To be fair though 1990's C++ written in the recommended way is almost a completely different language to 2018 C++. The change isn't as marked as say perl5 and perl6 but it is still huge. I've no dog in either fight though, I moved to managed languages a long time ago (Object Pascal was the last compiled language I used in anger).
      - pjmlp 8y ago

ahartmetz 8y ago

Excellent. These are things designers of other languages should have considered but didn't. Looking at you, C++. I write mostly C++...

maxxxxx 8y ago
To be fair, C++ did a lot of research that the Rust designers then could learn from. I hope that C++ will get replaced by something simpler but it's a phenomenal success story.

ben0x539 8y ago

Sure, we can limit the language growth, as soon as we get all the critical features in!

cesarb 8y ago
Every feature is a "critical feature" to someone. You have to know when to stop.
- gdy 8y ago
  That was a sarcastic comment
- galangalalgol 8y ago
  Async/await isn't stable yet, that seems to be making many commenters here wait to adopt, so at least that should make it in before they lock it down. I'd like the platform independent SIMD but that I can admit is niche and could live in nightly for a long time without harming adoption. They have polls to get a feel for the difference between those two categories and which features fall into them.
  - topspin 8y ago
    Landing async/await will be a watershed. Fast, safe, low resource communications applications implemented in Rust will proliferate.
    - cryptonector 8y ago
      It's absolutely essential. A sine qua non for a serious new language.
    - ajross 8y ago
      Or maybe it's just a fad. There have been far more failed IO paradigms than watersheds... I mean, I like it too, but the point upthread is that you can't just suck in every nice-looking idea or you'll end up like C++.

the_clarence 8y ago

I ran into the Failure crate today. It was hard for me to figure out if it was something official that was going to make its way into the core language or just a third party crate. If the former, should I avoid learning failure patterns that are not using this crate? It sometimes feel like the language is moving too fast for me to learn it.

epage 8y ago
`failure` captures common error patterns in Rust and provided a test bed for experimenting on them while working to improve `trait Error`. There is an RFC for pulling some of the trait improvements into the language. After that, I believe they plan to continue to iterate on the design of the failure crate. The general recommendation I make and see from others is that `failure` is far from stable. Feel free to use it in applications but avoid it for libraries.
- the_duke 8y ago
  That RFC was accepted and merged quite a while ago! https://github.com/rust-lang/rfcs/pull/2504 https://github.com/rust-lang/rfcs/pull/2504
- zanny 8y ago
  Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. Coinciding with the 2018 edition release I ported one of my libraries to it that was using vanilla std::Error impls for two years and dropped about ~400 LOCs out of 600 lines of error handling. It still does all the exact same stuff, and if you use its generic Error impl it behaves the exact same way as the std trait. If Failure stops getting updated.. fine? It doesn't need changing if it works right now, on the 0.1.3 release, for you. If Rust's error trait changes it breaks all libraries anyway and would only happen in the next edition. Thats probably three years out!
  - epage 8y ago

skybrian 8y ago

As a newcomer to Rust and perhaps having been spoiled by Go's very readable specification, I was surprised that Rust doesn't have a definitive language spec. How do the people working on Rust ensure everyone has a common understanding of the language without one?

deleted 8y ago
[deleted]
steveklabnik 8y ago
Some stuff is quite nailed down, some stuff is not. In the end, not breaking existing code is the most important thing. These things are always on a spectrum. Just because a spec exists doesn’t mean that it has holes; Go’s spec isn’t formally proven, for example, so you could make a similar claim: how can people know that it all works without a proof? The answer is that it’s all a spectrum. Many languages don’t have anything resembling a spec at all! (We are interested and actively working on such a thing for Rust, but we’re shooting high. It’s gonna take a while.)
- gameswithgo 8y ago
  I have many times run into issues where a written down language spec would have been a big help. The are very useful features in the language that aren't mentioned anywhere in The Book, discovering them requires hoping someone on twitter mentions it, which is crazy. I would love to see a feature freeze and focus on writing down a spec and speeding up the compiler.
  - steveklabnik 8y ago
    Absolutely! We’re working on it for a reason. The only thing not mentioned in the book should be HRTB. Did you run into something else?
    - lambda 8y ago
      Conditional compilation? There's still just a placeholder referring to the first version of the book or the reference. https://doc.rust-lang.org/book/conditional-compilation.html https://doc.rust-lang.org/book/conditional-compilation.html pub(crate) doesn't seem to be mentioned in https://doc.rust-lang.org/book/ch07-02-modules-and-use-to-control-scope-and-privacy.html https://doc.rust-lang.org/book/ch07-02-modules-and-use-to-co.... Some things that are covered are a bit hard to find. For example, I didn't know if operator overloading was covered; it turns out, it's mentioned in https://doc.rust-lang.org/book/ch19-03-advanced-traits.html https://doc.rust-lang.org/book/ch19-03-advanced-traits.html, but it's not in the outline and there's no table of contents on that page, and it's only actually mentioned as an example of how default generic type parameters work. The topic it is covered well by the `std::ops` docs (https://doc.rust-lang.org/std/ops/index.html https://doc.rust-lang.org/std/ops/index.html), but since it's a language feature as well as a library feature, I'd expect it to be covered by the book as well. Raw string literals are only covered very briefly in the appendix: https://doc.rust-lang.org/book/appendix-02-operators.html https://doc.rust-lang.org/book/appendix-02-operators.html #[path = "path/to/file.rs"] doesn't seem to be mentioned; there are probably a bunch of other obscure attributes like this that aren't mentioned. repr? I didn't find any mention of #[repr(C)], #[repr(packed)], #[repr(align)] etc. I also didn't find union. simd? Seems to only really be covered by the 2018 edition guide. Googling "rust simd" turns up references to the old, unstable std::simd. The first two examples are a couple of things I've recently looked for and couldn't find; the others are ones that I noticed browsing around just now looking for other things that might have been missed. Now, some of these are documented in the reference, in the nomicon, in the 2018 edition guide, or in the standard library docs. But that's one of the problems; that there's no one, or even two or three, places you can go to find everything you need. The reference has large warnings at the top about being incomplete, although it's actually not as incomplete as I remember, it might be a good idea to remove the scary warning from it, or to do an audit of it and only put the warning on the sections that are found to be incomplete (like the memory model, which is clearly incomplete as it hasn't actually been formalized yet), but take it off of the sections that actually are up to date. And Google doesn't always help. It still sometimes gives me first edition book links at the top. When I was trying to look up all of the `#[cfg(target_...)]` forms I could use, I tried to search for "rust cfg target", https://www.google.com/search?q=rust+cfg+target https://www.google.com/search?q=rust+cfg+target, but that gives me Rust By Example, a first edition link, and a link to a placeholder that refers to both the first edition and the reference. It took a lot of clicking through to actually find the reference page on it.

rossdavidh 8y ago

I think that, in not only languages but anything related to code (frameworks, packages, etc.), there is a tendency for things to overshoot because that is likely to make those who know the most, more powerful (they know how to use all the features), and its negative impact is on new learners, i.e. those who have little or no voice in these decisions (for obvious and often good reasons). Thus, it becomes a form of pulling up the ladder after you. Not that this phenomenon is in any way limited to coding, of course.

dccoolgai 8y ago
As a longtime JS dev, I sometimes cringe for this reason when I see new features in ES. Even though I'm excited about them, when I think about experiencing them as a learner I feel intimidated. One good point the article makes that I wish more language designers accounted for is the fact that in a shared language you can't just pick and choose - to reach a level of expertise you basically have to know all of it.
- Groxx 8y ago
  JS especially has been a rocket-ship of new language features lately. It used to be my go-to language for new people since it was so simple (when used with a few boundaries (like every language needs)) that it could be picked up and the basics understood fairly quickly, and you can set people free to look at other people's code, and gradually learn DOM APIs and whatnot as needed. Not any more. Not even close. The amount of stuff you have to deal with immediately is far larger now. I actually miss the days when people added this kind of stuff to their transpiler of choice (e.g. coffeescript) and just used that - it doesn't need to be in the language, because it can never be removed from the language. Let fads appear and die outside that barrier, not inside.
  - dccoolgai 8y ago
    Case in point the "how to deal with asynchronous stuff" problem. Callback pyramids weren't great, but the pastiche of approaches that followed (promises, generators, async functions, etc.) Is starting to feel worse.

Ericson2314 8y ago

The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this: GHC Haskell and Rust with have an intermediate language (Core and MIR + Chalk, respectively), which keep the rest of the language in tight check. No other mainstream language has this (Java bytecode doesn't really speak to high level safety properties). This ensures the vast majority of the languages are forgettable sugar, and making consistencies of various sorts tractable. I would argue that even outside of languages as we conventionally think of them, the lack of separating functionality into core languages/interfaces and sugar is the central failure in letting complexity spiral out of control. And indeed, just about everything has.

Ericson2314 8y ago
Also the Dependent Haskell work of Richard Eisenberg I'd argue is more important as an attempt to shrink the language than add expressive power. The main thing it does is combine existing language features, which only yields more constructs insofar as the old features had friction. You can think of it roughly as taking the convex hull (or probably better bounding parallelepiped) of the existing feature space. Seen in this light, I've never such a thing attempted at this scale (GHC's size and GHC/Haskell's age), and very much commend it. Hope other things can do the same thing someday.
kccqzy 8y ago
I agree with you, but complexity is perceived by newcomers through the surface syntax of the language, not through an internal, mostly invisible IR. It's great that as advanced users, most of the perceived complexity can simply be thought of as sugar, but to a newcomer without an understanding of the core of the language yet, the complexity is often intimidating. It's easy for a language designer to say things are just "forgettable sugar" whereas in the eyes of the users, they are anything but forgettable.
- Ericson2314 8y ago
  For starters, I think newcomers should look at the core languages more. It's a great way to develop a (shared) mental model, rather than do so independently, reinventing the wheel and then maybe finding that yours disagrees with others'. But even discounting that, I think it's still meaningful. Sugar is easier to deprecate; The desugaring can be used to remove deprecated sugar in the wild too. Core language complexity is a lot harder to eradicate.

zanny 8y ago

Since when did you need to read, comprehend, and digest every language feature in Rust to ever use the language? The absence of HKT / GATs / overloading / default arguments from the language doesn't make it easier for a newbie to learn. These aren't topics someone new, or even intermediate, should ever be touching until they need them. And in the absence of having this functionality (example - we JUST got const fn this month in stable) you have to work around the weaknesses of the language in often obtuse and cumbersome ways... such as hacking the macro system with lazy_static. I think a lot of this sentiment comes back to what makes a language hard. I recently started learning CSS properly for once, now that Grid is in and I can just do all my styling by hand again in the same way I can use ES6 instead of JS frameworks. I needed Bootstrap and JQuery back in the day because despite the simplicity of the fundamental languages there were things I wanted to do that I could not do in an intuitive way. So other people wrote thousands of lines of code to make what should have been simple and accessible but the languages weren't expressive enough. On the inverse, you need some degree of intuitiveness to your design. If I didn't read about the syntax of [<name>] col [<name>] col in CSS Grid I would have never intuitively thought you could name Grid regions. The syntax is completely arcane and arbitrary, isn't based on anything else common to CSS, and just happens to be. That is the source of real complexity in a programming language, not how long the book is or how many pages long the standard library is. Nothing worth learning or doing is so simple as to be digested in a weekend and trying to make a programming language like that, especially a systems one - one that has to expose all the jank complexities of how computers actually work - would have you make a really pretty paper weight nobody could use to get real work done. The complexity in C++ is not in how big the template library is, or how many glyphs the syntax uses, but in how much mental stress it is to see void* = 0 or new Foo and have to juggle all the edge cases and eccentricities of the grammar and model on every single line. Its a massive weight on ones shoulders and that is what will drive a newbie away, at least a newbie with the mindset to take advantage of what they learn. Not the length of your book, so long as all those chapters are about things people want, need, and that are beneficial to the user, rather than warning them about all the ways they can break everything with a single character or how arbitrary decisions were made incongruent with the rest of the language because thats just the way it is. C++ and C are not complex for their expressiveness, they are complex for their arbitrariness and lack of consistency. Same way Javascript and CSS are complex. Same way an actual, legitimate newbie to Rust is going to have much more difficulty processing why :: is the namespace delimiter or why you need curly braces to deliniate scope than how having the option to declare your function const would. Until they need const functions they don't need to touch them and can write all the non-const Rust they want. But now they have const when they need it and can often never touch something crazy like lazy_static again.

fpoling 8y ago

Have other languages or libraries anything like the proposed anti-feature RFC that bans adding features in a particular direction? Go with its ban on generics that they hold for 10 years comes to mind. Anything else?

MBlume 8y ago
Not exactly the same thing, but PEP-404 made a negative commitment. [https://www.python.org/dev/peps/pep-0404/ https://www.python.org/dev/peps/pep-0404/]
dullgiulio 8y ago
Go never banned generics, it just set a very high bar of integration with the rest of the language. The idea is that Go is one language with a very specific personality: if it changes that much it just becomes another language and can as well be called something else.

Animats 8y ago

It's interesting to see this critique of the Rust language's development process. There's a lot of process. Most of it aimed at adding new features. That may be part of the problem. The Go crowd seemed to know when to stop. I've criticized Rust's growth here before. The big breakthrough in Rust was the borrow checker. Finally, one could have memory safety without garbage collection or reference counting. Huge improvement. "Unsafe" opened too big a hole. I was looking forward to seeing more work on eliminating almost all need for "unsafe". Backpointer support. A way to talk about partially initialized objects. More static analysis. But that didn't happen. Instead, feature after feature was piled on, like C++. Individually, the features aren't bad, but cumulatively, Rust is now a very big language. Meanwhile, C++ has been trying to retrofit Rust ownership semantics using templates. There's too much "be very careful" associated with that.

dbaupp 8y ago
All of those unsafe "hole fixes" are features, meaning your desires are for adding even more features. Additionally, useful back pointer support (i.e. for anything more than a toy doubly linked list) is probably a bigger feature than anything else added since Rust 1.0, and probably harder to work with.
- steveklabnik 8y ago
  ... and basically an open research question, whereas the features we're talking about adding are generally less novel.
kccqzy 8y ago
The C++ lifetime proposal doesn't seem have to a lot to do with templates. https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs... Are you talking about something else?

jacquesm 8y ago

That is a super mature post whose content should be read by any language and/or eco-system component (libraries, frameworks and so on) creators and maintainers. I love the intentionally limited scope and the amount of thought that went into writing this, and I wished I had the clarity required to be able to do this. Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. And there already is one example from a company whose founder I knew that made serious bank on just knowing what they were not, so this advice has applicability far outside of computer programming language design. Thanks for posting this.

munificent 8y ago
> Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. One of the most profoundly useful things I've ever realized in my life is that the most important choices are often about deciding what not to do. Creativity is deeply wedded to the idea of constraints and pragmatically, there are only so many hours in the day. Deliberately deciding to not investing in one thing is the clearest way I know to free up mental capacity for the things I do want to put care into.
- mehrdadn 8y ago
  I see the value of deciding what not to do for version(s) X of something, but ruling something out for all eternity seems a little... short-sighted? Who's to say that what you're ruling out won't become the next big concern for everyone and your technology won't be the odd one out without it?
  - usrusr 8y ago
    There are two possible ways to deal with that situation: create something new that is the old thing plus the feature that had been ruled out for it, or simply revoke that decision. Eternity can be surprisingly short when everybody agrees that it is time to move on. Both ways are perfectly possible, and both would in many cases be much preferable to having an implicit "is it time yet for X?" on the agenda every time the version number is incremented. "Not in the foreseeable future" is effectively understood as a far out roadmap item, no matter how much you don't mean it that way. I'd rather see a humble "we thought that we would never X, but we were wrong" repeated for many different X than a single misleading "we absolutely commit to not be adding GOTO before 2025".

sudeepj 8y ago

I have written non-trivial code in Go and Rust. My situation is C++ dev -> Go -> Rust -> Go (current day job). The shifts have been due to various circumstances on my day job. The thing is when I moved back from Rust to Go, I had forgotten how productive Go is and I felt something like this: https://youtu.be/1i_Eqj7wu88?t=50 https://youtu.be/1i_Eqj7wu88?t=50 (20-30 sec video) As someone who tried to "sell" rust in my org, I see the biggest issue is: 1. Steep learning curve (it is true) 2. When lot of people talk about #1 it gets amplified in the minds of people who make calls on the tech to be used A great effort has been spent on #1 and I agree the payoff is worth it. But #2 is perception/marketing issue. PS: I am huge fan of both Rust & Go.

the_clarence 8y ago
Big fan of Rust as well, but this is why both Go and Rust are going to co-live. They are both amazing languages.
- akavel 8y ago
  Personally, in my heart, I'm kinda keeping fingers crossed for a future where if one needs to/has to, one uses Rust (mostly where one would use C/C++ today, including for "squeezing the last drop of performance", and especially high risk everpresent libraries like libpng; plus as an extra, probably for highly ambitious parallelism like in Servo); otherwise, one just goes with Go (for the amazing general productivity and readability). Though then there's also Luna-lang, which I'm hoping even stronger to become long-term a new breakthrough paradigm/tech in programming & scripting... On a mostly unrelated note, but continuing with off the sofa predictions, I'm curious on a few more developments: - whether WebAsm will become the new de-facto universal architecture — at least for VMs, but I wonder if we won't eventually end up living on purely WebAsm CPUs at some point in future? (Unless WebAsm has some inherently hardware-hostile design decisions; I'm not a CPU/ISA guy to know that.) - then RISC-V; will it become the ultimate personal computer/device CPU in the meanwhile? Also, what may happen if both RISC-V and WebAsm start naturally competing in this domain eventually? - Fuchsia off-handedly dethroning the Linux kernel & ecosystem (and maybe even Windows) as the sudden standard mainstream OS (and thus also, amusingly, suddenly swinging the Tannenbaum's argument up through a semi-random caprice of Google's deep pockets)? Especially per the last point, I wonder if we'll eventually end up in a world with much more... "secure"... personal devices. And if yes, will it end up being net good or bad (or just neutral/hard to say/nuanced, a.k.a. both, as usually) for humanity. Given that I'm recently realizing that "secure" unfortunately seems to be a very close sibling, or even maybe just an other face of, "closed" — think DRM, walled-garden ecosystems, no more rooted Android or XBOX... or even no more control at all over your PC, a.k.a. no general computing for the masses, potentially. Though I personally stay mostly hopeful on this front; in part because I think I believe people are as a sum too chaotic for this to be able to happen completely.

fhrow4484 8y ago

The Rust documentation is a bit outdated: https://www.google.com/search?q=rust+tour https://www.google.com/search?q=rust+tour the 1st result is "A 30-minute Introduction to Rust". Going through it requires 4 navigations from the user to get to a valid page, everything in between is deprecated

steveklabnik 8y ago
Interesting! That page has been deprecated for something like four years... thanks for pointing this out. I've seen people mention other pages before, but never this one.
- laszlokorte 8y ago
  It's also confusing that there are: 1. A first edition that is marked as outdated [1] 2. A second editions that seems to be not outdated [2] but 3. also the book without any edition marker that differs from the second edition [3] 4. As well as the second edition for various rust versions (eg [4] or [5]) And all of them are only distinguishable via the url. I guess the book without any version or edition marker [3] is the nightly version? But I am not sure. I guess the second-edition does not differ much between the rust versions as the chapters look the same, except for bug fixes? I am not sure. As a beginner learning rust that is really confusing because I am never sure if I am reading the correct book or if there is some other version with more information. Eg why differs [6] so much from [7] when both are the "second edition"? Ok, while writing this comment I now see that [2] are only empty pages linking to [8] and that all that books and documentation are generated for each rust version. But my point still stands: When coming from the google search result page to the rust documentation there is some confusion of what I am looking at. [1]: https://doc.rust-lang.org/book/first-edition/index.html https://doc.rust-lang.org/book/first-edition/index.html [2]: https://doc.rust-lang.org/book/second-edition/index.html https://doc.rust-lang.org/book/second-edition/index.html [3]: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ [4]: https://doc.rust-lang.org/1.28.0/book/second-edition/foreword.html https://doc.rust-lang.org/1.28.0/book/second-edition/forewor... [5]: https://doc.rust-lang.org/1.29.0/book/second-edition/foreword.html https://doc.rust-lang.org/1.29.0/book/second-edition/forewor... [6]: https://doc.rust-lang.org/book/second-edition/appendix-04-macros.html https://doc.rust-lang.org/book/second-edition/appendix-04-ma... [7]: https://doc.rust-lang.org/1.30.0/book/second-edition/appendix-04-macros.html https://doc.rust-lang.org/1.30.0/book/second-edition/appendi... [8]: https://doc.rust-lang.org/1.30.0/book/second-edition/ https://doc.rust-lang.org/1.30.0/book/second-edition/

Santosh83 8y ago

Rust can force a programmer to be disciplined and that's good as far as it goes, but sadly no current language can force (or even encourage) a programmer to think critically at an architectural level. Indisciplined coding leads to security issues (at least immediately), but a poor architecture can mean a complete failure of the project to meet its goals, never mind exceeding them.

steveklabnik 8y ago
One claim about Rust that's increasingly common is that its language constraints do require you to reconsider architecture. See https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html for example.

dmos62 8y ago

I'd read the other two latest posts on this blog for context: The Planning System: hhttps://graydon2.dreamwidth.org/262512.html https://graydon2.dreamwidth.org/262512.html More Galbraith: https://graydon2.dreamwidth.org/262669.html https://graydon2.dreamwidth.org/262669.html

Zelmor 8y ago

>Magnifying inequality: only the most-privileged, available, energetic, well-paid or otherwise well-situated participants can keep up. >privilege this privilege that Shit like this is why I will never touch this language.

MichaelMoser123 8y ago

any shop that is considering Rust would need to consider the question of how to hire or train a sufficient number of programmers. With any mainstream language you have a big pool of programmers up for hire, my guess is that this is more of a problem with a new languages like Rust. Maybe that's the reason why they did hype Java to such an extent when it was a new platform, i think SUN understood that it is quite difficult to gain acceptance as a mainstream player in this game.