21 ms·

Using Rust at a startup: A cautionary tale

107 points by mawaldne 4y ago

fasterthanlime 4y ago
Dupe of https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007
- SeanAnderson 4y ago
  Indeed. I got a couple of paragraphs in before I realized the author was making some surprisingly familiar points :)
- mananaysiempre 4y ago
  That is to say, link should be changed away from the Medium proxy. (Even if the proxy is nice.)
KingLancelot 4y ago
davidw 4y ago
> the service we were building was a fairly straightforward CRUD app. The expected load on this service was going to be on the order no more than a few queries per second, max, through the lifetime of this particular system. The service was a frontend to a fairly elaborate data-processing pipeline that could take many hours to run, so the service itself was not expected to be a performance bottleneck. There was no particular concern that a conventional language like Python would have any trouble delivering good performance. Yeah, that's not the kind of thing you use low level stuff for. Ruby on Rails or Node or Elixir, or whatever Java thing is going to let you iterate faster than a lower level language.
- aswanson 4y ago
  I mean, Rust is the cool new language though.
  - davidw 4y ago
    I'd love to have an excuse to write something with it, but it'd need to be the right excuse - something low level requiring some speed.
    - aswanson 4y ago
      Same. Im looking for an excuse also.
- dabeeeenster 4y ago
  Elixir for a crud app? Really?
  - lawn 4y ago
    As a fan of Elixir it seems like a good fit. Why do you think otherwise?
  - sph 4y ago
    Yes, really. The Phoenix framework is one of the most productive web frameworks around, and Elixir is a very pragmatic functional language that is easier to adopt than others. Creating a CRUD module, with schema, migration, controller, view, template and data validation is literally one command away with `mix phx.gen.html/phx.gen.json` https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Html.html https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Html.html
  - ajmurmann 4y ago
    I haven't written Elixir in years, but Elixir with Phoenix was a quite similar experience to writing a CRUD app in RoR.
  - jcpst 4y ago
    Really! The flagship web framework for Elixir, “Phoenix” is pretty well made https://www.phoenixframework.org/ https://www.phoenixframework.org/
  - drewbug01 4y ago
    If given the choice between Rails (Ruby) and Phoenix (Elixir) for a low-traffic CRUD app I might have the same sort of question as you - really? But if the choice is between Elixir and Rust for that same CRUD app, it doesn’t seem strange; Elixir would be a far better choice. I would presume the commenter is more familiar with ecosystems like Elixir, even though it wouldn’t be the most optimal choice. But certainly more optimal than Rust in that case.
  - cjglo 4y ago
    Elixir offers a lot of the great protections of rust. If you haven’t tried it, I 100% recommend.
npigrounet 4y ago
alexfromapex 4y ago
I think for most companies, using Rust for security and performance critical areas is best. For other things, Rust can run Python code via FFI so no need to take the productivity hit unnecessarily.
cardanome 4y ago
Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with automatic garbage collection for your project, do that. Always. If not, sure, Rust or whatever else language is in that space can be a good choice for embedded development or game dev or whatever. That should be common sense. No need for an article. I hope for the sake of Rust that the hype around it will die soon so that it can become a pragmatic choice for certain projects.
- vbezhenar 4y ago
  IMO if you would forget about borrow checker, Rust is awesome language by itself. I'm not sure if it's even possible, but I think that if GC were introduced to Rust as an optional part, it would make Rust suitable for CRUD apps. Like all low-level libraries are written with borrow checker and you can write your code with borrow-checker or GC, your choice. So you'll still get superior performance compared to any other GC languages, because your standard library is incredibly fast. And your code will use GC because your code does not matter from performance PoV. And if some function matters - you use borrow checker in that function, so it's fast. Also green threads might be a good addition. It seems that modern computing reinvents it all over again. Golang, Java. Async/await is hard, people want to write blocking code and get good scalability at the same time. We need a silver bullet programming language. Period. Suitable to write CRUD and MCU firmware at the same time. Until this silver bullet is not found, we will reinvent new languages.
  - lolinder 4y ago
    This is the kind of attitude that will send Rust the way of C++. Features cost, even optional features. No programming language can or should try to be everything to everyone: to attempt it is to serve no one very well at all, because you split the focus of the language development between too many use cases and you complicate the language so thoroughly that onboarding a new programmer becomes an exercise in re-education about which subsets are acceptable in the given organization. Rust's niche is safely managing memory without a GC. If Rust adds a GC, even an optional one, it will have lost its soul.
throway22342 4y ago
My friends, coworkers, and peers always ask me if they should start using Rust for web apps and I always say no. The web frameworks are still immature, and rapidly changing. I still use Rust for CLI, lambdas, and/or backend web services. Ruby on Rails tickles the cheap and easy CRUD + RAD paradigm pretty well. I don't see Rust doing that anytime soon.
revskill 4y ago
One question though: What does Garbage collection do besides what Rust provide? Ownership and borrow checker.
- odo1242 4y ago
  Garbage collection deals with a couple (albeit rare) additional cases (e.g reference cycles) while requiring significantly less mental overhead.
- darthrupert 4y ago
  Frees cognitive resources because you can usually forget that menory management is a thing. When on GC.
  - dinosaurdynasty 4y ago
    I usually don't think about memory management in Rust, to be fair. Also GC doesn't remove all resource management... ironically I find most GC-based languages to be more mentally taxing when managing manual resources (file handles, mutex locks, etc).
    - Jensson 4y ago
      Haskell programmers says that Haskell is just fine as well, but in the end there aren't many big programs with complex architecture in these languages. Compilers, interpreters, crud servers etc, those things are very simple architecturally so for them these languages are fine, but for more complex cases these pure languages seems to be too cumbersome.
      - revskill 4y ago
        What i love about Haskell, is it made things simple, not simpler. If you have a program with complex architecture, you're doing wrong somehow. If you can't decomposing the complexity, you will have complexity. I think it's not about programming language, it's about human (and technology).
y7 4y ago
I find it a little odd the author mentions C++ often. I think the use cases for C++ and Rust are pretty interchangeable, and C++ devs would and should probably know about lifetimes anyway. (That said: yeah, don't use Rust for CRUD apps.)
- ithkuil 4y ago
  Coming from c++ I had no troubles with lifetimes in rust; they were obvious and moat of the time I would have structured the code in the same way anyway. The main problem i encountered (beyond the usual learning curve for stdlib and other common libraries) is all the gotchas and rough edges around async
- nicoburns 4y ago
  > I think the use cases for C++ and Rust are pretty interchangeable Hmm... in some ways. I feel like one probably shouldn't be using C++ for anything network facing or security critical, whereas Rust is ideal for those situations.
modeless 4y ago
I liked the recent article about writing the Apple Silicon GPU Linux kernel driver in Rust. Now there's a perfect application for Rust if I ever heard one. The service described in this article is a great example of an application that Rust is not the best choice for. When I first heard about Rust I really thought it would be the language to end all languages, but even after just a few days using it I realized that's not the case. Maybe someday someone will come up with that perfect language for everything, but given recent progress in AI I think the more likely long term outcome is that neural nets will start writing all our code for us. I wouldn't start work on a new programming language today given the changes that are clearly coming in the next 20 years or so. At least, not one designed for humans. Maybe there's an opportunity for someone to make the first programming language designed for neural nets to use. Maybe that neural net language would look like Rust. The downside of lower programmer productivity may not matter when the programmer is a neural net. You can just run more neural nets! And neural nets are anything but perfect so they will still benefit from the safety guarantees Rust provides. Rust is the language that I don't want to write, but I want the software I use to be written in it.
ekidd 4y ago
Rust would not be my first choice for a simple CRUD app. There are too many other tools that handle that space well. I have used Rust at a startup, and it worked out extremely well. But we used it for CLI tools (where it shines), and performance critical code, and for specialized, high performance servers.
jll29 4y ago
In many larger projects, there is a need for efficiency and/or low-level work in _some_ corners, _and_ there is also a need for productivity, rapid development in _other_ parts. And everywhere do we want maintainable and readable code that is easy to understand. Selecting more than one language sometimes works, in my experience you can have various microservices that talk to each other, then it doesn't matter what language each is implemented in. However, it isn't optimal to have to master more than one language (most good people do, but we also want to cater to weaker team members; in football, not everyone is a Ronaldo, Pele or Messi either). I don't see why C++ or Rust shouldn't have opt-in garbage collection offered for parts of the codebase where this makes sense (where productivity is worth more than runtime speed), which is probably most part of most projects if we are honest. As some of you know Rust actually _had_ GC in an earlier version, and some readers may complain saying "but C++ can do GC if you want" (of course you can add a Boehm-style GC in your project). But what I'm referring to is that there should be a "batteries included" GC-enabled part of systems programming languages by default (as a technical and cultural preferred setting), unless you mark up a library/crate/class as performance-relevant. This could be done with a mechanism similar to marking up "unsafe", e.g. "uncritical" (= runtime matters less in this section compared to productivity). Then strings and other objects could be garbage-collected and programmers could focus on solving the actual problem instead of managing memory. Critical sections could be marked as such, and there'd be the much-coveted "zero overhead" abstractions for these. The advantage is you would not need to stay up to date in two languages, and you could avoid FFI-type integration, which tends to be brittle (JNI? shudder!). An entirely separate point is the availability of programmers that master a language. I totally agree with the poster that you should use a mainstream language to avoid being hit by a talent shortage.
stephc_int13 4y ago
Are we already there in the hype curve? The classic silver-bullet story, same old, same old.
- ferdowsi 4y ago
  I'm glad we're here. More and more organizations are going to have serious buyers regret after being sold a bad bag of goods by all of the Rust hype.
jpgvm 4y ago
Startups spend innovation tokens very poorly. Progamming languages, hosting platforms and non-standard databases aren't ideal places to spend such tokens. For most apps what you want is JVM or .NET, PostgreSQL or MySQL or SQL Server, k8s or vanilla VMs/containers. You almost never want different programming languages to these mature stacks, you might think you do, but you don't. Node.js/Python/Ruby etc all promise a fast start but in reality any perceptible velocity benefit is dead within months, usually before anything of value is shipped. Most of it has to with ecosystems (library quality etc, framework maturity) but those also being the 2 most advanced managed runtimes helps a ton. For databases just standard RDBMS is almost always the way to go, unless you startup is intrinsically a data startup and you know ahead of time you require very special properties you just want one of these. Keep hosting simple. Don't use any fangdangled "serverless" nonsense. It's not worth it, shipping a week or 2 later because you took the time to setup EKS/GKE/AKS will pay off in spades. k8s reputation for complexity isn't warranted and it's essentially standard now and will remain that way. So now you have freed up your innovation tokens you can spend them on solutions to your actual business problems instead of on stuff that will only continue to eat your token budget and often yield negative real returns.
- eropple 4y ago
  For my money, at least Node and Python have absolutely reached the point where they can provide self-feeding velocity. I quite like the JVM as well--I've written a lot of Java and a lot of Kotlin--but TypeScript and modern, typed Python are very defensible options. I know more about Node than Python, so that's easier for me to talk about, but for my money tools like Fastify have a really excellent ecosystem around getting shit done in ways that don't buy you too much technical debt in the future. Databases, fully agreed. "Use Postgres unless you have a reason not to." When you need a key-value store for caching or whatever...consider Postgres hstore first, and then spin up a Redis only when you need to. Hosting...depends. With my product hat on instead of my infra hat, I think there's real value in managed serverless options. The various Heroku descendants--I work at Render, but I'm friends with the Fly folks and they're great too--can, if you are in a low-devops environment, provide some real benefits. Or, for a more stripped-down option, AWS Fargate/GCP Cloud Run, but to bootstrap that you're going to be doing somewhere between the work necessary between a Heroku++ option and "run a server somewhere and keep it patched".
lumost 4y ago
If you are writing CPP, rust is a godsend. Many pitfalls/code review debates/wtf moments simply don’t happen in the language. There are huge cpp code bases in the wild which need help. However rust string handling is barely a step above c’s, there are a variety of datastructures c engineers dislike simply because of the memory management constraints. Getting 2x better performance than Java is a marginal gain for many environments. I really hope rust takes a bent towards ease of use. Stabilizing a rust gc arena would be hugely impactful, or simply revisiting the string api.
- pitaj 4y ago
  I've found Rust is also far better than weakly typed and dynamically typed languages as well. > However rust string handling is barely a step above c’s How so? Personally I've found it very good.
  - lumost 4y ago
    Having 3 separate string types commonly used across the standard library is a huge friction. For beginners, it’s impossible to write a common program for doing some basic string manipulation without reading 3/4 of the Rust book and waiting through dozens of compilation failures.
    - pitaj 4y ago
      Are the three types you refer to str/String, CStr/CString, and OsStr/OsString? There are trade-offs associated with having multiple string types, but the alternative is worse. It's better to force the developer to handle these things up front than to have bugs down the line. str/String being UTF-8 is great. Is means that the various standard library functions associated with them have well-defined behavior. CStr/CString are necessary for FFI, but I wouldn't really say they're commonly used in std. OsStr/OsString are necessary unless you think the standard library should automatically convert whatever random format the OS uses into UTF-8. Rust's decision to not treat everything like Unix is actually a good thing. > For beginners, it’s impossible to write a common program for doing some basic string manipulation without reading 3/4 of the Rust book and waiting through dozens of compilation failures. Personally, I think the standard library makes it pretty easy to learn how to convert between the types.
voxl 4y ago
> Because we had chosen an “esoteric” programming language for this service, the other engineers in the company who might have otherwise been helpful in building features, debugging production issues, and so forth were largely unable to help because they couldn’t make heads or tails of the Rust codebase. Then they are bad engineers and should be fired. Maybe it's just my general rage at so-called developers being incapable of understanding undergraduate level recursive functions, but the quality of developer is on the floor in my opinion.
- ferdowsi 4y ago
  Not very convincing when "git gud" is the common response to Rust's exuberance towards needless complexity in use cases that it doesn't fit well in (like CRUD applications)
  - 0x457 4y ago
    I don't think it's a "git gut" kind of response. There are some engineers who keep repeating "oh X is so hard, I've never tried myself or even looked at it, but I've heard that it's hard". X could be anything. If you are a software engineer and not a code monkey in a web shop, you should have no problem at least trying to expand your knowledge. I worked with people who're afraid of changing a line in k8s manifest file even after you tell them what and where. There are some languages that look alien to the typical engineer and hard to understand without at least a minor prior knowledge, but Rust isn't one of them.
- bigbillheck 4y ago
  I agree that it sounds like they're not the sharpest knives in the drawer, but completely disagree on the 'should be fired' part.
distalx 4y ago
Previously: Using Rust at a startup: A cautionary tale – https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007 - 10 Days ago! (332 comments)
oxff 4y ago
The author equates C++, Go, Python, Java as languages. I think there might have been some other things wrong than the language here.
- ferdowsi 4y ago
  Rust advocates want us to believe that Rust can effectively replace all of the use cases of those languages, so it's totally fair to group them.
Mesopropithecus 4y ago
> [...] most modern, procedural languages (C++, Go, Python, Java, etc.) all very similar in terms of their basic concepts. [...] With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, [...] Maybe an oversight, C++ is misplaced in that list. C++ without knowing about ownership and lifetimes is a recipe for disaster.
- dinosaurdynasty 4y ago
  Even in the other languages lifetimes/ownership are a useful mental tool for managing manual resources (DB connections, transactions, mutexes, file handles, etc). There's so much code in Go that is documented like "while this object takes a file handle, it does not close it itself even though there is a close function, you will need to close it" that in Rust is just a lifetime annotation.
hardwaregeek 4y ago
One note about hiring: if you want to hire like super experienced, senior developers who can architect your rust codebase and tell you definitively how to write Rust, you’re probably out of luck. There just aren’t that many people. You can get senior developers and you can get developers with Rust experience but the intersection of the two is very sparse. As a result, expect some churn in your codebase. Your team will have to discover and iterate upon best practices. Avoid the impulse to spend too much time code golf refactoring because “oh I can use a proc macro to decrease boilerplate while avoiding the orphan rule and having nice traits!” Rust can definitely nerd snipe you by making you worry about some very small edge case like oh no I’m copying a few too many times. Basically unless you’re pretty damn sure you have product market fit (PMF) and you’re sure that rust offers an appreciable benefit to said PMF, I would not use it.
- zozbot234 4y ago
  Any senior developer with C/C++ experience will probably be pretty comfortable with Rust and its ecosystem. It's not an overly complicated language.
  - loeg 4y ago
    I was very familiar with C before starting to do professional work in Rust, and ran into a similar trap as the grandparent comment describes. Since then I've gained professional experience in C++ as well. Without specific Rust experience, I wholly disagree that "any senior developer with C/C++ experience" will have a good sense of optimal Rust project architecture out of the gate. A reasonably good starting point, sure. But it's a different enough language that you can't just reduce architecture concerns to "it's not overly complicated."
    - zozbot234 4y ago
      > ran into a similar trap as the grandparent comment describes. The only "trap" I've seen referenced wrt. Rust is the concern that coding for agility and flexibility introduces boilerplate. Such as GP's concern about calling .clone() too much instead of worrying about lifetimes. But every language has its unidiomatic parts; it's a benefit of Rust that they chose to make the most thoroughly refactored style look "clean and natural", and the most open to refactoring "hackish and unidiomatic" rather than the reverse (cough, cough Java cough, cough). Describing that as a pitfall is just not very helpful!
lordleft 4y ago
Great article. I love Rust, but I don't associate it with (development) agility, despite the overpromising of Rust advocates. It requires a tremendous amount of the developer (at first).
nindalf 4y ago
This was discussed 10 days ago (287 points, 332 comments) - https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007 dang - scribe.rip is an alternative front end to medium.com. That's why this wasn't caught by the dupe detection.
avinassh 4y ago
Using Rust for CRUD stuff is not a good idea. I would pick Go or Elixir may be. If you are starting a new project, ask yourself: 1. Would I be writing this in C++? Then Rust is a great alternative. 2. Would I be using C? Then may be Rust or Zig would make a good alternatives 3. Would I be writing it in Ruby or Python? Then Go or Elixir can be considered
wyldfire 4y ago
> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages ... Some of those “new” ideas are, of course, present in other languages — especially functional ones. With C++, lifetime and ownership are just about as important but unfortunately no one's got your back. You can ignore lifetimes and ownership but you do so at your own peril. And the compiler won't tell you you're doing it wrong because the language wasn't designed for it to do so. If you want a taste of rust's "mindset" (with respect to limitations imposed by some types) without jumping ship to a new language, try C++'s Guidelines Support Library [1]. It introduces some of the same benefits/friction as switching to rust but without a new language. Opting-in to some of these guidelines might be a gentler way to get some of the benefits of Rust. But it comes with a similarly higher bar. [1] https://github.com/microsoft/GSL https://github.com/microsoft/GSL
- deleted 4y ago
  [deleted]
rvz 4y ago
> With Rust, even after months of working daily in the language, most people on the team never felt fully competent. A number of devs told me they were often embarrassed that it was taking longer than they expected for their features to land and that they were spending so long trying to wrap their heads around Rust. Very unsurprising. Rust is a bad choice to use when building a typical CRUD app especially when you are not making any money. So when I saw this about immature libraries: > Rust, by comparison, has long felt like a work in progress. The docs for a lot of popular libraries are pretty sparse, and one often needs to read the source code of a given library to understand how to use it. This is bad. I just couldn't help but say that someone has finally cut through the hype, and experienced the reality of the immature state of the library ecosystem in Rust rather than pretending that it is fine; especially for a startup which can result in the failure of feature delivery and of itself. This cargo culting of programming languages promised by a fan club or hype squad of any new language needs to stop.
samuel2 4y ago
Would Rust be worth learning for implementing (numerical) optimization algorithms?
mustache_kimono 4y ago
Previously posted with lots of engagement: 11 days ago - https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007 19 hours ago - https://news.ycombinator.com/item?id=33837803 https://news.ycombinator.com/item?id=33837803
rootusrootus 4y ago
The cautionary tale is, no doubt, don't use trendy tech stacks if you want your startup to survive. You need a product, and the correct tech stack is whatever gets you there soonest. If you're wildly successful you might eventually need something better, you can worry about that then, after all your competitors with awesome tech stacks have gone out of business.
deleted 4y ago
[deleted]
bigbillheck 4y ago
> how to grok the often arcane error messages from the compiler This, to me, is a bizarro opinion. Compared to c++, rustc's error messages are (by and large) incredibly helpful and clear, oftentimes showing how the code should have been written.
gregwebs 4y ago
I have been shocked on multiple occasions to see how difficult teams make it to do basic CRUD apps. Go lang is suggested rather than Rust, but the standard way of using Go is lower-level and less productive (unless you care about performance) than the Rails of 10 years ago (and I am not a fan of Rails). Haskell can be a great option here- all the high level benefits of Rust and more in a language with a GC and plenty of good frameworks and libraries for CRUD. Unfortunately its one of the only languages that has a greater learning curve than Rust.
ear7h 4y ago
My devil's advocate take on this article is that they're using Rust as scapegoat to their scaling (team not performance) problems. I use Go at $DAYJOB and we're having similar problems for lead times. OTOH, the novelty of Rust in webdev, means there isn't someone to make a decision like, "we don't need performance, so use threads instead of async and pass everything around in a box". I've sunk plenty of personal time trying to wrangle async on a CRUD app for learning, and I recommend it as an exercise, but I'd avoid async if I was trying to ship something.
sreevisakh 4y ago
Rust has an undeniably steep learning curve which can cause a productivity penalty for beginners. However, there are some statements in this article I simply can't agree with based on personal experience. I'm using Rust to develop a few projects. At this stage, I would go for Rust for general development, irrespective of how useful manual garbage collection is. To put it in context, my other favourite language is Python. > Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages, and there is a pretty steep learning curve, even for experienced programmers. Rust's borrow checker system doesn't exist in isolation. It's designed to avoid problems that can occur with computing and memory model of programming - things like call stack frames (esp constant size), heap memory and other resource management, concurrency paradigms, etc. These are just the tip of low level computing models. There are things like cache coherence that Rust doesn't address directly. These are concepts that programmers must know if they want to do: a) Low level programming b) High performance programming. The problem raised by author may partially belong to the second category. Even if it is not, programmers should probably learn these, because they are likely to face such problems at some point and may gain from that knowledge. There are two ways to learn the borrow checker rules. The first is to start with the rules itself. It's going to appear rather convoluted. The other approach is to understand the machine/memory model that I mentioned above first. Once you do, the rules are going to make much more sense - especially in the context of specific error messages during coding. These days, I'm able to connect every single error message that I see to some potential memory or concurrency problem, even though they are the result of some seemingly convoluted but simple borrow checker rule. > Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below). There were dozens of errors that I made today that were easily understood just by a glance at Rust's error messages. The help messages that accompany these error messages are often the solution that I needed. Even otherwise, the error messages point out potential low-level bugs as I mentioned above - allowing me to make proper corrections. This may just be anecdotal. What is not anecdotal is that the Rust team reworked the error messaging early in the project's life to make it that way. It's generally accepted that Rust's error messaging is top-notch. I find it disrespectful to all those early endeavors to call it arcane. Perhaps it's a good idea to try to learn those error messages. There is an entire index of errors with detailed explanations [1]. > We started having weekly “learn Rust” sessions for the team to help share knowledge and expertise. This was all a significant drain on the team’s productivity and morale as everyone felt the slow rate of development. Perhaps this is the wrong way to approach the problem. The thing that may need learning is type theory. Type theory is often too esoteric with a theoretical mathematical approach. Perhaps we need an introduction to it that encourages people to see a bunch of bits as a storage for data with a particular meaning (the type). Next step would be to how to track types using software (type system) and then extend the idea all the way to include constant-size stack frames, generics, polymorphism and lifetime tracking. > Libraries and documentation are immature Library ecosystem is still growing - especially async programming. But documentation support is a first-class feature of Rust's language ecosystem. I find myself writing documentation much more often in Rust than with other languages. It's also equally easy to browse the documentation of the language, stdlib and other libraries. Sections are marked out clearly and navigation is well thought-out. Every search of a feature or API takes me through half a dozen links to the final target in a matter of minutes, if not less. It's a good investment to learn browsing technique for documentation in any language. > Rust makes roughing out new features very hard Somehow, my experience doesn't match here either. I use the same technique for trying out new features in both Python and Rust. Create a scratch project for each experiment. A single project may take up to a dozen such scratch projects. It's marginally easier in Rust than in Python, mainly because project management is another first-class feature of Rust tooling. But what's really remarkable about Rust compared to most other languages I've encountered is that Rust's discipline gently nudges the scratch project to a proper design. By the end of the scratch project, the experimental code is often in a good enough state to be directly integrated into the main project. It's amazingly friction-less to integrate integrate external code into the main project. I wouldn't blame the author for having a very different experience as mine. But I sure would like to know what makes Rust 'click' for some, but remain a tough nut to crack for others. [1] https://doc.rust-lang.org/error_codes/error-index.html https://doc.rust-lang.org/error_codes/error-index.html

107 points by mawaldne 4y ago

fasterthanlime 4y ago

Dupe of https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007

SeanAnderson 4y ago
Indeed. I got a couple of paragraphs in before I realized the author was making some surprisingly familiar points :)
mananaysiempre 4y ago
That is to say, link should be changed away from the Medium proxy. (Even if the proxy is nice.)

KingLancelot 4y ago

davidw 4y ago

> the service we were building was a fairly straightforward CRUD app. The expected load on this service was going to be on the order no more than a few queries per second, max, through the lifetime of this particular system. The service was a frontend to a fairly elaborate data-processing pipeline that could take many hours to run, so the service itself was not expected to be a performance bottleneck. There was no particular concern that a conventional language like Python would have any trouble delivering good performance. Yeah, that's not the kind of thing you use low level stuff for. Ruby on Rails or Node or Elixir, or whatever Java thing is going to let you iterate faster than a lower level language.

aswanson 4y ago
I mean, Rust is the cool new language though.
- davidw 4y ago
  I'd love to have an excuse to write something with it, but it'd need to be the right excuse - something low level requiring some speed.
  - aswanson 4y ago
    Same. Im looking for an excuse also.
dabeeeenster 4y ago
Elixir for a crud app? Really?
- lawn 4y ago
  As a fan of Elixir it seems like a good fit. Why do you think otherwise?
- sph 4y ago
  Yes, really. The Phoenix framework is one of the most productive web frameworks around, and Elixir is a very pragmatic functional language that is easier to adopt than others. Creating a CRUD module, with schema, migration, controller, view, template and data validation is literally one command away with `mix phx.gen.html/phx.gen.json` https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Html.html https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Html.html
- ajmurmann 4y ago
  I haven't written Elixir in years, but Elixir with Phoenix was a quite similar experience to writing a CRUD app in RoR.
- jcpst 4y ago
  Really! The flagship web framework for Elixir, “Phoenix” is pretty well made https://www.phoenixframework.org/ https://www.phoenixframework.org/
- drewbug01 4y ago
  If given the choice between Rails (Ruby) and Phoenix (Elixir) for a low-traffic CRUD app I might have the same sort of question as you - really? But if the choice is between Elixir and Rust for that same CRUD app, it doesn’t seem strange; Elixir would be a far better choice. I would presume the commenter is more familiar with ecosystems like Elixir, even though it wouldn’t be the most optimal choice. But certainly more optimal than Rust in that case.
- cjglo 4y ago
  Elixir offers a lot of the great protections of rust. If you haven’t tried it, I 100% recommend.

npigrounet 4y ago

alexfromapex 4y ago

I think for most companies, using Rust for security and performance critical areas is best. For other things, Rust can run Python code via FFI so no need to take the productivity hit unnecessarily.

cardanome 4y ago

Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with automatic garbage collection for your project, do that. Always. If not, sure, Rust or whatever else language is in that space can be a good choice for embedded development or game dev or whatever. That should be common sense. No need for an article. I hope for the sake of Rust that the hype around it will die soon so that it can become a pragmatic choice for certain projects.

vbezhenar 4y ago
IMO if you would forget about borrow checker, Rust is awesome language by itself. I'm not sure if it's even possible, but I think that if GC were introduced to Rust as an optional part, it would make Rust suitable for CRUD apps. Like all low-level libraries are written with borrow checker and you can write your code with borrow-checker or GC, your choice. So you'll still get superior performance compared to any other GC languages, because your standard library is incredibly fast. And your code will use GC because your code does not matter from performance PoV. And if some function matters - you use borrow checker in that function, so it's fast. Also green threads might be a good addition. It seems that modern computing reinvents it all over again. Golang, Java. Async/await is hard, people want to write blocking code and get good scalability at the same time. We need a silver bullet programming language. Period. Suitable to write CRUD and MCU firmware at the same time. Until this silver bullet is not found, we will reinvent new languages.
- lolinder 4y ago
  This is the kind of attitude that will send Rust the way of C++. Features cost, even optional features. No programming language can or should try to be everything to everyone: to attempt it is to serve no one very well at all, because you split the focus of the language development between too many use cases and you complicate the language so thoroughly that onboarding a new programmer becomes an exercise in re-education about which subsets are acceptable in the given organization. Rust's niche is safely managing memory without a GC. If Rust adds a GC, even an optional one, it will have lost its soul.

throway22342 4y ago

My friends, coworkers, and peers always ask me if they should start using Rust for web apps and I always say no. The web frameworks are still immature, and rapidly changing. I still use Rust for CLI, lambdas, and/or backend web services. Ruby on Rails tickles the cheap and easy CRUD + RAD paradigm pretty well. I don't see Rust doing that anytime soon.

revskill 4y ago

One question though: What does Garbage collection do besides what Rust provide? Ownership and borrow checker.

odo1242 4y ago
Garbage collection deals with a couple (albeit rare) additional cases (e.g reference cycles) while requiring significantly less mental overhead.
darthrupert 4y ago
Frees cognitive resources because you can usually forget that menory management is a thing. When on GC.
- dinosaurdynasty 4y ago
  I usually don't think about memory management in Rust, to be fair. Also GC doesn't remove all resource management... ironically I find most GC-based languages to be more mentally taxing when managing manual resources (file handles, mutex locks, etc).
  - Jensson 4y ago
    Haskell programmers says that Haskell is just fine as well, but in the end there aren't many big programs with complex architecture in these languages. Compilers, interpreters, crud servers etc, those things are very simple architecturally so for them these languages are fine, but for more complex cases these pure languages seems to be too cumbersome.
    - revskill 4y ago
      What i love about Haskell, is it made things simple, not simpler. If you have a program with complex architecture, you're doing wrong somehow. If you can't decomposing the complexity, you will have complexity. I think it's not about programming language, it's about human (and technology).

y7 4y ago

I find it a little odd the author mentions C++ often. I think the use cases for C++ and Rust are pretty interchangeable, and C++ devs would and should probably know about lifetimes anyway. (That said: yeah, don't use Rust for CRUD apps.)

ithkuil 4y ago
Coming from c++ I had no troubles with lifetimes in rust; they were obvious and moat of the time I would have structured the code in the same way anyway. The main problem i encountered (beyond the usual learning curve for stdlib and other common libraries) is all the gotchas and rough edges around async
nicoburns 4y ago
> I think the use cases for C++ and Rust are pretty interchangeable Hmm... in some ways. I feel like one probably shouldn't be using C++ for anything network facing or security critical, whereas Rust is ideal for those situations.

modeless 4y ago

I liked the recent article about writing the Apple Silicon GPU Linux kernel driver in Rust. Now there's a perfect application for Rust if I ever heard one. The service described in this article is a great example of an application that Rust is not the best choice for. When I first heard about Rust I really thought it would be the language to end all languages, but even after just a few days using it I realized that's not the case. Maybe someday someone will come up with that perfect language for everything, but given recent progress in AI I think the more likely long term outcome is that neural nets will start writing all our code for us. I wouldn't start work on a new programming language today given the changes that are clearly coming in the next 20 years or so. At least, not one designed for humans. Maybe there's an opportunity for someone to make the first programming language designed for neural nets to use. Maybe that neural net language would look like Rust. The downside of lower programmer productivity may not matter when the programmer is a neural net. You can just run more neural nets! And neural nets are anything but perfect so they will still benefit from the safety guarantees Rust provides. Rust is the language that I don't want to write, but I want the software I use to be written in it.

ekidd 4y ago

Rust would not be my first choice for a simple CRUD app. There are too many other tools that handle that space well. I have used Rust at a startup, and it worked out extremely well. But we used it for CLI tools (where it shines), and performance critical code, and for specialized, high performance servers.

jll29 4y ago

In many larger projects, there is a need for efficiency and/or low-level work in _some_ corners, _and_ there is also a need for productivity, rapid development in _other_ parts. And everywhere do we want maintainable and readable code that is easy to understand. Selecting more than one language sometimes works, in my experience you can have various microservices that talk to each other, then it doesn't matter what language each is implemented in. However, it isn't optimal to have to master more than one language (most good people do, but we also want to cater to weaker team members; in football, not everyone is a Ronaldo, Pele or Messi either). I don't see why C++ or Rust shouldn't have opt-in garbage collection offered for parts of the codebase where this makes sense (where productivity is worth more than runtime speed), which is probably most part of most projects if we are honest. As some of you know Rust actually _had_ GC in an earlier version, and some readers may complain saying "but C++ can do GC if you want" (of course you can add a Boehm-style GC in your project). But what I'm referring to is that there should be a "batteries included" GC-enabled part of systems programming languages by default (as a technical and cultural preferred setting), unless you mark up a library/crate/class as performance-relevant. This could be done with a mechanism similar to marking up "unsafe", e.g. "uncritical" (= runtime matters less in this section compared to productivity). Then strings and other objects could be garbage-collected and programmers could focus on solving the actual problem instead of managing memory. Critical sections could be marked as such, and there'd be the much-coveted "zero overhead" abstractions for these. The advantage is you would not need to stay up to date in two languages, and you could avoid FFI-type integration, which tends to be brittle (JNI? shudder!). An entirely separate point is the availability of programmers that master a language. I totally agree with the poster that you should use a mainstream language to avoid being hit by a talent shortage.

stephc_int13 4y ago

Are we already there in the hype curve? The classic silver-bullet story, same old, same old.

ferdowsi 4y ago
I'm glad we're here. More and more organizations are going to have serious buyers regret after being sold a bad bag of goods by all of the Rust hype.

jpgvm 4y ago

Startups spend innovation tokens very poorly. Progamming languages, hosting platforms and non-standard databases aren't ideal places to spend such tokens. For most apps what you want is JVM or .NET, PostgreSQL or MySQL or SQL Server, k8s or vanilla VMs/containers. You almost never want different programming languages to these mature stacks, you might think you do, but you don't. Node.js/Python/Ruby etc all promise a fast start but in reality any perceptible velocity benefit is dead within months, usually before anything of value is shipped. Most of it has to with ecosystems (library quality etc, framework maturity) but those also being the 2 most advanced managed runtimes helps a ton. For databases just standard RDBMS is almost always the way to go, unless you startup is intrinsically a data startup and you know ahead of time you require very special properties you just want one of these. Keep hosting simple. Don't use any fangdangled "serverless" nonsense. It's not worth it, shipping a week or 2 later because you took the time to setup EKS/GKE/AKS will pay off in spades. k8s reputation for complexity isn't warranted and it's essentially standard now and will remain that way. So now you have freed up your innovation tokens you can spend them on solutions to your actual business problems instead of on stuff that will only continue to eat your token budget and often yield negative real returns.

eropple 4y ago
For my money, at least Node and Python have absolutely reached the point where they can provide self-feeding velocity. I quite like the JVM as well--I've written a lot of Java and a lot of Kotlin--but TypeScript and modern, typed Python are very defensible options. I know more about Node than Python, so that's easier for me to talk about, but for my money tools like Fastify have a really excellent ecosystem around getting shit done in ways that don't buy you too much technical debt in the future. Databases, fully agreed. "Use Postgres unless you have a reason not to." When you need a key-value store for caching or whatever...consider Postgres hstore first, and then spin up a Redis only when you need to. Hosting...depends. With my product hat on instead of my infra hat, I think there's real value in managed serverless options. The various Heroku descendants--I work at Render, but I'm friends with the Fly folks and they're great too--can, if you are in a low-devops environment, provide some real benefits. Or, for a more stripped-down option, AWS Fargate/GCP Cloud Run, but to bootstrap that you're going to be doing somewhere between the work necessary between a Heroku++ option and "run a server somewhere and keep it patched".

lumost 4y ago

If you are writing CPP, rust is a godsend. Many pitfalls/code review debates/wtf moments simply don’t happen in the language. There are huge cpp code bases in the wild which need help. However rust string handling is barely a step above c’s, there are a variety of datastructures c engineers dislike simply because of the memory management constraints. Getting 2x better performance than Java is a marginal gain for many environments. I really hope rust takes a bent towards ease of use. Stabilizing a rust gc arena would be hugely impactful, or simply revisiting the string api.

pitaj 4y ago
I've found Rust is also far better than weakly typed and dynamically typed languages as well. > However rust string handling is barely a step above c’s How so? Personally I've found it very good.
- lumost 4y ago
  Having 3 separate string types commonly used across the standard library is a huge friction. For beginners, it’s impossible to write a common program for doing some basic string manipulation without reading 3/4 of the Rust book and waiting through dozens of compilation failures.
  - pitaj 4y ago
    Are the three types you refer to str/String, CStr/CString, and OsStr/OsString? There are trade-offs associated with having multiple string types, but the alternative is worse. It's better to force the developer to handle these things up front than to have bugs down the line. str/String being UTF-8 is great. Is means that the various standard library functions associated with them have well-defined behavior. CStr/CString are necessary for FFI, but I wouldn't really say they're commonly used in std. OsStr/OsString are necessary unless you think the standard library should automatically convert whatever random format the OS uses into UTF-8. Rust's decision to not treat everything like Unix is actually a good thing. > For beginners, it’s impossible to write a common program for doing some basic string manipulation without reading 3/4 of the Rust book and waiting through dozens of compilation failures. Personally, I think the standard library makes it pretty easy to learn how to convert between the types.

voxl 4y ago

> Because we had chosen an “esoteric” programming language for this service, the other engineers in the company who might have otherwise been helpful in building features, debugging production issues, and so forth were largely unable to help because they couldn’t make heads or tails of the Rust codebase. Then they are bad engineers and should be fired. Maybe it's just my general rage at so-called developers being incapable of understanding undergraduate level recursive functions, but the quality of developer is on the floor in my opinion.

ferdowsi 4y ago
Not very convincing when "git gud" is the common response to Rust's exuberance towards needless complexity in use cases that it doesn't fit well in (like CRUD applications)
- 0x457 4y ago
  I don't think it's a "git gut" kind of response. There are some engineers who keep repeating "oh X is so hard, I've never tried myself or even looked at it, but I've heard that it's hard". X could be anything. If you are a software engineer and not a code monkey in a web shop, you should have no problem at least trying to expand your knowledge. I worked with people who're afraid of changing a line in k8s manifest file even after you tell them what and where. There are some languages that look alien to the typical engineer and hard to understand without at least a minor prior knowledge, but Rust isn't one of them.
bigbillheck 4y ago
I agree that it sounds like they're not the sharpest knives in the drawer, but completely disagree on the 'should be fired' part.

distalx 4y ago

Previously: Using Rust at a startup: A cautionary tale – https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007 - 10 Days ago! (332 comments)

oxff 4y ago

The author equates C++, Go, Python, Java as languages. I think there might have been some other things wrong than the language here.

ferdowsi 4y ago
Rust advocates want us to believe that Rust can effectively replace all of the use cases of those languages, so it's totally fair to group them.

Mesopropithecus 4y ago

> [...] most modern, procedural languages (C++, Go, Python, Java, etc.) all very similar in terms of their basic concepts. [...] With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, [...] Maybe an oversight, C++ is misplaced in that list. C++ without knowing about ownership and lifetimes is a recipe for disaster.

dinosaurdynasty 4y ago
Even in the other languages lifetimes/ownership are a useful mental tool for managing manual resources (DB connections, transactions, mutexes, file handles, etc). There's so much code in Go that is documented like "while this object takes a file handle, it does not close it itself even though there is a close function, you will need to close it" that in Rust is just a lifetime annotation.

hardwaregeek 4y ago

One note about hiring: if you want to hire like super experienced, senior developers who can architect your rust codebase and tell you definitively how to write Rust, you’re probably out of luck. There just aren’t that many people. You can get senior developers and you can get developers with Rust experience but the intersection of the two is very sparse. As a result, expect some churn in your codebase. Your team will have to discover and iterate upon best practices. Avoid the impulse to spend too much time code golf refactoring because “oh I can use a proc macro to decrease boilerplate while avoiding the orphan rule and having nice traits!” Rust can definitely nerd snipe you by making you worry about some very small edge case like oh no I’m copying a few too many times. Basically unless you’re pretty damn sure you have product market fit (PMF) and you’re sure that rust offers an appreciable benefit to said PMF, I would not use it.

zozbot234 4y ago
Any senior developer with C/C++ experience will probably be pretty comfortable with Rust and its ecosystem. It's not an overly complicated language.
- loeg 4y ago
  I was very familiar with C before starting to do professional work in Rust, and ran into a similar trap as the grandparent comment describes. Since then I've gained professional experience in C++ as well. Without specific Rust experience, I wholly disagree that "any senior developer with C/C++ experience" will have a good sense of optimal Rust project architecture out of the gate. A reasonably good starting point, sure. But it's a different enough language that you can't just reduce architecture concerns to "it's not overly complicated."
  - zozbot234 4y ago
    > ran into a similar trap as the grandparent comment describes. The only "trap" I've seen referenced wrt. Rust is the concern that coding for agility and flexibility introduces boilerplate. Such as GP's concern about calling .clone() too much instead of worrying about lifetimes. But every language has its unidiomatic parts; it's a benefit of Rust that they chose to make the most thoroughly refactored style look "clean and natural", and the most open to refactoring "hackish and unidiomatic" rather than the reverse (cough, cough Java cough, cough). Describing that as a pitfall is just not very helpful!

lordleft 4y ago

Great article. I love Rust, but I don't associate it with (development) agility, despite the overpromising of Rust advocates. It requires a tremendous amount of the developer (at first).

nindalf 4y ago

This was discussed 10 days ago (287 points, 332 comments) - https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007 dang - scribe.rip is an alternative front end to medium.com. That's why this wasn't caught by the dupe detection.

avinassh 4y ago

Using Rust for CRUD stuff is not a good idea. I would pick Go or Elixir may be. If you are starting a new project, ask yourself: 1. Would I be writing this in C++? Then Rust is a great alternative. 2. Would I be using C? Then may be Rust or Zig would make a good alternatives 3. Would I be writing it in Ruby or Python? Then Go or Elixir can be considered

wyldfire 4y ago

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages ... Some of those “new” ideas are, of course, present in other languages — especially functional ones. With C++, lifetime and ownership are just about as important but unfortunately no one's got your back. You can ignore lifetimes and ownership but you do so at your own peril. And the compiler won't tell you you're doing it wrong because the language wasn't designed for it to do so. If you want a taste of rust's "mindset" (with respect to limitations imposed by some types) without jumping ship to a new language, try C++'s Guidelines Support Library [1]. It introduces some of the same benefits/friction as switching to rust but without a new language. Opting-in to some of these guidelines might be a gentler way to get some of the benefits of Rust. But it comes with a similarly higher bar. [1] https://github.com/microsoft/GSL https://github.com/microsoft/GSL

deleted 4y ago
[deleted]

rvz 4y ago

> With Rust, even after months of working daily in the language, most people on the team never felt fully competent. A number of devs told me they were often embarrassed that it was taking longer than they expected for their features to land and that they were spending so long trying to wrap their heads around Rust. Very unsurprising. Rust is a bad choice to use when building a typical CRUD app especially when you are not making any money. So when I saw this about immature libraries: > Rust, by comparison, has long felt like a work in progress. The docs for a lot of popular libraries are pretty sparse, and one often needs to read the source code of a given library to understand how to use it. This is bad. I just couldn't help but say that someone has finally cut through the hype, and experienced the reality of the immature state of the library ecosystem in Rust rather than pretending that it is fine; especially for a startup which can result in the failure of feature delivery and of itself. This cargo culting of programming languages promised by a fan club or hype squad of any new language needs to stop.

samuel2 4y ago

Would Rust be worth learning for implementing (numerical) optimization algorithms?

mustache_kimono 4y ago

Previously posted with lots of engagement: 11 days ago - https://news.ycombinator.com/item?id=33714007 https://news.ycombinator.com/item?id=33714007 19 hours ago - https://news.ycombinator.com/item?id=33837803 https://news.ycombinator.com/item?id=33837803

rootusrootus 4y ago

The cautionary tale is, no doubt, don't use trendy tech stacks if you want your startup to survive. You need a product, and the correct tech stack is whatever gets you there soonest. If you're wildly successful you might eventually need something better, you can worry about that then, after all your competitors with awesome tech stacks have gone out of business.

deleted 4y ago

[deleted]

bigbillheck 4y ago

> how to grok the often arcane error messages from the compiler This, to me, is a bizarro opinion. Compared to c++, rustc's error messages are (by and large) incredibly helpful and clear, oftentimes showing how the code should have been written.

gregwebs 4y ago

I have been shocked on multiple occasions to see how difficult teams make it to do basic CRUD apps. Go lang is suggested rather than Rust, but the standard way of using Go is lower-level and less productive (unless you care about performance) than the Rails of 10 years ago (and I am not a fan of Rails). Haskell can be a great option here- all the high level benefits of Rust and more in a language with a GC and plenty of good frameworks and libraries for CRUD. Unfortunately its one of the only languages that has a greater learning curve than Rust.

ear7h 4y ago

My devil's advocate take on this article is that they're using Rust as scapegoat to their scaling (team not performance) problems. I use Go at $DAYJOB and we're having similar problems for lead times. OTOH, the novelty of Rust in webdev, means there isn't someone to make a decision like, "we don't need performance, so use threads instead of async and pass everything around in a box". I've sunk plenty of personal time trying to wrangle async on a CRUD app for learning, and I recommend it as an exercise, but I'd avoid async if I was trying to ship something.

sreevisakh 4y ago

Rust has an undeniably steep learning curve which can cause a productivity penalty for beginners. However, there are some statements in this article I simply can't agree with based on personal experience. I'm using Rust to develop a few projects. At this stage, I would go for Rust for general development, irrespective of how useful manual garbage collection is. To put it in context, my other favourite language is Python. > Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages, and there is a pretty steep learning curve, even for experienced programmers. Rust's borrow checker system doesn't exist in isolation. It's designed to avoid problems that can occur with computing and memory model of programming - things like call stack frames (esp constant size), heap memory and other resource management, concurrency paradigms, etc. These are just the tip of low level computing models. There are things like cache coherence that Rust doesn't address directly. These are concepts that programmers must know if they want to do: a) Low level programming b) High performance programming. The problem raised by author may partially belong to the second category. Even if it is not, programmers should probably learn these, because they are likely to face such problems at some point and may gain from that knowledge. There are two ways to learn the borrow checker rules. The first is to start with the rules itself. It's going to appear rather convoluted. The other approach is to understand the machine/memory model that I mentioned above first. Once you do, the rules are going to make much more sense - especially in the context of specific error messages during coding. These days, I'm able to connect every single error message that I see to some potential memory or concurrency problem, even though they are the result of some seemingly convoluted but simple borrow checker rule. > Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below). There were dozens of errors that I made today that were easily understood just by a glance at Rust's error messages. The help messages that accompany these error messages are often the solution that I needed. Even otherwise, the error messages point out potential low-level bugs as I mentioned above - allowing me to make proper corrections. This may just be anecdotal. What is not anecdotal is that the Rust team reworked the error messaging early in the project's life to make it that way. It's generally accepted that Rust's error messaging is top-notch. I find it disrespectful to all those early endeavors to call it arcane. Perhaps it's a good idea to try to learn those error messages. There is an entire index of errors with detailed explanations [1]. > We started having weekly “learn Rust” sessions for the team to help share knowledge and expertise. This was all a significant drain on the team’s productivity and morale as everyone felt the slow rate of development. Perhaps this is the wrong way to approach the problem. The thing that may need learning is type theory. Type theory is often too esoteric with a theoretical mathematical approach. Perhaps we need an introduction to it that encourages people to see a bunch of bits as a storage for data with a particular meaning (the type). Next step would be to how to track types using software (type system) and then extend the idea all the way to include constant-size stack frames, generics, polymorphism and lifetime tracking. > Libraries and documentation are immature Library ecosystem is still growing - especially async programming. But documentation support is a first-class feature of Rust's language ecosystem. I find myself writing documentation much more often in Rust than with other languages. It's also equally easy to browse the documentation of the language, stdlib and other libraries. Sections are marked out clearly and navigation is well thought-out. Every search of a feature or API takes me through half a dozen links to the final target in a matter of minutes, if not less. It's a good investment to learn browsing technique for documentation in any language. > Rust makes roughing out new features very hard Somehow, my experience doesn't match here either. I use the same technique for trying out new features in both Python and Rust. Create a scratch project for each experiment. A single project may take up to a dozen such scratch projects. It's marginally easier in Rust than in Python, mainly because project management is another first-class feature of Rust tooling. But what's really remarkable about Rust compared to most other languages I've encountered is that Rust's discipline gently nudges the scratch project to a proper design. By the end of the scratch project, the experimental code is often in a good enough state to be directly integrated into the main project. It's amazingly friction-less to integrate integrate external code into the main project. I wouldn't blame the author for having a very different experience as mine. But I sure would like to know what makes Rust 'click' for some, but remain a tough nut to crack for others. [1] https://doc.rust-lang.org/error_codes/error-index.html https://doc.rust-lang.org/error_codes/error-index.html