8 ms·

Rust advocacy at a medium-sized startup

73 points by lukastyrychtr 4y ago

phendrenad2 4y ago
Not a fan of Rust (or Go,.. or Python), but it's interesting to read people's experiences with them.
- chrisshroba 4y ago
  Just curious, what language(s) do you prefer?
mistrial9 4y ago
great to read - enthusiastic positivity, "no enemies" approach, educational and participatory results self-organized.. but the ending? Is this a "no good deeds go unpunished" story in sheep's clothing? perhaps young engineers are being conditioned to sudden and unexplained unemployment as if that is normal ? that's a different kind of sheep. Are there grownups in this story ? just kind of awful at the very end after all that positive detail.
- lmeyerov 4y ago
  Agreed. I think the author took the wrong lesson, while you are sensing the real deal. There was a lot of rust advocacy time that ultimately had little clear business value -- a couple of bugs that may have been prevented, and rust may have cost different problems instead. If you're getting paid 6-7 figures and supposed to supporting 2-10X that in revenue, that's a real responsibility. When an infra investment makes sense (lang, DB, ...), especially for 40+ engineers and who knows how big a workload, the multiplier should make the benefit clear. GPU computing speedups, k8s for easier elasticity, something, and ideally obvious like some sort of 10X. We certainly have quite a queue internally like that ("platform X unlocks property Y that has lift Z"), as do many. Conversely, with time wasted, that's a person distracting themselves and everyone else. Getting aligned with the business isn't about pushing a language that might help but identifying what is the most thing you can do to solve the company's/customer's problems, and going for that one.
- quelleconnerie 4y ago
  The senior engineers should have been more honest ("screw you and your pet language, we won't be using this garbage here") instead of getting the author to run various useless side quests. This is the company he is talking about: https://www.hologram.io/blog/why-we-dont-hate-php https://www.hologram.io/blog/why-we-dont-hate-php They love PHP and Python. Good for them, I don't like those languages but why would I get a job there and try to get them to use a language with a pretty much completely opposite philosophy? It would be like getting a job at a vegan restaurant and suggest they should have wagyu beef on their menu because it's so tasty and everyone loves it.
  - xrd 4y ago
    This. Often companies that are in need of more bodies will hire people and tell them they can certainly help change the culture and help adopt a new language. Everyone there wants to believe it but it'll probably never happen. There is probably a fun math problem here: count up the number of engineers, sum up their time in the language. If the average is X or more, they will never switch away from the language they've earned their keep in. It's too hard once you get past a point. Maybe that is already a rule. But I'm sure it is stronger for certain languages, probably PHP especially.
  - srer 4y ago
    I largely agree with you, that rather than introducing Rust into your workplace it's easier to change workplaces. I currently work in a Go shop. Why Go? Did it win some business value delivering contest? I don't think so, it's just the initial team lead liked Go the most of the languages they knew and made everyone else learn it. If you read my comment history you'll see I think Go is a mediocre choice. But, it's here to stay in this company and it doesn't matter what new language comes along it won't have the inertia or acceptance of the status quo language. The expected improvement has to be large enough to overcome the associated costs to sell the business case. This idea of the status quo being somewhat arbitrary, and difficult to change, applies to more than just languages. It applies to everything else, your architecture, your work processes, your culture. A blueprint is set early on by some founding members, and perpetuated potentially forever. In this world, rather than trying to change a company you change employers. Innovation is change, and to achieve that the individual changes, but leaves their company to remain the same. Personally, I seek to improve in what I do, to innovate. And I think what we do can be done better and that the tools and systems in-place play a part in that. But will I introduce them at my workplace? Perhaps not, I think I'll find a new job, and both my old and next company can pay the rather high costs of someone leaving and someone joining. This makes me a little sad, since I like my company and leaving would be a significant amount of institutional knowledge walking out the door.
Animats 4y ago
Enthusiasm can be a problem. You don't really need Rust for server-side Web stuff. That's what Go was designed for. Go comes with well-exercised libraries for most of the things people do web server side. As I've mentioned before, I'm writing a metaverse client in Rust. Now that's something for which Rust is worth the trouble. You need concurrency. A lot of tightly interlocked concurrency. If you want a large high-detail virtual world, you need to keep a half dozen CPUs, a multi-threadable GPU, and the network all quite busy. There's a huge payoff in being able to do all that threading without spending time in a debugger. I've opened a debugger once in the last two years, and that was for a bug in someone else's "unsafe" code. The price of using Rust is that you hit bleeding edge problems. I just finished writing a basic internationalization package to translate menu items and such. That should be unnecessary at this late date. But it turns out that the basic "internationalization" crate is fundamentally flawed, and even its creator now says so. The crate most commonly used, "fluent", is not suitable for use with the immediate-mode GUI used for games, "egui", because you need lookup memoization for strings retrieved on every frame. A lot of time is wasted on side issues like this. Many widely used Rust crates are still at version 0.x.x, and not really stable yet. The language and core tools are pretty solid now, but the crates are all volunteer and not well-curated. The graphics systems I'm using, Rend3 and WGPU, are under heavy development, and not yet ready for prime time. I'm in regular contact with those dev groups. There's not much off the shelf code for metaverses yet. Unity and Unreal Engine don't support metaverses yet, where the content comes from hundreds or thousands of people not working under common management. It's not like picking one of a dozen widely used payment rail systems. So you're going to have to do some serious development from a cold start. Rust is good for that. For routine web development with short deadlines, Rust may be overkill or unsuitable.
- brundolf 4y ago
  Sometimes I think about how many weeks I’ve wasted debugging my local python environment, managing venvs and various build/package management/testing tools, manually editing my shell’s rc file to approximate a sane dev flow, fixing broken dependencies, re-fixing them whenever I pull changes from one of a dozen repos, etc. I can’t help wonder if Rust would be a net productivity gain solely based on that stuff. And then, less dramatically but still significant, there’s the runtime errors and all the hand-written JSON (de-)serialization code. It adds up.
reitzensteinm 4y ago
> I didn’t want to talk about Go because it’s simply not what I was passionate about. I also didn’t want to put down Go users in the company. I just wanted to extol the benefits of Rust and see if anyone was interested in trying it out. > Yet, it made me sad to look up articles on the language just to, in effect, bash it. I’m not generally in the business of discouraging people from coding, regardless of what their favorite programming language was. While this level of self reflection shows a lot of maturity, if your judgement is clouded by excitement and you're searching for evidence to support your plan, this is _exactly the wrong_ time to attempt to shift your organization's direction. You're on tilt. Worse, others are likely to recognize that you're on tilt, and discount otherwise rational arguments that you're making. It won't be clear to you why you're not making progress. I've introduced Rust to an organization for a specific project, and it wasn't a decision taken lightly. It fit the problem domain well. I'll likely advocate against Rust for the next greenfield project that's on the horizon - as it's not nearly as much of a fit. These are tools and there is no silver bullet. This doesn't apply (as other commenters have said) to quitting and getting a job elsewhere that already uses Rust. Indulge in your passion without engaging in a sisyphean battle that'll burn you out and harm the business.
- fakedang 4y ago
  As a sort-of-dev-outsider in a firm that's slowly moving into Rust, I would like to know what kinds of projects is Rust suitable for, and the reasons why you might advocate against it.
  - code_biologist 4y ago
    In the absence of Rust, would C or C++ be top contenders for a given project? Then Rust might be a good fit. If the contender language is Go, think carefully before using Rust. If the contender language is Python, think very carefully before using Rust.
    - fakedang 4y ago
      Lol, that's pretty much the heuristic I have been going by. Rust to replace C++ and Julia to potentially replace Python as it matures.
manigandham 4y ago
> "The issue of whether or not to use Go instead of Rust seems inevitable in any organization." It is not inevitable; it barely ever happens. This single line shows the extreme bias of the author. Rust is new and exciting, but it's not the best at everything nor nearly as productive as Java or Go at general webapps. Engineering needs to serve the business and get things done, not vacillate on language decisions. This was a rather big waste of effort and I blame leadership for allowing it to continue as far as it did.
jeroenhd 4y ago
> The issue of whether or not to use Go instead of Rust seems inevitable in any organization. This assumes Go is even evaluated as an option, let alone Rust. There are many programming languages any organisation can pick from. The right choice is usually "the language most programmers are most productive in". I don't think "let's teach an entire team this novel programming language" is something you'll see in many companies. It makes sense for new companies, startups, and divisions, I suppose. A company with 200 employees is hardly still a startup, though, that's just a regular old company, even if it relies solely on new investors not to go bankrupt.
- skohan 4y ago
  > The right choice is usually "the language most programmers are most productive in". As someone who picked the primary BE programming language for a software org in the last year, our considerations were: 1. What's a language that's reasonably easy to hire for 2. What's the language where we feel that the community attracts high quality SWE's 3. What's the language that's easy to teach and easy to pick up, so that if we find a quality SWE who's not experienced, we can still consider them as part of our hiring pool 4. What's the language that's productive, easy to read and easy to maintain so that if we have turnover it's reasonably easy for someone new to pick up where others have left off For us, Go scored very highly on all of these metrics, and imo it's almost purpose built to avoid the types of problems a software organization can typically run into. That's at the tradeoff of not being the most expressive or conceptually exciting programming language out there. Imo Rust is at the opposite end of the spectrum. I have a lot of fun programming with Rust on hobby projects, but to be honest it would be hard to recommend it to an organization as a primary programming language unless the problem domain really can benefit from Rust's value prop in terms of performance, safety, and low-level control. Because you're paying a lot for it in terms of steep learning curve, potentially complex and difficult to maintain codebase, and small talent pool.
  - echelon 4y ago
    > Because you're paying a lot for it in terms of steep learning curve It's a hill at this point and people are calling it Everest. There are a few incredibly uncommon things that are still difficult (the ones you see "Rust is hard!" blog posts about), but you're most likely never going to hit those corners. Especially if you're writing CRUD web apps with a few threads here and there. That path is boring and vanilla at this point.
jollybean 4y ago
I'm a bit perplexed because I can't fathom where someone is going to substitute Rust for PHP or Python. I mean, you 'could' ... but that just doesn't feel right. High performance, embedded systems, or things that have some kind of criticality with respect to fail cases, and must be fast, sure.
- 42e6e8c8-f7b8-4 4y ago
  Rust is trivial speed. Blinding speed, out of the box.
  - cyber_kinetist 4y ago
    No, Rust can be still slow (slower than well-optimized garbage-collected languages) if you perform memory allocations on the heap all over the place, ignore cache coherency, use #[derive(Clone, Copy)] everywhere, and use Rc<T> and Arc<T> to solve all your typical ownership issues (plus making the wrong algorithmic/data structure decisions). Language is only a tool, you don't automatically write fast software by using a "better" language. That said, I think the design decisions of the Rust borrow checker leads most developers either to write borrow-checker-agnostic code by using indices and Vec<T> instead (see https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html), or go ham with Rc<T> and Arc<T> until the language basically becomes similar to (but slower than) garbage-collected languages like Go. The former leads to performant code but makes you question why you are using Rust in the first place, and the latter leads to slow unwieldy code and also makes you question why you are using Rust in the first place.
    - 42e6e8c8-f7b8-4 4y ago
      Yes, all languages we're using are Turing complete. Yes, you can fashion a foot-gun out of every language. Also, some languages make speed easily accessible.
  - jollybean 4y ago
    Rust is in the same 'speed zone' as c and c++ generally, yes, much faster than python, but who cares? Are you delivering your groceries in a Ferrari, or a Truck?
anonyfox 4y ago
As someone quite fluent in Rust (and several other languages) I love it in general… but I think it’s not a good option for average teams, especially if you don’t need the last bit of performance. You could get most benefits of it by using Go in terms of tooling/speed, or something with a great type system if you‘re after the correctness checking compiler. Personally I didn’t find a language yet that checks all the boxes I have, there is always some tradeoff involved that keeps bugging me. Recently stumbled upon OCaml and for the first time in years it looks like I found what I was looking for
- kaba0 4y ago
  > You could get most benefits of it by using Go in terms of tooling/speed, or something with a great type system if you‘re after the correctness checking compiler. Or the much more mainstream Java/C# choice with much bigger ecosystems.
jokethrowaway 4y ago
I tried this approach a number of times some decade ago (about other languages / functional programming) and it didn't payoff. Countless of presentations, workshops, discussions and nothing. The business didn't care about nothing but hiring basic js developers and throwing them at the issue. Nowadays I don't waste my energy trying to change clients, I'm just collecting a paycheck and going along with whatever bs the leaders think is good. My stress levels and happiness levels are way better. If a company has leaders who are open to change they'll hire you with that in mind, if not, they can just keep rotting with the other dinosaurs.
ZephyrBlu 4y ago
I think the argument presented for Rust over Go is extremely weak, and I say this as someone who is not interested in Go and likes Rust. If the main value proposition of Rust is bug fixes, error handling and nice-to-have (?) platform support it sounds like you're really scraping the bottom of the barrel. Unless there is an extremely obvious and large benefit to using Rust over Go I would not do it. I have not written any Go, but Rust seems to have a far steeper learning curve and there would also likely be high organizational costs associated with transitioning from Go to Rust (E.g. coordinating the transition, ramp up time, hiring, etc). When Go is working fine and you only have 40 engineers this sounds like a massive distraction from building the product. I wonder if the author considered the possible negative impact of this as well as the positive.
- deleted 4y ago
  [deleted]
- yobbo 4y ago
  The benefits of using Rust come as a consequence of a team that learns and chooses Rust on its own. It is likely a more committed team, which would produced better code in any language. Migrating a team of PHP, Javascript and Go programmers to Rust for no technical reason seems just hopeless. It's putting the cart before the horse.
  - ecshafer 4y ago
    I think its Paul Graham that made the argument to have a "weird" language as your startup language for this reason. Sure there are a billion C#, Java or Javascript developers out there. But if you make your start up in obscure lang you'll get a lot of high minded hard working engineers that will go there and build something awesome because its interesting.
    - Patrol8394 4y ago
      The flip side is that your business now depends on those few high skilled engineers. Much harder to replace. I would probably go for a main stream programming language / platform: Java / JavaScript / Go / Ruby / Python
grose 4y ago
I've been writing Go professionally for about 10 years now. I don't really buy your arguments against Go. Error handling is optional only if you explicitly ignore error results, and you can have the linter yell at you for that. The Go ecosystem is much larger and more mature, with many production-ready libraries available, and success stories everywhere you look. This article is a great illustration of how Rust just makes certain things hard, for better or worse: https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-of-mainstream-programming.html https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-... That being said, I think Rust is cool so I'll give you a hint. Go has a kryptonite: binary size. This didn't matter until recently when WASM runtimes became the new hotness. It is very very difficult to deploy Go on e.g. Cloudflare Workers. Even with Tinygo, it's a struggle getting your binary less than 1MB. Some features that make Go ergonomic like reflection (encoding/json package is a good example) ruin "tree-shaking" and bloat the binary. If you're dead-set on using Rust, I'd try framing it in terms of edge computing. Rust is absolutely in a position to become the best non-JS language to use for these kind of 'workers' environments. And they have a lot of benefits: super fast, super cheap, effortless deploys, etc. so it's totally possible to make an argument for them. "Rust is the only compiled language viable in these environments"[1] is certainly a compelling position. [1]. Hyperbole, I'm sure there's good progress towards getting others to work. For example, I'm currently working on adding Prolog support for Cloudflare Workers :-)
- synergy20 4y ago
  recently started learning wasm as a c++ developer, yes go binary is large for edge computing(workers) and wasm runtime is a good fit there, what about c++ vs rust for this use case? many wasm subjects are referring rust as _the_ language, but I feel modern c++ can do it as well if not better on all aspects(maturity, size, speed, even safety).
  - grose 4y ago
    I think modern C++ could be perfectly viable as well. Maybe https://github.com/cloudflare/workers-wasi https://github.com/cloudflare/workers-wasi would be a good starting point? I'm not too knowledgeable on the subject. Exciting times though, I think WASM might be the great equalizer.
devit 4y ago
Rust and Go are different classes of language, where Rust is a non-GC memory-safe language, and Go is a statically typed GC language. In Go's language class of statically typed GC languages, Go is much worse than the best languages, which are Kotlin and C# (Go lets you forget to write error handling, had no generics until recently, uses duck typed interfaces (!)). In general, Go's inferiority can be traced to its root cause, which is the Google Go designers having severe Dunning-Kruger syndrome because they think they are good because they invented C/Unix and work at Google and don't realize they have no clue about programming languages in general and were only successful because the limited hardware at the time didn't allow sophisticated programming languages and thus allowed a terrible language like C to succeed. As a language class, non-GC memory safe languages are far better than statically typed GC languages since they don't have the overhead of a GC and can guarantee the correctness of concurrent programs since they are data-race free (in Go-like language two threads can share the same data with no checks whatsoever resulting in arbitrary racy behavior), can make other guarantees enabled by the linear type system and use composition instead of implementation inheritance. So in general you should always use Rust unless existing framework or libraries for other languages make solving the problem much easier and the app code is small enough that the extra problems in using a subpar language aren't too bad (e.g. you probably want to use bash for system administration, Python for simple deep learning projects, Kotlin for simple Android apps, Swift for simple iOS apps, TypeScript for simple web frontends, etc.). However, if you plan to write a lot of code, then just using the best language, i.e. Rust, is probably better since the time to write or correct dependencies will be small compared to the sheer amount of code you are planning to write for the main software. If you are willing to give up good performance and a large library ecosystem for correctness, then dependently typed languages like Idris are also an option.
- Strum355 4y ago
  You lost me at saying Go let's you forget to handle errors, when its pretty objectively more vocal at having you not handle them than Kotlin with its lack of checked exceptions, having just said Kotlin (and C#) are better than Go in its class. And I say this as a big fan of both Go, Kotlin and Rust.
- machinekob 4y ago
dxuh 4y ago
> Doug and I were counseled to know our “opponent” (Go) inside and out > Rust Evangelism Strike Force I know these are in quotes or meant as a joke, but it still is very off-putting to me. It's a team of 40 engineers and they have different subgroups of people coordinating essentially political efforts to advocate for programming languages. I would not like to work at a company like that. What is with Rust and this uniquely fanatical evangelism? For me the biggest reason for not using it is the rabidness of its advocates. While they state technical reasons it seems the reasons are not technical in nature, which leads to my gut reaction of not taking them seriously.
- mayormcheeseman 4y ago
  As someone relatively new to both Go and Rust, I definitely feel the same way. It seems like Rust fans are more passively-aggressively pushing Rust much more than Go devs. Also, it seems like a lot of them talk down on Go/Go devs for the usual reasons that most people point out. For example, Go's popularity is only because of Google. I'm sure that has to do with it, but I don't think many companies are going to be putting their bottom line at risk by using a language just because it may have come from Google. It has to actually do its job and do it well. In that case, the proof is in the pudding. Again, as more of an outsider to these languages, Go seems to be doing pretty well for a relatively young language and it's already taking over the cloud space.
- deleted 4y ago
  [deleted]

73 points by lukastyrychtr 4y ago

phendrenad2 4y ago

Not a fan of Rust (or Go,.. or Python), but it's interesting to read people's experiences with them.

chrisshroba 4y ago
Just curious, what language(s) do you prefer?

mistrial9 4y ago

great to read - enthusiastic positivity, "no enemies" approach, educational and participatory results self-organized.. but the ending? Is this a "no good deeds go unpunished" story in sheep's clothing? perhaps young engineers are being conditioned to sudden and unexplained unemployment as if that is normal ? that's a different kind of sheep. Are there grownups in this story ? just kind of awful at the very end after all that positive detail.

lmeyerov 4y ago
Agreed. I think the author took the wrong lesson, while you are sensing the real deal. There was a lot of rust advocacy time that ultimately had little clear business value -- a couple of bugs that may have been prevented, and rust may have cost different problems instead. If you're getting paid 6-7 figures and supposed to supporting 2-10X that in revenue, that's a real responsibility. When an infra investment makes sense (lang, DB, ...), especially for 40+ engineers and who knows how big a workload, the multiplier should make the benefit clear. GPU computing speedups, k8s for easier elasticity, something, and ideally obvious like some sort of 10X. We certainly have quite a queue internally like that ("platform X unlocks property Y that has lift Z"), as do many. Conversely, with time wasted, that's a person distracting themselves and everyone else. Getting aligned with the business isn't about pushing a language that might help but identifying what is the most thing you can do to solve the company's/customer's problems, and going for that one.
quelleconnerie 4y ago
The senior engineers should have been more honest ("screw you and your pet language, we won't be using this garbage here") instead of getting the author to run various useless side quests. This is the company he is talking about: https://www.hologram.io/blog/why-we-dont-hate-php https://www.hologram.io/blog/why-we-dont-hate-php They love PHP and Python. Good for them, I don't like those languages but why would I get a job there and try to get them to use a language with a pretty much completely opposite philosophy? It would be like getting a job at a vegan restaurant and suggest they should have wagyu beef on their menu because it's so tasty and everyone loves it.
- xrd 4y ago
  This. Often companies that are in need of more bodies will hire people and tell them they can certainly help change the culture and help adopt a new language. Everyone there wants to believe it but it'll probably never happen. There is probably a fun math problem here: count up the number of engineers, sum up their time in the language. If the average is X or more, they will never switch away from the language they've earned their keep in. It's too hard once you get past a point. Maybe that is already a rule. But I'm sure it is stronger for certain languages, probably PHP especially.
- srer 4y ago
  I largely agree with you, that rather than introducing Rust into your workplace it's easier to change workplaces. I currently work in a Go shop. Why Go? Did it win some business value delivering contest? I don't think so, it's just the initial team lead liked Go the most of the languages they knew and made everyone else learn it. If you read my comment history you'll see I think Go is a mediocre choice. But, it's here to stay in this company and it doesn't matter what new language comes along it won't have the inertia or acceptance of the status quo language. The expected improvement has to be large enough to overcome the associated costs to sell the business case. This idea of the status quo being somewhat arbitrary, and difficult to change, applies to more than just languages. It applies to everything else, your architecture, your work processes, your culture. A blueprint is set early on by some founding members, and perpetuated potentially forever. In this world, rather than trying to change a company you change employers. Innovation is change, and to achieve that the individual changes, but leaves their company to remain the same. Personally, I seek to improve in what I do, to innovate. And I think what we do can be done better and that the tools and systems in-place play a part in that. But will I introduce them at my workplace? Perhaps not, I think I'll find a new job, and both my old and next company can pay the rather high costs of someone leaving and someone joining. This makes me a little sad, since I like my company and leaving would be a significant amount of institutional knowledge walking out the door.

Animats 4y ago

Enthusiasm can be a problem. You don't really need Rust for server-side Web stuff. That's what Go was designed for. Go comes with well-exercised libraries for most of the things people do web server side. As I've mentioned before, I'm writing a metaverse client in Rust. Now that's something for which Rust is worth the trouble. You need concurrency. A lot of tightly interlocked concurrency. If you want a large high-detail virtual world, you need to keep a half dozen CPUs, a multi-threadable GPU, and the network all quite busy. There's a huge payoff in being able to do all that threading without spending time in a debugger. I've opened a debugger once in the last two years, and that was for a bug in someone else's "unsafe" code. The price of using Rust is that you hit bleeding edge problems. I just finished writing a basic internationalization package to translate menu items and such. That should be unnecessary at this late date. But it turns out that the basic "internationalization" crate is fundamentally flawed, and even its creator now says so. The crate most commonly used, "fluent", is not suitable for use with the immediate-mode GUI used for games, "egui", because you need lookup memoization for strings retrieved on every frame. A lot of time is wasted on side issues like this. Many widely used Rust crates are still at version 0.x.x, and not really stable yet. The language and core tools are pretty solid now, but the crates are all volunteer and not well-curated. The graphics systems I'm using, Rend3 and WGPU, are under heavy development, and not yet ready for prime time. I'm in regular contact with those dev groups. There's not much off the shelf code for metaverses yet. Unity and Unreal Engine don't support metaverses yet, where the content comes from hundreds or thousands of people not working under common management. It's not like picking one of a dozen widely used payment rail systems. So you're going to have to do some serious development from a cold start. Rust is good for that. For routine web development with short deadlines, Rust may be overkill or unsuitable.

brundolf 4y ago
Sometimes I think about how many weeks I’ve wasted debugging my local python environment, managing venvs and various build/package management/testing tools, manually editing my shell’s rc file to approximate a sane dev flow, fixing broken dependencies, re-fixing them whenever I pull changes from one of a dozen repos, etc. I can’t help wonder if Rust would be a net productivity gain solely based on that stuff. And then, less dramatically but still significant, there’s the runtime errors and all the hand-written JSON (de-)serialization code. It adds up.

reitzensteinm 4y ago

> I didn’t want to talk about Go because it’s simply not what I was passionate about. I also didn’t want to put down Go users in the company. I just wanted to extol the benefits of Rust and see if anyone was interested in trying it out. > Yet, it made me sad to look up articles on the language just to, in effect, bash it. I’m not generally in the business of discouraging people from coding, regardless of what their favorite programming language was. While this level of self reflection shows a lot of maturity, if your judgement is clouded by excitement and you're searching for evidence to support your plan, this is _exactly the wrong_ time to attempt to shift your organization's direction. You're on tilt. Worse, others are likely to recognize that you're on tilt, and discount otherwise rational arguments that you're making. It won't be clear to you why you're not making progress. I've introduced Rust to an organization for a specific project, and it wasn't a decision taken lightly. It fit the problem domain well. I'll likely advocate against Rust for the next greenfield project that's on the horizon - as it's not nearly as much of a fit. These are tools and there is no silver bullet. This doesn't apply (as other commenters have said) to quitting and getting a job elsewhere that already uses Rust. Indulge in your passion without engaging in a sisyphean battle that'll burn you out and harm the business.

fakedang 4y ago
As a sort-of-dev-outsider in a firm that's slowly moving into Rust, I would like to know what kinds of projects is Rust suitable for, and the reasons why you might advocate against it.
- code_biologist 4y ago
  In the absence of Rust, would C or C++ be top contenders for a given project? Then Rust might be a good fit. If the contender language is Go, think carefully before using Rust. If the contender language is Python, think very carefully before using Rust.
  - fakedang 4y ago
    Lol, that's pretty much the heuristic I have been going by. Rust to replace C++ and Julia to potentially replace Python as it matures.

manigandham 4y ago

> "The issue of whether or not to use Go instead of Rust seems inevitable in any organization." It is not inevitable; it barely ever happens. This single line shows the extreme bias of the author. Rust is new and exciting, but it's not the best at everything nor nearly as productive as Java or Go at general webapps. Engineering needs to serve the business and get things done, not vacillate on language decisions. This was a rather big waste of effort and I blame leadership for allowing it to continue as far as it did.

jeroenhd 4y ago

> The issue of whether or not to use Go instead of Rust seems inevitable in any organization. This assumes Go is even evaluated as an option, let alone Rust. There are many programming languages any organisation can pick from. The right choice is usually "the language most programmers are most productive in". I don't think "let's teach an entire team this novel programming language" is something you'll see in many companies. It makes sense for new companies, startups, and divisions, I suppose. A company with 200 employees is hardly still a startup, though, that's just a regular old company, even if it relies solely on new investors not to go bankrupt.

skohan 4y ago
> The right choice is usually "the language most programmers are most productive in". As someone who picked the primary BE programming language for a software org in the last year, our considerations were: 1. What's a language that's reasonably easy to hire for 2. What's the language where we feel that the community attracts high quality SWE's 3. What's the language that's easy to teach and easy to pick up, so that if we find a quality SWE who's not experienced, we can still consider them as part of our hiring pool 4. What's the language that's productive, easy to read and easy to maintain so that if we have turnover it's reasonably easy for someone new to pick up where others have left off For us, Go scored very highly on all of these metrics, and imo it's almost purpose built to avoid the types of problems a software organization can typically run into. That's at the tradeoff of not being the most expressive or conceptually exciting programming language out there. Imo Rust is at the opposite end of the spectrum. I have a lot of fun programming with Rust on hobby projects, but to be honest it would be hard to recommend it to an organization as a primary programming language unless the problem domain really can benefit from Rust's value prop in terms of performance, safety, and low-level control. Because you're paying a lot for it in terms of steep learning curve, potentially complex and difficult to maintain codebase, and small talent pool.
- echelon 4y ago
  > Because you're paying a lot for it in terms of steep learning curve It's a hill at this point and people are calling it Everest. There are a few incredibly uncommon things that are still difficult (the ones you see "Rust is hard!" blog posts about), but you're most likely never going to hit those corners. Especially if you're writing CRUD web apps with a few threads here and there. That path is boring and vanilla at this point.

jollybean 4y ago

I'm a bit perplexed because I can't fathom where someone is going to substitute Rust for PHP or Python. I mean, you 'could' ... but that just doesn't feel right. High performance, embedded systems, or things that have some kind of criticality with respect to fail cases, and must be fast, sure.

42e6e8c8-f7b8-4 4y ago
Rust is trivial speed. Blinding speed, out of the box.
- cyber_kinetist 4y ago
  No, Rust can be still slow (slower than well-optimized garbage-collected languages) if you perform memory allocations on the heap all over the place, ignore cache coherency, use #[derive(Clone, Copy)] everywhere, and use Rc<T> and Arc<T> to solve all your typical ownership issues (plus making the wrong algorithmic/data structure decisions). Language is only a tool, you don't automatically write fast software by using a "better" language. That said, I think the design decisions of the Rust borrow checker leads most developers either to write borrow-checker-agnostic code by using indices and Vec<T> instead (see https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html), or go ham with Rc<T> and Arc<T> until the language basically becomes similar to (but slower than) garbage-collected languages like Go. The former leads to performant code but makes you question why you are using Rust in the first place, and the latter leads to slow unwieldy code and also makes you question why you are using Rust in the first place.
  - 42e6e8c8-f7b8-4 4y ago
    Yes, all languages we're using are Turing complete. Yes, you can fashion a foot-gun out of every language. Also, some languages make speed easily accessible.
- jollybean 4y ago
  Rust is in the same 'speed zone' as c and c++ generally, yes, much faster than python, but who cares? Are you delivering your groceries in a Ferrari, or a Truck?

anonyfox 4y ago

As someone quite fluent in Rust (and several other languages) I love it in general… but I think it’s not a good option for average teams, especially if you don’t need the last bit of performance. You could get most benefits of it by using Go in terms of tooling/speed, or something with a great type system if you‘re after the correctness checking compiler. Personally I didn’t find a language yet that checks all the boxes I have, there is always some tradeoff involved that keeps bugging me. Recently stumbled upon OCaml and for the first time in years it looks like I found what I was looking for

kaba0 4y ago
> You could get most benefits of it by using Go in terms of tooling/speed, or something with a great type system if you‘re after the correctness checking compiler. Or the much more mainstream Java/C# choice with much bigger ecosystems.

jokethrowaway 4y ago

I tried this approach a number of times some decade ago (about other languages / functional programming) and it didn't payoff. Countless of presentations, workshops, discussions and nothing. The business didn't care about nothing but hiring basic js developers and throwing them at the issue. Nowadays I don't waste my energy trying to change clients, I'm just collecting a paycheck and going along with whatever bs the leaders think is good. My stress levels and happiness levels are way better. If a company has leaders who are open to change they'll hire you with that in mind, if not, they can just keep rotting with the other dinosaurs.

ZephyrBlu 4y ago

I think the argument presented for Rust over Go is extremely weak, and I say this as someone who is not interested in Go and likes Rust. If the main value proposition of Rust is bug fixes, error handling and nice-to-have (?) platform support it sounds like you're really scraping the bottom of the barrel. Unless there is an extremely obvious and large benefit to using Rust over Go I would not do it. I have not written any Go, but Rust seems to have a far steeper learning curve and there would also likely be high organizational costs associated with transitioning from Go to Rust (E.g. coordinating the transition, ramp up time, hiring, etc). When Go is working fine and you only have 40 engineers this sounds like a massive distraction from building the product. I wonder if the author considered the possible negative impact of this as well as the positive.

deleted 4y ago
[deleted]
yobbo 4y ago
The benefits of using Rust come as a consequence of a team that learns and chooses Rust on its own. It is likely a more committed team, which would produced better code in any language. Migrating a team of PHP, Javascript and Go programmers to Rust for no technical reason seems just hopeless. It's putting the cart before the horse.
- ecshafer 4y ago
  I think its Paul Graham that made the argument to have a "weird" language as your startup language for this reason. Sure there are a billion C#, Java or Javascript developers out there. But if you make your start up in obscure lang you'll get a lot of high minded hard working engineers that will go there and build something awesome because its interesting.
  - Patrol8394 4y ago
    The flip side is that your business now depends on those few high skilled engineers. Much harder to replace. I would probably go for a main stream programming language / platform: Java / JavaScript / Go / Ruby / Python

grose 4y ago

I've been writing Go professionally for about 10 years now. I don't really buy your arguments against Go. Error handling is optional only if you explicitly ignore error results, and you can have the linter yell at you for that. The Go ecosystem is much larger and more mature, with many production-ready libraries available, and success stories everywhere you look. This article is a great illustration of how Rust just makes certain things hard, for better or worse: https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-of-mainstream-programming.html https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-... That being said, I think Rust is cool so I'll give you a hint. Go has a kryptonite: binary size. This didn't matter until recently when WASM runtimes became the new hotness. It is very very difficult to deploy Go on e.g. Cloudflare Workers. Even with Tinygo, it's a struggle getting your binary less than 1MB. Some features that make Go ergonomic like reflection (encoding/json package is a good example) ruin "tree-shaking" and bloat the binary. If you're dead-set on using Rust, I'd try framing it in terms of edge computing. Rust is absolutely in a position to become the best non-JS language to use for these kind of 'workers' environments. And they have a lot of benefits: super fast, super cheap, effortless deploys, etc. so it's totally possible to make an argument for them. "Rust is the only compiled language viable in these environments"[1] is certainly a compelling position. [1]. Hyperbole, I'm sure there's good progress towards getting others to work. For example, I'm currently working on adding Prolog support for Cloudflare Workers :-)

synergy20 4y ago
recently started learning wasm as a c++ developer, yes go binary is large for edge computing(workers) and wasm runtime is a good fit there, what about c++ vs rust for this use case? many wasm subjects are referring rust as _the_ language, but I feel modern c++ can do it as well if not better on all aspects(maturity, size, speed, even safety).
- grose 4y ago
  I think modern C++ could be perfectly viable as well. Maybe https://github.com/cloudflare/workers-wasi https://github.com/cloudflare/workers-wasi would be a good starting point? I'm not too knowledgeable on the subject. Exciting times though, I think WASM might be the great equalizer.

devit 4y ago

Rust and Go are different classes of language, where Rust is a non-GC memory-safe language, and Go is a statically typed GC language. In Go's language class of statically typed GC languages, Go is much worse than the best languages, which are Kotlin and C# (Go lets you forget to write error handling, had no generics until recently, uses duck typed interfaces (!)). In general, Go's inferiority can be traced to its root cause, which is the Google Go designers having severe Dunning-Kruger syndrome because they think they are good because they invented C/Unix and work at Google and don't realize they have no clue about programming languages in general and were only successful because the limited hardware at the time didn't allow sophisticated programming languages and thus allowed a terrible language like C to succeed. As a language class, non-GC memory safe languages are far better than statically typed GC languages since they don't have the overhead of a GC and can guarantee the correctness of concurrent programs since they are data-race free (in Go-like language two threads can share the same data with no checks whatsoever resulting in arbitrary racy behavior), can make other guarantees enabled by the linear type system and use composition instead of implementation inheritance. So in general you should always use Rust unless existing framework or libraries for other languages make solving the problem much easier and the app code is small enough that the extra problems in using a subpar language aren't too bad (e.g. you probably want to use bash for system administration, Python for simple deep learning projects, Kotlin for simple Android apps, Swift for simple iOS apps, TypeScript for simple web frontends, etc.). However, if you plan to write a lot of code, then just using the best language, i.e. Rust, is probably better since the time to write or correct dependencies will be small compared to the sheer amount of code you are planning to write for the main software. If you are willing to give up good performance and a large library ecosystem for correctness, then dependently typed languages like Idris are also an option.

Strum355 4y ago
You lost me at saying Go let's you forget to handle errors, when its pretty objectively more vocal at having you not handle them than Kotlin with its lack of checked exceptions, having just said Kotlin (and C#) are better than Go in its class. And I say this as a big fan of both Go, Kotlin and Rust.
machinekob 4y ago

dxuh 4y ago

> Doug and I were counseled to know our “opponent” (Go) inside and out > Rust Evangelism Strike Force I know these are in quotes or meant as a joke, but it still is very off-putting to me. It's a team of 40 engineers and they have different subgroups of people coordinating essentially political efforts to advocate for programming languages. I would not like to work at a company like that. What is with Rust and this uniquely fanatical evangelism? For me the biggest reason for not using it is the rabidness of its advocates. While they state technical reasons it seems the reasons are not technical in nature, which leads to my gut reaction of not taking them seriously.

mayormcheeseman 4y ago
As someone relatively new to both Go and Rust, I definitely feel the same way. It seems like Rust fans are more passively-aggressively pushing Rust much more than Go devs. Also, it seems like a lot of them talk down on Go/Go devs for the usual reasons that most people point out. For example, Go's popularity is only because of Google. I'm sure that has to do with it, but I don't think many companies are going to be putting their bottom line at risk by using a language just because it may have come from Google. It has to actually do its job and do it well. In that case, the proof is in the pudding. Again, as more of an outsider to these languages, Go seems to be doing pretty well for a relatively young language and it's already taking over the cloud space.
deleted 4y ago
[deleted]