11 ms·

> Rust on the other hand is optimized for maintaining (it's right there in the name: software should be allowed to become old and "collect rust"). Rust APIs are

> Rust on the other hand is optimized for maintaining (it's right there in the name: software should be allowed to become old and "collect rust"). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can't do - you even know whether it's allowed to mutate an object you're passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }. A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. You could maybe make the argument that the guarantees provided by the language and compiler reduce the maintenance burden of software built in Rust, but I don't even really think that statement has been tested (via Rust being so young). It is tiresome the frequency that legitimate language discussions for some reason turn into Rust vs. Go trash talking. It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly. There will be legacy apps that people hate working with in all programming languages, and there's nothing that can save you.

sanderjd 5y ago
> It is almost certain that in 10 years, both will be used more than they are now by several x's. That's why so many threads end up being about Rust vs. Go. They are the new(ish) languages that appear most likely to be real factors in the industry for a very long time, so they bear more discussion. I wasn't really around for it, but I'm sure there were lots of discussions about Java vs. C++ earlier in their lifespans, for this same reason.
- ehvatum 5y ago
  > I'm sure there were lots of discussions about Java vs. C++ earlier in their lifespans Rewind to 1996. I’m at the Networld/Interop conference in Las Vegas. The steel skeleton of the Ballagio looms over desert mirages, and Java is all things to all people: a wide-open utopia to be populated by new and perfect code, a new world without concern for memory management, an abstraction from everything freeing us all from needing to know anything.
kazoomonger 5y ago
I doubt Go will be used in the future more by several times than it is now. Looking at Google Trends, we're past peak Go, it's now on the decline: https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F09gbxjr https://trends.google.com/trends/explore?date=all&geo=US&q=%... I haven't seen anything that would indicate anything else than Go slowly declining much like Ruby has. In other words, it's still around and getting new updates, but losing mindshare.
- dpatterbee 5y ago
  On the other hand, searches for "golang" matched their all-time high in July 2020.
  - kazoomonger 5y ago
    Not sure what you mean. This chart shows the peak as being in 2019, and declining since then: https://trends.google.com/trends/explore?date=all&geo=US&q=golang https://trends.google.com/trends/explore?date=all&geo=US&q=g...
    - fwip 5y ago
      You're looking at US, the Worldwide view matches July 2020.
- nr0mx 5y ago
  By that metric, doesn't Rust have an even bleaker future? https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F09gbxjr,%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?date=today%205-y&q=...
  - kazoomonger 5y ago
    My response was more doubting that Go is going to be used many times more than it is currently 10 years down the line, but the trend on Rust is upwards: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... That doesn't mean it will ever achieve popularity, and could also go away. However, with the Go developers' insistence on changing the language as little as possible (not good or bad, it just is), it seems unlikely that Go will see a resurgence that brings it to multiple times usage than it has now.
brundolf 5y ago
My intention wasn't to trash-talk, and I admitted my bias up front. I'm just speculating, and I think that speculation is legitimate and relevant to the subject at hand. It's my belief that whatever difficulty there is around onboarding people into Rust (setting aside the question of exactly how much of a problem that actually is or isn't) is "constant", where the difficulty of onboarding people into a legacy codebase is, shall we say, "polynomial" over time. Rust adds some constant overhead in exchange for reducing that polynomial growth, and my belief is that at some point the larger polynomials outpace it, ending up with more total difficulty for newcomers to a given legacy codebase. Of course time will tell.
- throwaway894345 5y ago
  > constant vs polynomial This is an interesting way to look at it, but I actually think this perspective favors Go considering that there is less variety across Go projects than other ecosystems, including Rust. Of course no programming language can hold constant the business domain, but there are things like which “error handling framework”, “for loops vs iterators”, “sync vs async”, “prefer owned vs borrowed by default”, etc that apply to Rust and not to Go. And of course, Rust lets you build some gnarly abstractions which simply don’t exist in Go. Go gives you less choice, and thus projects are more similar, and thus I suspect legacy Go code adds will be easier to maintain. Of course this property may not endure once Go acquires generics. It should be said that I’m a big fan of both languages, and I am especially enthusiastic about Rust in that it fits my compulsion to have code that is both very abstract and very performant.
  - brundolf 5y ago
    > error handling framework Not sure what's meant by this; Rust has a standardized Result type, with dedicated syntax for early-returning errors and type checks that make sure you handle them (or at least explicitly ignore them). Go, on the other hand, has a shaky error story and from what I've heard it's a constant problem due to enforcement-by-convention. > prefer owned vs borrowed by default Not really sure what this means either... the owner of a value generally falls out naturally from how you're trying to use it. It's not really an either/or option. It needs to live where it will be around long enough for everything that's done with it, and everything other than the owner should get a reference to it. Maybe you're talking about passing by reference vs implementing Copy? If so, that's mostly a performance concern. > Of course this property may not endure once Go acquires generics Yeah- one of the few things I like about Go is that it doesn't have generics (yet). I've seen generics make TypeScript codebases impenetrable, and I think there's a decent case to be made for not having them at all.
aranchelk 5y ago
I use neither Go nor Rust and don’t have an opinion, but it’s worth pointing out that “difficult to learn” is highly contextual, e.g. Python or Ruby were probably relatively easy to learn if you already knew Perl or PHP. I found Haskell quite difficult to learn. Subsequently PureScript was very easy. Widely shared knowledge and concepts change over time and they will affect ease of adoption.
mumblemumble 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. I'm not so sure about that. (Or perhaps the definition itself needs scrutiny?) Most the languages I've seen get a reputation for being easy to learn have also subsequently earned a reputation for being a maintenance hassle: perl, ruby, python, php, javascript, etc.
- deleted 5y ago
  [deleted]
- toxik 5y ago
  Language nitpick in the parent’s comment: “touted” is definitely the wrong word here, to tout is to solicit.
  - perl4ever 5y ago
    "touted" has a positive connotation to me, so it doesn't sound right to tout negative aspects of something. But the meaning seems clear.
  - yesenadam 5y ago
    > “touted” is definitely the wrong word here, Uh, no. In Merriam Webster, that's meaning #2. Meaning #1 is > to make much of : promote, talk up > touted as the summer's blockbuster movie > the college's much touted women's studies program https://www.merriam-webster.com/dictionary/tout https://www.merriam-webster.com/dictionary/tout
    - mumblemumble 5y ago
      Realistically, that first definition is slightly ambiguous; it may or may not mean to imply that the talk is supposed to be promotional and not derisive in order for the definition to apply. I am guessing that they probably did mean to imply that connotation, though, based on other information on the page. I'd argue, though, that the reality is that the word's meaning is in the process of shifting from being a synonym for "promote" to being a synonym for "make out to be"; that reflects much common usage, and dictionaries always lag behind a bit in cases like this. They have to - they're a descriptive artifact, not a prescriptive one.
aidenn0 5y ago
I cannot write a program from scratch in Haskell. I just can't wrap my brain around it. However, every time I've needed a new feature in a program I use written in Haskell, it's been easy and a pleasure to implement.
woah 5y ago
Have you ever maintained a piece of Rust code?
- void_mint 5y ago
  Yep! edit I am amused at this downvote. I was asked a yes or no question, and responded with a yes. What could possibly make this response downvote-worthy?
orwin 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. Disagree. First, difficult to learn is not difficult to onboard. Second, unless you think Ocaml is not hard to learn, i think this is a great counterexample.
zozbot234 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. Rust is not more "difficult to learn" or "difficult to onboard" than C++. And C++ is certainly a language with plenty of legacy, enough that you could reasonably call it "brown". Go is a rather different language that's perhaps best compared with Java as its closest "brown" counterpart.
- void_mint 5y ago
  > Rust is not more "difficult to learn" or "difficult to onboard" than C++. Saying Rust isn't more difficult than possibly the most difficult thing is not a good argument in favor of Rust not being difficult, no? People dread maintaining legacy C++ systems. People dread maintaining legacy systems. Rust will be no different.
  - kevin_thibedeau 5y ago
    The problem with C++ is that the various standards have encouraged changing idioms. Pre-standard, 98, 11, and 17 are significantly different when the new language features are fully leveraged. Legacy code creates inconvenient barriers when interoperating with modern stuff. Rust may be able to escape this problem.
    - resonantjacket5 5y ago
      I mean eventually there's going to be rust 2 etc...
      - steveklabnik 5y ago
        Not from the Rust project; someone else would have to come along and build it.
        resonantjacket5 5y ago
        I mean there will be more and more changes to Rust, just like how C++ has had many changes over the years. Rust 2020, .. 2025, 2026 etc..
solipsism 5y ago
It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly. You contradict yourself.
cbsks 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" Does anyone know if there have been studies about how long it takes to learn different programming languages? I hypothesize that it would take a beginner programmer longer to learn Rust than C, but probably a similar amount of time as learning C++ (which I think is the closest “traditional” programming language to Rust).
Ygg2 5y ago
I can learn any language in a day or two. And become proficient in it in a week. Big part of mastering is less about knowing the language and knowing its plumbing. Quirks, unique behavior, library, tooling, etc. Dynamism is a constant source of pain. Because it makes tooling and thus exploring language harder. In Rust there is little such dynamism. Actual problems understanding are macros and proc macros. And finding the right Trait. Tooling around Rust is standarized. You have cargo, rustc and they bring in the rest. While there is some chance of Rust going nuts and adding some bizzare thing like inheritance, HKT++, the chance that it will reach cognitive complexity of Scala or C++ is lesser.
- Decabytes 5y ago
  I program in Python by day. Racket is probably the language I know best after Python, then maybe Groovy. I've had exposure to R, C, C++, D, Java, Common Lisp etc, and I find it easier to pick up new languages due to my familiarity. While Rust has all the constructs that I'm used to from these other programming languages, I find Rust to be the most difficult one for me to learn in recent memory. The documentation is great, the book is great, the tooling with Cargo is great, but after getting through the first 15 chapters in the Book I struggled to write a program that had any sort of complexity. Sure I can add a dependency super easily to my project, but figuring out what errors everything in the library throws takes a lot of work. Sometimes I get confused about using panic!, expect, unwrap, or ? when I'm writing my own functions or interfacing with others. Swimming through the myriad of traits on different structs is confusing, and I sometimes get tripped up passing closures. And don't get me started on Macros, with great shame, they still have not clicked for me, in Lisp, or in Rust. The language just feels very different from what I'm used to, and I've never had such a hard time getting code I've written to compile correctly. I'd be totally lost without all the help from the subreddit and the book, and I appreciate everyone who has helped me. I know this will get easier... and it has. But it will take longer for me to get comfortably with Rust then it has for other programmings languages in the same time period. This is not to say that it's a bad language. I remember one day after having debugged a Python issue that ended up being a stupid logic error on my part I exclaimed "I wish I knew a programming language that would save me from myself". I think... Or rather I hope Rust is that language in the long term for me
shinjitsu 5y ago
I think the "difficult to learn" and "difficult to onboard" is important to keeping rust a "Most Loved Programming Language". If only those who make it through the "difficult to onboard" phase use the language extensively, then only they will be responding to the "most loved"/"most dreaded" question. I taught a university seminar that looked at rust and another emerging language a couple of years ago and only 2 students out of 30 said they would use rust again after the class. So the rest will never get a chance to answer the survey question about rust.
the__alchemist 5y ago
I wouldn't call Rust difficult to learn. The syntax quirks (Knowing where to put `&` etc takes time, and traits are abstract, but used all over Rust codebases). For example: Look at Python which is typically considered easy to learn. In Rust, I know that I can create a project using official tooling; specify dependencies cleanly in `Cargo.toml`; use the built-in linter, and formatter. Check the Rust docs page for any dependencies, including type signatures for all functions, and a list of struct fields. Look in the `examples` folder of a dependency's repo for code snippets. In Python, I'm likely to find a comparative mess of sparingly-documented documented third-party tools, dependency docs, and Stack Overflow posts. Or, look at embedded, where C is considered a simple language. In C, it's not obvious how I'd start. Use something like Cube-MX or Keil? GCC? All the options are messy and tough to learn. In Rust, I clone a template repo, cargo-install 2 or 3 tools and targets, and `cargo run` to compile and flash.
- petre 5y ago
  C/C++ and Rust are both hard IMHO. D is way easier, one gets productive quite fast and there are also more advanced language features once you get proficient in it, unlike Go.
- valand 5y ago
  > I wouldn't call Rust difficult to learn I agree with this too. This is because you know what Rust brings you compared to what you used in the past that cause you pain. Unfortunately, some people that have difficulty learning Rust (or hear about it) focus solely on the learning process and not what they gain by learning it. Learning a low-level language is inherently hard because there are more at stake, it is simply more complex. For people that work where dangling pointer, data-races, is never a problem, they are learning about the problem the same time they are learning about the solution (Rust's ownership concept), and I came from that place too.
- nec4b 5y ago
  > Or, look at embedded, where C is considered a simple language. In C, it's not obvious how I'd start. Use something like Cube-MX or Keil? GCC? All the options are messy and tough to learn. In Rust, I clone a template repo, cargo-install 2 or 3 tools and targets, and `cargo run` to compile and flash. Keil is a company that builds an IDE, compiler and debuging tools for microcontrollers. CubeMx is a configuration tool/code generator for STM microcontrollers. You comment makes no sense in regards to C language, unless you are saying that rust/cargo automagically does everything that Keil products and CubeMx do?
HWR_14 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. I disagree. The things that make for good maintenance correlate with both difficulty to learn and difficulty to onboard. (The converse is not true.) Things that are easily to learn tend to be easy to start with, but end up tacking on, via frameworks or coding standards, pieces that raise both difficulty to learn and to onboard as complex projects exist. Specifically, maintenance requires thinking like the person or people who initially created the code. The more your thinking aligns with them, the easier it is to maintain. And that act of changing to think like them is learning and onboarding.
derefr 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. I think this presumes that you have to teach people the language. But most maintenance programming is done by hiring people already familiar with the language the existing codebase is written in, and then bringing them on to work on the existing project. Rust isn’t hard to onboard for an individual project, in the same way that a macro-laden Lisp codebase is. Once you know Rust, you know Rust. It takes more effort to “know Rust” because you have to learn all the ecosystem stuff expected of someone who “knows Rust”; but from the perspective of an employer, you can just hire “someone who knows Rust”, and they’ll come with all that knowledge. And, in fact, an experienced Rust dev may be able to start work on a novel-to-them existing Rust project, a lot faster than (for example) an experienced C dev would on a novel-to-them existing C project, as a large stdlib / conventional ecosystem of foundational libraries (as in the case of Rust) tends to translate well to experienced developers coming into a codebase and quickly recalling everything, because it’s a bunch of the same batteries/libraries they’ve already used in the past. The difference between a design pattern and a language feature, is that you can recall language features, while you have to recognize design patterns (i.e. grok the code in order to identify what pattern(s) it’s trying to reify.) Languages with more formalisms (either built into the language, or in common use in the ecosystem) increase the amount of recall that new maintenance programmers can do (or rather, decrease the amount of recognizing they have to do to get up-to-speed), and thus make switching a maintenance programmer between codebases “cheaper.” ————— I bring this up not from the perspective of a Rust programmer, but from the perspective of an Erlang programmer... who also doesn’t like Go very much (though I do write quite a lot of Go! As a maintenance programmer!) IMHO Erlang and Go aren’t all that fundamentally different runtime-wise. Presuming you’re using them for the same thing — writing highly-concurrent, fault-tolerant network servers — the main difference between the experiences of coding in Go and in Erlang, comes down to the fact that Go provides you with a bunch of concurrency primitives that you have to put together as design patterns — and where maintenance programmers then have to recognize those patterns; while Erlang actually has universal concurrency formalisms that everyone takes advantage of, and so those formalisms can simply be recalled on new projects. I advise anyone who thinks that “recognizing design patterns” is a cheap-and-easy thing to do, to tell me what’s going on in this file: https://github.com/ethereum/go-ethereum/blob/master/eth/downloader/statesync.go https://github.com/ethereum/go-ethereum/blob/master/eth/down... . I’ve stared at this code on-and-off for two years, and I still don’t have a mental model for it. If this code was made out of cleanly-separated named/opaque formalisms, rather than fifty design-patterns tied into a knot, I can’t even imagine how much more productive I would have been working on it.
emteycz 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. Strong disagreement here. It could be difficult because it's built for maintaining. People who are unable to understand Rust are the people you don't want anywhere near your C/C++/Rust project.
valand 5y ago
> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining PL learnability alone is not significant as a factor for a PL to be chosen for a certain task, unless it is impossibly hard. Rust, looking at the growing community, is not a PL that is impossibly hard to learn. A PL is chosen for a certain task for its features. The same as any other class of tool, "A is chosen for X because of A's feature". The learning curve is simply the side-effect of the PL's minimum features need to be learnt for it to work. Rust being a low-level language + an extra layer of protection is inherently hard. But let's see how it fares in 10 years. There have been successful projects built on Rust, firecracker, figma, discord, and many more, despite it being so young.

sanderjd 5y ago

> It is almost certain that in 10 years, both will be used more than they are now by several x's. That's why so many threads end up being about Rust vs. Go. They are the new(ish) languages that appear most likely to be real factors in the industry for a very long time, so they bear more discussion. I wasn't really around for it, but I'm sure there were lots of discussions about Java vs. C++ earlier in their lifespans, for this same reason.

ehvatum 5y ago
> I'm sure there were lots of discussions about Java vs. C++ earlier in their lifespans Rewind to 1996. I’m at the Networld/Interop conference in Las Vegas. The steel skeleton of the Ballagio looms over desert mirages, and Java is all things to all people: a wide-open utopia to be populated by new and perfect code, a new world without concern for memory management, an abstraction from everything freeing us all from needing to know anything.

kazoomonger 5y ago

I doubt Go will be used in the future more by several times than it is now. Looking at Google Trends, we're past peak Go, it's now on the decline: https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F09gbxjr https://trends.google.com/trends/explore?date=all&geo=US&q=%... I haven't seen anything that would indicate anything else than Go slowly declining much like Ruby has. In other words, it's still around and getting new updates, but losing mindshare.

dpatterbee 5y ago
On the other hand, searches for "golang" matched their all-time high in July 2020.
- kazoomonger 5y ago
  Not sure what you mean. This chart shows the peak as being in 2019, and declining since then: https://trends.google.com/trends/explore?date=all&geo=US&q=golang https://trends.google.com/trends/explore?date=all&geo=US&q=g...
  - fwip 5y ago
    You're looking at US, the Worldwide view matches July 2020.
nr0mx 5y ago
By that metric, doesn't Rust have an even bleaker future? https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F09gbxjr,%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?date=today%205-y&q=...
- kazoomonger 5y ago
  My response was more doubting that Go is going to be used many times more than it is currently 10 years down the line, but the trend on Rust is upwards: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... That doesn't mean it will ever achieve popularity, and could also go away. However, with the Go developers' insistence on changing the language as little as possible (not good or bad, it just is), it seems unlikely that Go will see a resurgence that brings it to multiple times usage than it has now.

brundolf 5y ago

My intention wasn't to trash-talk, and I admitted my bias up front. I'm just speculating, and I think that speculation is legitimate and relevant to the subject at hand. It's my belief that whatever difficulty there is around onboarding people into Rust (setting aside the question of exactly how much of a problem that actually is or isn't) is "constant", where the difficulty of onboarding people into a legacy codebase is, shall we say, "polynomial" over time. Rust adds some constant overhead in exchange for reducing that polynomial growth, and my belief is that at some point the larger polynomials outpace it, ending up with more total difficulty for newcomers to a given legacy codebase. Of course time will tell.

throwaway894345 5y ago
> constant vs polynomial This is an interesting way to look at it, but I actually think this perspective favors Go considering that there is less variety across Go projects than other ecosystems, including Rust. Of course no programming language can hold constant the business domain, but there are things like which “error handling framework”, “for loops vs iterators”, “sync vs async”, “prefer owned vs borrowed by default”, etc that apply to Rust and not to Go. And of course, Rust lets you build some gnarly abstractions which simply don’t exist in Go. Go gives you less choice, and thus projects are more similar, and thus I suspect legacy Go code adds will be easier to maintain. Of course this property may not endure once Go acquires generics. It should be said that I’m a big fan of both languages, and I am especially enthusiastic about Rust in that it fits my compulsion to have code that is both very abstract and very performant.
- brundolf 5y ago
  > error handling framework Not sure what's meant by this; Rust has a standardized Result type, with dedicated syntax for early-returning errors and type checks that make sure you handle them (or at least explicitly ignore them). Go, on the other hand, has a shaky error story and from what I've heard it's a constant problem due to enforcement-by-convention. > prefer owned vs borrowed by default Not really sure what this means either... the owner of a value generally falls out naturally from how you're trying to use it. It's not really an either/or option. It needs to live where it will be around long enough for everything that's done with it, and everything other than the owner should get a reference to it. Maybe you're talking about passing by reference vs implementing Copy? If so, that's mostly a performance concern. > Of course this property may not endure once Go acquires generics Yeah- one of the few things I like about Go is that it doesn't have generics (yet). I've seen generics make TypeScript codebases impenetrable, and I think there's a decent case to be made for not having them at all.

aranchelk 5y ago

I use neither Go nor Rust and don’t have an opinion, but it’s worth pointing out that “difficult to learn” is highly contextual, e.g. Python or Ruby were probably relatively easy to learn if you already knew Perl or PHP. I found Haskell quite difficult to learn. Subsequently PureScript was very easy. Widely shared knowledge and concepts change over time and they will affect ease of adoption.

mumblemumble 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. I'm not so sure about that. (Or perhaps the definition itself needs scrutiny?) Most the languages I've seen get a reputation for being easy to learn have also subsequently earned a reputation for being a maintenance hassle: perl, ruby, python, php, javascript, etc.

deleted 5y ago
[deleted]
toxik 5y ago
Language nitpick in the parent’s comment: “touted” is definitely the wrong word here, to tout is to solicit.
- perl4ever 5y ago
  "touted" has a positive connotation to me, so it doesn't sound right to tout negative aspects of something. But the meaning seems clear.
- yesenadam 5y ago
  > “touted” is definitely the wrong word here, Uh, no. In Merriam Webster, that's meaning #2. Meaning #1 is > to make much of : promote, talk up > touted as the summer's blockbuster movie > the college's much touted women's studies program https://www.merriam-webster.com/dictionary/tout https://www.merriam-webster.com/dictionary/tout
  - mumblemumble 5y ago
    Realistically, that first definition is slightly ambiguous; it may or may not mean to imply that the talk is supposed to be promotional and not derisive in order for the definition to apply. I am guessing that they probably did mean to imply that connotation, though, based on other information on the page. I'd argue, though, that the reality is that the word's meaning is in the process of shifting from being a synonym for "promote" to being a synonym for "make out to be"; that reflects much common usage, and dictionaries always lag behind a bit in cases like this. They have to - they're a descriptive artifact, not a prescriptive one.

aidenn0 5y ago

I cannot write a program from scratch in Haskell. I just can't wrap my brain around it. However, every time I've needed a new feature in a program I use written in Haskell, it's been easy and a pleasure to implement.

woah 5y ago

Have you ever maintained a piece of Rust code?

void_mint 5y ago
Yep! edit I am amused at this downvote. I was asked a yes or no question, and responded with a yes. What could possibly make this response downvote-worthy?

orwin 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. Disagree. First, difficult to learn is not difficult to onboard. Second, unless you think Ocaml is not hard to learn, i think this is a great counterexample.

zozbot234 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. Rust is not more "difficult to learn" or "difficult to onboard" than C++. And C++ is certainly a language with plenty of legacy, enough that you could reasonably call it "brown". Go is a rather different language that's perhaps best compared with Java as its closest "brown" counterpart.

void_mint 5y ago
> Rust is not more "difficult to learn" or "difficult to onboard" than C++. Saying Rust isn't more difficult than possibly the most difficult thing is not a good argument in favor of Rust not being difficult, no? People dread maintaining legacy C++ systems. People dread maintaining legacy systems. Rust will be no different.
- kevin_thibedeau 5y ago
  The problem with C++ is that the various standards have encouraged changing idioms. Pre-standard, 98, 11, and 17 are significantly different when the new language features are fully leveraged. Legacy code creates inconvenient barriers when interoperating with modern stuff. Rust may be able to escape this problem.
  - resonantjacket5 5y ago
    I mean eventually there's going to be rust 2 etc...
    - steveklabnik 5y ago
      Not from the Rust project; someone else would have to come along and build it.
      - resonantjacket5 5y ago
        I mean there will be more and more changes to Rust, just like how C++ has had many changes over the years. Rust 2020, .. 2025, 2026 etc..

solipsism 5y ago

It is almost certain that in 10 years, both will be used more than they are now by several x's. I think pretending you can predict what'll happen with either (and the industry) over that time is pretty silly. You contradict yourself.

cbsks 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" Does anyone know if there have been studies about how long it takes to learn different programming languages? I hypothesize that it would take a beginner programmer longer to learn Rust than C, but probably a similar amount of time as learning C++ (which I think is the closest “traditional” programming language to Rust).

Ygg2 5y ago

I can learn any language in a day or two. And become proficient in it in a week. Big part of mastering is less about knowing the language and knowing its plumbing. Quirks, unique behavior, library, tooling, etc. Dynamism is a constant source of pain. Because it makes tooling and thus exploring language harder. In Rust there is little such dynamism. Actual problems understanding are macros and proc macros. And finding the right Trait. Tooling around Rust is standarized. You have cargo, rustc and they bring in the rest. While there is some chance of Rust going nuts and adding some bizzare thing like inheritance, HKT++, the chance that it will reach cognitive complexity of Scala or C++ is lesser.

Decabytes 5y ago
I program in Python by day. Racket is probably the language I know best after Python, then maybe Groovy. I've had exposure to R, C, C++, D, Java, Common Lisp etc, and I find it easier to pick up new languages due to my familiarity. While Rust has all the constructs that I'm used to from these other programming languages, I find Rust to be the most difficult one for me to learn in recent memory. The documentation is great, the book is great, the tooling with Cargo is great, but after getting through the first 15 chapters in the Book I struggled to write a program that had any sort of complexity. Sure I can add a dependency super easily to my project, but figuring out what errors everything in the library throws takes a lot of work. Sometimes I get confused about using panic!, expect, unwrap, or ? when I'm writing my own functions or interfacing with others. Swimming through the myriad of traits on different structs is confusing, and I sometimes get tripped up passing closures. And don't get me started on Macros, with great shame, they still have not clicked for me, in Lisp, or in Rust. The language just feels very different from what I'm used to, and I've never had such a hard time getting code I've written to compile correctly. I'd be totally lost without all the help from the subreddit and the book, and I appreciate everyone who has helped me. I know this will get easier... and it has. But it will take longer for me to get comfortably with Rust then it has for other programmings languages in the same time period. This is not to say that it's a bad language. I remember one day after having debugged a Python issue that ended up being a stupid logic error on my part I exclaimed "I wish I knew a programming language that would save me from myself". I think... Or rather I hope Rust is that language in the long term for me

shinjitsu 5y ago

I think the "difficult to learn" and "difficult to onboard" is important to keeping rust a "Most Loved Programming Language". If only those who make it through the "difficult to onboard" phase use the language extensively, then only they will be responding to the "most loved"/"most dreaded" question. I taught a university seminar that looked at rust and another emerging language a couple of years ago and only 2 students out of 30 said they would use rust again after the class. So the rest will never get a chance to answer the survey question about rust.

the__alchemist 5y ago

I wouldn't call Rust difficult to learn. The syntax quirks (Knowing where to put `&` etc takes time, and traits are abstract, but used all over Rust codebases). For example: Look at Python which is typically considered easy to learn. In Rust, I know that I can create a project using official tooling; specify dependencies cleanly in `Cargo.toml`; use the built-in linter, and formatter. Check the Rust docs page for any dependencies, including type signatures for all functions, and a list of struct fields. Look in the `examples` folder of a dependency's repo for code snippets. In Python, I'm likely to find a comparative mess of sparingly-documented documented third-party tools, dependency docs, and Stack Overflow posts. Or, look at embedded, where C is considered a simple language. In C, it's not obvious how I'd start. Use something like Cube-MX or Keil? GCC? All the options are messy and tough to learn. In Rust, I clone a template repo, cargo-install 2 or 3 tools and targets, and `cargo run` to compile and flash.

petre 5y ago
C/C++ and Rust are both hard IMHO. D is way easier, one gets productive quite fast and there are also more advanced language features once you get proficient in it, unlike Go.
valand 5y ago
> I wouldn't call Rust difficult to learn I agree with this too. This is because you know what Rust brings you compared to what you used in the past that cause you pain. Unfortunately, some people that have difficulty learning Rust (or hear about it) focus solely on the learning process and not what they gain by learning it. Learning a low-level language is inherently hard because there are more at stake, it is simply more complex. For people that work where dangling pointer, data-races, is never a problem, they are learning about the problem the same time they are learning about the solution (Rust's ownership concept), and I came from that place too.
nec4b 5y ago
> Or, look at embedded, where C is considered a simple language. In C, it's not obvious how I'd start. Use something like Cube-MX or Keil? GCC? All the options are messy and tough to learn. In Rust, I clone a template repo, cargo-install 2 or 3 tools and targets, and `cargo run` to compile and flash. Keil is a company that builds an IDE, compiler and debuging tools for microcontrollers. CubeMx is a configuration tool/code generator for STM microcontrollers. You comment makes no sense in regards to C language, unless you are saying that rust/cargo automagically does everything that Keil products and CubeMx do?

HWR_14 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. I disagree. The things that make for good maintenance correlate with both difficulty to learn and difficulty to onboard. (The converse is not true.) Things that are easily to learn tend to be easy to start with, but end up tacking on, via frameworks or coding standards, pieces that raise both difficulty to learn and to onboard as complex projects exist. Specifically, maintenance requires thinking like the person or people who initially created the code. The more your thinking aligns with them, the easier it is to maintain. And that act of changing to think like them is learning and onboarding.

derefr 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. I think this presumes that you have to teach people the language. But most maintenance programming is done by hiring people already familiar with the language the existing codebase is written in, and then bringing them on to work on the existing project. Rust isn’t hard to onboard for an individual project, in the same way that a macro-laden Lisp codebase is. Once you know Rust, you know Rust. It takes more effort to “know Rust” because you have to learn all the ecosystem stuff expected of someone who “knows Rust”; but from the perspective of an employer, you can just hire “someone who knows Rust”, and they’ll come with all that knowledge. And, in fact, an experienced Rust dev may be able to start work on a novel-to-them existing Rust project, a lot faster than (for example) an experienced C dev would on a novel-to-them existing C project, as a large stdlib / conventional ecosystem of foundational libraries (as in the case of Rust) tends to translate well to experienced developers coming into a codebase and quickly recalling everything, because it’s a bunch of the same batteries/libraries they’ve already used in the past. The difference between a design pattern and a language feature, is that you can recall language features, while you have to recognize design patterns (i.e. grok the code in order to identify what pattern(s) it’s trying to reify.) Languages with more formalisms (either built into the language, or in common use in the ecosystem) increase the amount of recall that new maintenance programmers can do (or rather, decrease the amount of recognizing they have to do to get up-to-speed), and thus make switching a maintenance programmer between codebases “cheaper.” ————— I bring this up not from the perspective of a Rust programmer, but from the perspective of an Erlang programmer... who also doesn’t like Go very much (though I do write quite a lot of Go! As a maintenance programmer!) IMHO Erlang and Go aren’t all that fundamentally different runtime-wise. Presuming you’re using them for the same thing — writing highly-concurrent, fault-tolerant network servers — the main difference between the experiences of coding in Go and in Erlang, comes down to the fact that Go provides you with a bunch of concurrency primitives that you have to put together as design patterns — and where maintenance programmers then have to recognize those patterns; while Erlang actually has universal concurrency formalisms that everyone takes advantage of, and so those formalisms can simply be recalled on new projects. I advise anyone who thinks that “recognizing design patterns” is a cheap-and-easy thing to do, to tell me what’s going on in this file: https://github.com/ethereum/go-ethereum/blob/master/eth/downloader/statesync.go https://github.com/ethereum/go-ethereum/blob/master/eth/down... . I’ve stared at this code on-and-off for two years, and I still don’t have a mental model for it. If this code was made out of cleanly-separated named/opaque formalisms, rather than fifty design-patterns tied into a knot, I can’t even imagine how much more productive I would have been working on it.

emteycz 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining. Strong disagreement here. It could be difficult because it's built for maintaining. People who are unable to understand Rust are the people you don't want anywhere near your C/C++/Rust project.

valand 5y ago

> A language that is touted as "difficult to learn" and "difficult to onboard" is by definition not built for maintaining PL learnability alone is not significant as a factor for a PL to be chosen for a certain task, unless it is impossibly hard. Rust, looking at the growing community, is not a PL that is impossibly hard to learn. A PL is chosen for a certain task for its features. The same as any other class of tool, "A is chosen for X because of A's feature". The learning curve is simply the side-effect of the PL's minimum features need to be learnt for it to work. Rust being a low-level language + an extra layer of protection is inherently hard. But let's see how it fares in 10 years. There have been successful projects built on Rust, firecracker, figma, discord, and many more, despite it being so young.