Using Rust at a Startup: A Cautionary Tale (scribe.rip) 141
"Rust is awesome, for certain things. But think twice before picking it up for a startup that needs to move fast," Matt Welsh, co-founder and chief executive of Fixie.ai and former Google engineering director, writes in a blog post. From the post: I hesitated writing this post, because I don't want to start, or get into, a holy war over programming languages. (Just to get the flame bait out of the way, Visual Basic is the best language ever!) But I've had a number of people ask me about my experience with Rust and whether they should pick up Rust for their projects. So, I'd like to share some of the pros and cons that I see of using Rust in a startup setting, where moving fast and scaling teams is really important. Right up front, I should say that Rust is very good at what it's designed to do, and if your project needs the specific benefits of Rust (a systems language with high performance, super strong typing, no need for garbage collection, etc.) then Rust is a great choice. But I think that Rust is often used in situations where it's not a great fit, and teams pay the price of Rust's complexity and overhead without getting much benefit.
My primary experience from Rust comes from working with it for a little more than 2 years at a previous startup. This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices (themselves implemented in a combination of Rust and Python). Rust was used primarily because a couple of the founders of the company were Rust experts. Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well. As the team and codebase grew, I felt that, over time, we were paying an increasingly heavy tax for continuing to use Rust. Development was sometimes sluggish, launching new features took longer than I would have expected, and the team was feeling a real productivity hit from that early decision to use Rust. Rewriting the code in another language would have, in the long run, made development much more nimble and sped up delivery time, but finding the time for the major rewrite work would have been exceedingly difficult.
So we were kind of stuck with Rust unless we decided to bite the bullet and rewrite a large amount of the code. Rust is supposed to be the best thing since sliced bread, so why was it not working so well for us? [...] 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). 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. As a comparison point of what it looks like to adopt a new language on a software team, one of my teams at Google was one of the first to switch entirely from C++ to Go, and it took no more than about two weeks before the entire 15-odd-person team was quite comfortably coding in Go for the first time.
My primary experience from Rust comes from working with it for a little more than 2 years at a previous startup. This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices (themselves implemented in a combination of Rust and Python). Rust was used primarily because a couple of the founders of the company were Rust experts. Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well. As the team and codebase grew, I felt that, over time, we were paying an increasingly heavy tax for continuing to use Rust. Development was sometimes sluggish, launching new features took longer than I would have expected, and the team was feeling a real productivity hit from that early decision to use Rust. Rewriting the code in another language would have, in the long run, made development much more nimble and sped up delivery time, but finding the time for the major rewrite work would have been exceedingly difficult.
So we were kind of stuck with Rust unless we decided to bite the bullet and rewrite a large amount of the code. Rust is supposed to be the best thing since sliced bread, so why was it not working so well for us? [...] 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). 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. As a comparison point of what it looks like to adopt a new language on a software team, one of my teams at Google was one of the first to switch entirely from C++ to Go, and it took no more than about two weeks before the entire 15-odd-person team was quite comfortably coding in Go for the first time.
I'll take it! tired of buggy web bloat. (Score:4, Interesting)
> Just to get the flame bait out of the way, Visual Basic is the best language ever!
I'll take VB over MVC and Core crap. Most businesses use mice and desktops/laptops for actual work, so the mobile angle is overblown. VB 6 was 6x less code and was 6x faster to develop in*. Businesses don't want to pay 6x more just to have mobile, since most don't take advantage of it, they are just afraid of obsolescence. It becomes a self-fulfilling prophecy: everyone is abandoning a tool because they fear everyone is abandoning a tool. (We need a state-ful GUI markup standard.)
Get *on* my VB lawn, it's nicer than existing webbloat.
* I realize a well-ran web-shop can be productive, but most shops are not well-run. Dilbertism dominates reality.
Re:I'll take it! tired of buggy web bloat. (Score:4, Insightful)
Tools today, frameworks today are massive bloat fests and you can't count on long term stability from them.
Re: (Score:3, Informative)
I worked with Borland (later Embarcadero) Delphi for a long time and hated VB 6 when I had to touch it from time to time. Typing and implict variable creation mechanisms are incredibly lax unless you use Option Strict On, and way too often VB guessed my intent false. Whatever time I saved initially by writing code quickly was eaten by the extra debugging time for ironing out the mistakes.
With Option Strict On VB 6 became tolerable, but at the same time it lost the (dubious) advantage of allowing you to slap
Re: (Score:2)
incredibly lax unless you use Option Strict On
Which it should always be on, unless you are copying VBScript code into a VB6 app, then you comment that out while you coax it to be proper VB code, then you uncomment it.
and way too often VB guessed my intent false
Because you were explicit in what you wanted your code to do. See above point.
Re: (Score:2)
Meant "weren't" explixit
Re: (Score:3)
Typing and implict variable creation mechanisms are incredibly lax unless you use Option Strict On, and way too often VB guessed my intent false.
The only thing Option Explicit did was require you to declare variables before you used them. That's it. This will save you from impossible-to-debug problems like... mistyping a variable name. (Option Strict is a VB.NET thing. That's a completely different language. Though it's worth pointing out that that only stops implicit down conversions like storing a float result in an int variable that you earlier declared to be an int... Who has these problems?)
As far as type systems go, VB was bog standard, wit
Rust is actually like tradtional VBA (Score:2)
In old VBA, you did not have classes, new, garbage etc. You used dynamic arrays to store things in. Arrays of structs.
My understanding is that his how it is largely done in RUST. To avoid dealing with non-trivial pointer structures which I understand are very difficult.
Re: (Score:2)
Didn't APK use Delphi for his hosts program back in the day?
Re: (Score:2)
Yes
Re: (Score:2)
He liked to evade downmods by posting AC. He would post the same thing over-and-over until he could get his message through at a score of 0 (due to mods running out of mod points). When they required logging in to post AC, he bailed.
Re: (Score:2)
MVC was not a bad concept. Unless you're talking about some branded product called MVC that I don't know of, it was the methodology used in the first GUI. Over time people did combine V+C into the same components. I do seem some user interfaces that never seemed to learn these concepts, putting core logic into the buttons instead of have a clean separation between the interface and the back end. And as much as I remember, VB was MVC in many ways.
Re:I'll take it! tired of buggy web bloat. (Score:5, Insightful)
It was just staggering how people took what was a simple concept and managed to generate so much arcane gibberish.
Re: (Score:3)
> putting core logic into the buttons instead of have a clean separation between the interface and the back end.
If your tool makes the code short and simple, then "separation of concerns" is often wasteful busy work that makes for spaghetti code: pointing back and forth between the UI and "business modules". Excess indirection can be wasteful--an e-bureaucracy.
(RANT: The eventual ideal tool would use Table-Oriented-Programming so that grouping events and biz logic modules is a matter of sorting and filte
Re: (Score:2)
Most businesses use mice and desktops/laptops for actual work, so the mobile angle is overblown.
Just let the sales team hear you say that and you'll have Salesforce forced upon you before you can say "bottom line".
wrong tool (Score:5, Interesting)
Because either Rust is a systems language or its trying to be all things to all people.
The fundamental problem is you SHOULD be developing applications in C#, Java, Ruby, Python, or Go. People used to write apps in C because that was all they had.
Rust fit for about 1% of projects, if its really a systems language or we should throw it on the ash heap now if the people behind it still think it should be application layer language - because it sucks.
Re: (Score:3)
Because either Rust is a systems language or its trying to be all things to all people.
Is it the wrong tool or is it premature optimization? You use C like languages in two main situations. a) when you need to talk direct to operating system parts and b) when you have one particular piece of code where the costs of your other language - for example garbage collection - don't work and you want one particular piece to be optimized. Using a higher level language like python is always going to be easier because the number of libraries for it are massive and a whole bunch of other problems such as
Re: (Score:3, Interesting)
If you want your code to work next week, don't use Python.
If you want your code to be fast, don't use Python.
If you want your code to be readable, don't use Python. (This shouldn't be controversial, but it is. )
If you want a print statement that isn't completely fucked up, don't use Python.
If you want lambdas that aren't crippled due to one moron's stupid choice, don't use Python. .... thousands of pages later ....
If you want an easy language that's fast to develop in, Lua is better than Python in every con
Re: (Score:2)
If you want your code to be readable, don't use Python. (This shouldn't be controversial, but it is. )
There is nothing controversial about this statement, it is simply wrong.
Re: (Score:2)
Using a higher level language like python is always going to be easier because
Because: the language is fundamentally more easy and streamlined.
the number of libraries for it are massive
You could use the same libraries from C/C++/Rust/Go.
and a whole bunch of other problems such as memory management are just taken care of.
Not really. If you are using one of those libraries you are required to tell them when you are done with a certain part, so they can manage their own resources.
Python only takes care about
Re:wrong tool (Score:5, Interesting)
I write in C because it's all we have. Oh sure, we could rewrite 15 years of technical debt in something else, but there's no benefit except as a jobs program. The code is low level and all those languages you list are completely unsuitable.
Part of the problem is that differentthings have different needs. Most scripting language are not about quality, they're about getting something done fast. If you're building a stupid web site for a stupid startup and are hiring the lowest paid developers you can, so quality is unimportant and most of it is throwaway code - in that scenario you're not writing code for the Mars landder, or a nuclear power plant. Who cares if the next Twitter replacement has bugs when the important thing is to get it to market before anyone else. And anything with the word "startup" is fundamentally more concerned about speed than quality (which is why technical debt is so huge when those startups change and start trying to do things the right way).
Rust just doesn't fit into that startup mentality. It's intentionally meant to be slow going. So trying to turn it into a high level language for fast moving applications doesn't work well. But at the same time it's difficult to pull it into a low level language without turning off lots of its advantages (sort of like doing C++ by writing C, which is commonly done).
Re: (Score:2)
Re: (Score:2)
Yes and no. Gotta turn off many of those features just to do low level systems work, where sharing buffers is the norm, especially in a tight memory environment. Use-after-free protections isn't much help if you're not using standard functions and instead have a pool, and you don't have space available to mark who currently owns a buffer.
There's one guy in the company who took it upon himself as a side project to try to convince everyone in the 300 person department how great Rust was and how we should al
Re: (Score:2)
Gotta turn off many of those features just to do low level systems work
Yes, but Rust allows safety to be turned off only when needed, and those short code segments are clearly marked with the "unsafe" keyword.
Re: (Score:2)
This is 1999 version of Java, which was still very slow even on a powerful PC and there weren't any compilers to native code yet, and we were supposed to put it smaller chips.
Native compilers did exist at that time, probably since roughly 1997. But most likely not for your embedded processor. Also small embedded JVMs emerged around that time, e.g. Wonka.
However rewriting a huge code base for sake of rewriting hardly ever makes any sense. It would have made sense to port older C++ parts to more modern standa
Re: (Score:2)
If it's intentionally slow to learn (I don't believe this), then it should be abandoned NOW.
AFAIKT, the problem with Rust is that it's immature. The libraries need a lot of work and much better documentation. Some of the language needs better documentation. But I don't think it's intentionally user-hostile.
Re: (Score:2)
It does too much too. Ie, yet again someone tries to redesign a build sytem so now there are a billion of them that can't match the simplicity of make.
Re: wrong tool (Score:4, Insightful)
Re: (Score:2)
Don't do C++ by writing C. That's silly. Do leverage C++'s backwards compatibility with C to start writing safer, more maintainable code without completely replacing the legacy stuff that works.
And maybe consider using Rust. The stuff that we used to write in C, then migrated to C++ is actually the system-level stuff that Rust is really good for. And if you're comfortable with Modern C++, you already know most of the "new ideas" that you need to learn to use Rust, stuff like object lifetimes.
Re: (Score:3)
Re: wrong tool (Score:2)
Re: (Score:2)
If the only thing you took from C++ was smart pointers for RAII memory management, you'd have safer code
Yes, absolutely.
If the only thing you took from C++ was STL containers, you'd have safer code.
Mmm... maybe. If you're in a memory-constrained device (e.g. embedded) I don't think this is true. Not unless you enable exceptions, which opens an additional can of worms, and requires you to take on a lot more C++. STL containers cannot gracefully handle out-of-memory situations without exceptions.
If you're writing or a platform that effectively simulates unlimited memory (e.g. modern *nix systems, Windows, etc.) then this isn't a problem because memory allocation doesn't fail in a way t
Re: (Score:2)
You can simply use fixed sized version of STL containers.
Also: I'm not sure I get your point. What is the difference between an STL container throwing an exception or a C program crashing "randomly" because of memory issues?
Re: (Score:2)
Re:wrong tool (Score:5, Insightful)
The fundamental problem is you SHOULD be developing applications in C#, Java, Ruby, Python, or Go
The biggest thing these languages have in common is that the users of these languages have a pretty heavy convention on how to do things. Spring Beans in Java are a pretty well understood convention. C# using [WebMethod] and what not is pretty well understood by all there too. Same goes for Python which is why you always see Django or Flask but it also shows that a single "true way" isn't there, Python has a two party system. And some might say "Oh but Java has J2EE beans..." which I would retort that those are basically Spring Beans but with a java namespace, as far as how one uses J2EE beans, you basically use them exactly the same way Spring Beans are used. And that's because Spring became so popular over the "FUN" way Sun was trying to get people to use J2EE, that basically Sun eventually gave up trying to reinvent the wheel and made J2EE 7 and up literally look exactly like Spring (except for EJBs, which don't get me started).
So what does this have to do with Rust? Rust has like a billion (not seriously but they have a lot) different conventions on how to do high level things. And there hasn't been a really clear winner yet. So what one person learns in Conventions will highly likely not translate over to some other person's way. Like for things like async, Tokio has pretty much won there. For serialization, you've got serde. But for a container WS? You've got folks firmly in actix, rocket, and hyper camps and each of those does things differently than the other. And same for the DB side of things, there's not really a firm "standard" way of doing things.
Add in that you have some UI toolkits that can with a swap of the rendering backend, create HTML to be rendered. iced-rs comes to mind. Rust is fairly new and there's still a lot of different ways each person can do their project. Sort of how C++ has gotten as of late. You've got people doing template metaprogramming and then you've got some that's moved onto constexpr. You've got some that still use pointers, and some that's moved to standard container objects. Some that use functions pointers and some that are actually using std::function. Rust is still finding the winners and losers in the API race.
For the really established stuff, Rust is really surprisingly good. Even for **SOME** high level stuff. But I'm not going to lie. Some of the high level stuff at the moment is. . . Still in a state of flux to put it nicely. And so without a really tight control from higher up, you're going to end up with stuff that can be easily read by one person and looks completely Greek to the other. This is one of the reasons I love the Linux bindings for Rust. They had a very clear idea of what they wanted and it's very clear what the intention and convention is there. There's not a second guessing what someone was trying to do. If you can read Rust, the Linux bindings pretty much ensure you'll write code that is understandable by all. Same with Relm/iced and other Elm inspired codebases. If you've dealt with Elm, dealing with Relm is pretty straight forward. Like you aren't going to be second guessing yourself on how to write the code or what it is that you are reading.
But at the moment, if there aren't hard standards put into place, there isn't widely held conventions that lead to reading code a lot easier.
if its really a systems language or we should throw it on the ash heap now if the people behind it still think it should be application layer language
Well no one person is pushing for it to be anything more than what they are pushing for it. There isn't some Rust cabal that's wanting it everywhere, just like the C++ standards committee isn't sitting there going, "Man I hope Qt wins the toolkit war" or whatever.
It's really important to remember Rust is still a fairly young language. Not only there, there's a lot of folks flooding to it.
Re: wrong tool (Score:2)
informative post, thanks.
I haven't tried rust, but I'm suspicious of TFA's judgement when he says:
"In my experience, people generally have little difficulty moving between languages like C++ and Python," (and in context he means both ways).
I'm a long time Java guy (with some c, c++, perl and "others") but recently have been working with some python first or python only people. Having the python only people do c++ , or heck, any strongly typed or just compiled language would be a serious shock to the sys
Re: (Score:3)
I'm not entirely convinced you can compare C to Rust in this way.
I recently wanted to get back into programming. Started out trying C, moved to Rust.
Rust has its downsides but they are not C-like downsides. If we are talking beginners, Rust has great documentation and a very active support community. And if we are talking general application development, it has a fully featured standard library, you are not starting from nothing and building up form their. It is also completely cross platform. It has its ow
Re: (Score:2)
Rust has its downsides but they are not C-like downsides. If we are talking beginners, Rust has great documentation and a very active support community.
Well... I imagine that after C has been around little longer there will be more documentation -- maybe even books, online forums, etc... /sarcasm
Your comment is nonsensical, there are (and have been) *literally* thousands of C reference / learning sources for C, targeted at all experience levels. I have 3 C books on my shelf, including one (or two) I got in college in the mid '80s.
Re: (Score:2)
I am not doubting that their are literally thousands of C tutorials, but it has very poor official curated documentation. While many of these C tutorials may be of high quality they are not comprehensive, and telling the good tutorials from the factually inaccurate ones simply based on google search result scoring is a crap shoot. C has the cpp reference webpage and the online unix man pages for "official" documentation, and they both suck. Their are probably many amazing books, but books are not as easily
Re: (Score:2)
Keep in mind that C was around long before the Internet ...
These are not languages that can be considered similar in their documentation and support.
Perhaps with regard to the ease of accessing that documentation/support. Then again, I've never had any trouble finding information I needed about C, even online, and I've been using C since the mid '80s. Of course, the longer one uses something, (usually) the less documentation/support is needed... But to your point, newer languages / systems (etc) certainly have the benefit of having their documentation (and selves) developed during the age of
Re: wrong tool (Score:2)
Honestly the biggest thing stopping me from learning c or c++ is because the documentation in general for it is all over the place. I actually bought a C book that was highly rated, only when I got it the examples typically didn't work. It turns out that the reason why is because, the book being 10 years old at the time that I got it, much of glibc had changed. To this day I still haven't really gotten into C.
Rust was easy in comparison. I really didn't even need a book, or even an actual course for that ma
Re: (Score:2)
it's really not completely cross platform compared to C. You'd be surprised about the really obscure or niche platforms C supports. Rust doesn't even have the reach of C++ yet never Mind C.
Re: (Score:3)
use the right tool for the job (Score:4, Interesting)
use the right tool for the job ... so you didn't get that part right, yet you still think that's blogworthy and also are an ex- google engineering director.
mmmkay ...
Re: use the right tool for the job (Score:2)
If all you have is a hammer...
Seriously, programming languages are tools. I've used well over 20 of them, and at least half-a-dozen for serious development. I love Prolog, but wouldn't use it for anything outside of certain mathematical/scientific areas. Lisp - ugh - but functional has its place, and I've written a lot of it. VB6 really was a great language for business apps. Java for modern CRUD applications and web service backends. Etc..
I haven't used Rust, but it's pretty clearly designed for systems
Re: (Score:2)
One caveat is that unlike, say, a hammer, programming languages are living tools -- where a language goes and how useful it will be in the future depends on the community around it, which is important for you because unlike that bookshelf you just put together with that hammer, your software project is also most likely a living one.
For my part, I love C++ for real time, exciting work and go for tedious, data moving tasks, and I often combine the two. (Now if only golang had a feature to prevent GC from runn
Re: (Score:2)
"This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices"
That sentence is the part of the summary where I lost the plot. Half the words are meaningless fluff and the other half are prepositions and articles. But from the words I do know, it was clear that this project was way too high level and fast moving for a language intended fo
Re: (Score:2)
"This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices"
That sentence is the part of the summary where I lost the plot. Half the words are meaningless fluff and the other half are prepositions and articles. But from the words I do know, it was clear that this project was way too high level and fast moving for a language intended for a lower level. And for a startup with such a concept, the goal is to get the product done fast, not to make it provably correct and bullet proof.
They used a C++ for something anyone in their right mind uses a Java for.
Re: (Score:3)
No one in their right mind uses Java
Re: use the right tool for the job (Score:2)
"A" java
I got what he was saying
Re: (Score:2)
And only people who know nothing about Java, talk such nonsense ...
For an idiotic layman like you: there is no difference between C++/Java/C#.
As some higher level programmer (team) will hide the obscurities for you ... Good luck with your attitude.
Re: use the right tool for the job (Score:2)
That sentence makes perfect sense and it generally informative. Obviously, you don't work in a similar space. It actually tells you quite a bit about what the app needs to do and what kind of expectations you might have for adding features.
Re:use the right tool for the job (Score:4, Insightful)
Not that I'm expecting people to actually RTFA, but his blog post was pretty much about that point... and he's not the one who made the decision to use Rust. I think the blog post is worthwhile because it confirms what I've suspected, but which Rust enthusiasts always seem to downplay: That Rust is actually fairly difficult for average programmers to pick up and use productively, and it emphatically trades speed/ease of implementation for it's top performance + memory/thread safety.
Re: (Score:2)
yes. you're completely correct. it is bloody obvious. ergo the whole thing is about the persona whoring for attention. ok, legit, but what would you expect me to say? i'm human, you insensitive clod!
Re: (Score:3)
Honestly, when you read between the lines, you can tell the author got immensely frustrating when using Rust for a few years, and this blog post is a cathartic bit of backlash against all the people who think Rust is God's Gift to Programmers that has no faults or downsides, as well as his frustration over his employers forcing everyone to live with their bad decision.
Clearly, the startup founders in question made a "bloody obvious" mistake like this, so I guess it's a bit hard for me to fault an attempt to
Is Rust a systems language? (Score:4, Interesting)
It looks to me like it was optimized for writing security libraries and/or code that will be facing the big bad internet. Hence Rust's Mozilla roots.
Rust puts constraints on what you can do. The constraints are supposed to provide benefits (security, memory consistency etc.). I don't see a case where those restrictions are a fit for systems programming, except maybe device drivers that have limited scope, but you'll be having a fun time squeezing the hardware interfaces of devices into the rust mold.
For systems work I want to see a fairly direct mapping between the code and the generated assembly. I want to see direct and simple support for inline assembly. I want memory to be available in the language consistent with the machine memory model. I see Zig as the best contender to replace C based on its technical metrics, but programming choice is a poisoned political space so I have low expectations.
Re: (Score:2)
> you'll be having a fun time squeezing the hardware interfaces of devices into the rust mold
And still, it exists and works quite well... for my hobby projects, at least.
https://docs.rust-embedded.org... [rust-embedded.org]
Re: Is Rust a systems language? (Score:2)
Rust is designed to generally operate safely, but then allows you go lower when you need, for example with raw pointers. That's why people like it. It's a bit like how modern ANSI C has "safe" versions of char* functions that require lengths and such.
Re: (Score:3)
I don't see a case where those restrictions are a fit for systems programming
Those restrictions are a perfect fit for systems programming. Systems programming is foundational, and you really, really need that code to be as fast as possible and perfectly safe. This is exactly what Rust excels at.
you'll be having a fun time squeezing the hardware interfaces of devices into the rust mold.
Nah. It's pretty easy to do register manipulation, etc., in an unsafe block. And this naturally leads you to use as little unsafe as possible, and to very thoroughly review and test that code. This works very well in practice. The first actual used-in-anger Rust code in the Linux kernel is
Working at a startup (Score:2)
The goal of working at a startup is to use as much different technologies as possible in order to pad one’s resume when the whole thing belly flops. You never want to go all in on one horse.
Early adopter problem? (Score:2)
Maybe in 10 years this won't be a problem. Rust needs time to get in to college curricula. How is it doing there? Remember when everybody complained about "Java schools"? Maybe a lot of the graduates weren't good, but there were a *lot* of graduates and you could find enough good ones to get the job done.
Sometimes the new language does fit a start-up and allow them to shove things out the door fast. IIRC, this was what happened with Ruby and Twitter. Then another problem: they got the product out fas
Re: (Score:2)
I've heard that Haskell has a big following in finance
It doesn't. Finance mostly uses the same programming languages as everyone else plus a few others (e.g. R). Haskell is popular among compiler writers because writing a compiler is something very well suited for functional programming. However, if your task isn't based upon a formalized mathematical framework (like a programming language) then pure FP isn't very useful. Also, writing a compiler for a FP language is far easier than writing one for a non-FP language (mostly, ignoring Prolog here). This is
Re: (Score:2)
I've never seen Haskell used in finance. Not saying it never happens, but I think it is pretty rare.
By far the most popular "programming language" in finance is Excel. Mostly this isn't a good thing, but it is what is used out there.
Other than that, Python, R, and of course JavaScript are what gets used.
Re: (Score:2)
Rust needs time to get in to college curricula.
Rust needs time to iron out some of its ecosystem problems. The async-std vs. Tokio schism is particularly painful. Every dependency that involves async picks one or the other (usually not both) and they aren't compatible. Or, rather, you are left to bridge the differences, which is a misery. If you can stay exclusively with one or the other then Rust async is a joy, but that is rare.
Dealing with different size errors is great fun (not.) You can't just return any Result error up the stack because dif
Re: (Score:2)
The async-std vs. Tokio schism is particularly painful.
That's fairly old. Tokio. async-std has been looking around for sponsorship to keep devs on it. Tokio suffers no such disability. If someone is trying to decide Tokio or async-std, you go Tokio. Everything that went with async-std is just going to have the painful chore of converting.
You can't just return any Result error up the stack because different errors have distinct memory layout
Yeah. You absolutely shouldn't do that in any language. If things have different memory layouts you shouldn't just assume somewhere down the road someone will catch it and ensure which one values need to map to what. Ju
Re: (Score:2)
If someone is trying to decide Tokio or async-std, you go Tokio.
False.
There are diehard async-std users and they have good reasons. [zenoh.io]
You absolutely shouldn't do that in any language.
False.
Any given garbage collected language (C#, Java, whatever) that passes by reference solves this problem safely and without the hassle that you incur in Rust. java.lang.Throwable instances climb up the stack with zero compromise of safety and no concern about memory layout.
And that doesn't make Rust wrong or defective in any way. It's just the cost you must pay when you choose Rust. If it's worth it then you pay the cost. If th
is it a language issue? (Score:2)
Re:is it a language issue? (Score:4, Insightful)
Yes, it's absolutely a language issue. For example, it would be a terrible idea to write all your backend business software in C++ (this from someone who primarily works in C++) or Rust if you didn't require absolute top end performance. Java or C# are relatively fast and memory-safe and are MUCH easier to use, boosting your team's productivity while also ensuring you're more likely to find people who know those languages well, and thus can be more easily hired.
Languages are tools. Use the right tool for the job at hand. No language is the best choice for all possible applications.
It worked in a similar situation (Score:2)
I wanted to start full-bore Rust production after a year of study. Web logic just isn't there. I wound up writing to SQLite with PHP for the front-end, and Rust in the back-end to talk to Twilio and work the list.
Systemd integration in Rust is farcical. Same for PHP,
SQLite in Rust isn't threadable, and I couldn't get async working except for Twilio. Async isn't really important anyway for that sort of task, but it would've been cool to see it work.
Did dev on Debian Testing, and the async falls over on Stabl
Why no Google translate (Score:3)
I've never understood why we have software that will translate Finnish into English, but we don't have software that will translate Rust into C++, or as far as I can tell any programming language into any other.
I would have thought that would be much easier.
Google, what are you waiting for? Get on the job!
Re: (Score:2)
You do not appear to have a programming background, converting between languages with different philosophies is anything but trivial. I seen a Fortran to C converter and I believe there is one for COBOL to C as well. COBOL to Fortran would be pretty much impossible because of the divergent way data is organised.
Re:Why no Google translate (Score:4, Insightful)
You do not appear to have a programming background, converting between languages with different philosophies is anything but trivial.
Unlike, say, translating Finnish to English?
Re:Why no Google translate (Score:4, Insightful)
Unlike, say, translating Finnish to English?
Translating Finnish to English is doable because English is the most fault tolerant language humans have ever evolved[*] [**]and because natural language is used exclusively by humans, who are also fault tolerant. So when a neural net makes a sloppy-ass conversion from Finnish to English, it's probably comprehensible, even if it's also probably incorrect in places.
Translating from one programming language to another is nothing like that. The machine is NOT fault tolerant. You get it right or you get nothing, period. A neural net flailing away with best guess output is worse than nothing. The time required to figure out what the neural net was trying to do and correct it is longer than the time required for a human to read, comprehend, and translate the original code themselves.
---
[*] Personal experience, as well as academic research. I've known a German engineer who could talk to a Chinese production company and make himself understood—in English, even though both parties spoke abysmal English. I've also had two coworkers who spoke Mandarin fluently be mutually incomprehensible, because one was from Shanghai and the other from Taiwan. They could recognize that the other was speaking Mandarin but couldn't understand what was said. So they spoke English to each other (less abysmally than the other example).
It's been said that English is the result of Norman conquerors attempting to talk to Saxon barmaids, making it a pidgin language from the outset, which has probably encouraged its inherent ability to be comprehensible even while both syntax and pronunciation are mangled.
[**] Most fault tolerant spoken language. Written languages are all considerably fault tolerant, from gyaru-moji in Japan to kusachuu-go in Japan and China to Russian and French equivalents of leetspeak.
Re: (Score:2)
The thing is, machine translators don't bark the same mistakes that human translators bark. Especially not if they sheep one sentence after anoth
Re: (Score:2)
or as far as I can tell any programming language into any other.
We call those 'compilers' and they're very common.
Re: (Score:2)
Trans-compilers are actually quite easy (compared to having a compiler in the first place). gcc for example, is structured as front ends which convert the source language into an internal representation and backends which normally produce machine code from the internal representation, but can fairly easily be written to produce a target language. The problem is that the output language done this way is pretty unreadable (and unmaintainable) to a human. The other big issue is the run time support/standard li
So, as a rank beginner, (Score:3)
with experience only in DOS batch, shell scripts, dBase/SQL queries, and Arduino scripts with a sideline into fully scripted and guided C++ code into the odd Mega and such, I might want to climb the learning curve of C# or JavaScript/Java rather than learn Rust as a first real programming language?
All I wanna do is have some fun, make a trivial Android app that can port to iOS, and maybe be able to write code for Arduino-level controllers and eventually my stock of Raspberry Pis... Maybe Rust is not the right launchpad to my misguided retirement?
Re:So, as a rank beginner, (Score:4, Informative)
Commit harakiri instead. It's quicker and less painful.
Less flippantly, there are toolkits which build on top of the native toolkits for Android and iOS so that you can write once and then cross-compile, but you're setting yourself up for a lot of obstacles. If you want to make an iOS app you're far far better off learning Swift (and you will need a Mac, so if you don't have one then factor that in). If you want to make an Android app you're better off learning Java or Kotlin. And if you want to port it, learn Swift and Kotlin and port the code between the two rather than trying to find a common language.
Re: So, as a rank beginner, (Score:3)
The language you're looking for is C#, using Visual Studio. You can write apps for Android using Xamarin with Visual Studio in C#, and then cross-compile them for iOS. Or so I'm told. I've never actually tried it. Xamarin does come with Visual Studio, even the free version, for sure. You'll still need a Mac for iOS though, even with Xamarin.
Re: (Score:2)
This is the way! (Or even better, the new .NET MAUI project which makes it even easier to translate C# code between platforms - mobile, web, desktop, etc)
Re: (Score:2)
Xamarin is the cross Android/IPhone tool "everyone" uses. Maybe VS gives something useful too, when working with Xamarin.
But personally, I never found anything that VS was useful for that VSCode wasn't, especially that would be worth some $1000 per year.
Re: (Score:2)
I have tried it, and that experience was behind my advice in an earlier reply to OP to learn Swift and Kotlin. Your two options when compiling Xamarin for iOS are to use Visual Studio for Mac, which is crippled compared to the Windows version, or to maintain an open login session on the Mac in addition to the ssh bridge; and even then in my experience the compilation fails regularly if you have large graphic assets.
Re: (Score:2)
All I wanna do is have some fun, make a trivial Android app that can port to iOS,
Learn about PWAs. It's the path of least resistance. For your Arduino, just learn C.
Re: So, as a rank beginner, (Score:2)
PWAs...
"progressive web application, commonly known as a progressive web app, is a type of application software delivered through the web, built using common web technologies including HTML, CSS, JavaScript, and WebAssembly"
Good advice, thanks.
Re: So, as a rank beginner, (Score:2)
agree that as a one stop language JavaScript (or preferably TypeScript (https://www.typescriptlang.org/) ) is a good way to go today. (as much as I have looked down my nose at it)
it's that language in the browser (and thus web apps and PWAs which can do plenty on phones. ) and since node.js came out it can do server side stuff well enough for many needs.
And with node you can run on raspberry pi too.
Also use an IDE, like VScode.
Time may help (Score:2)
The passage of years will likely provide more documentation, examples to copy from, etc. Some of these criticisms might not apply in the future, as they're more of a symptom of the still-small community, rather than t
Re: (Score:3)
No, C isn't really hard to learn. It's hard to learn to do some things (like concurrency) in C, and if you're just starting, it's hard to learn to pay attention to everything you do. But C is nearly as easy to learn as assembler, and it's easier to use for simple things.
The problem is that C is a really simple language, so when you start trying to do something that's a bit less simple, the programs start getting complex quickly. (Compare a simple hash table in C vs. one in C++, Java, or Python.)
Re: Time may help (Score:2)
Re: Time may help (Score:2)
IDK where this guy gets his expectations.
Weekly dev talks to learn about your new language / platform /stack are not THAT unusual. Probably a good practice that more teams should follow.
Go is massive a special case because it's a relatively simple language and if you come from c++ , c#, or Java it's a particularly easy transition.
Most transitions are harder that.
I suppose it depends on where you want to be (Score:3)
Error rates? (Score:2, Insightful)
I'd like the author of that article to come back in a year and report on code QUALITY.
Now if you adopt the Facebook "go fast and break things" model of software development, with no consequences for errors, then probably Rust is a bad choice of programming language.
But my experience with Ada, a language with similar goals and culture-of-correctness, was that the time to working product was less, even though time-to-initial-test was longer. We found fewer errors in integration, and usually those were locali
So what was their solution? (Score:2)
The author writes at length about the problem and Rust itself, but there is no explanation as to how they mitigated the issues that Rust presented.
I feel that would have contributed more weight to the article by at least show how they were dealing with the problems Rust was creating.
Insane to use rust as a startup web api⦠(Score:2)
You need to be more specific (Score:2)
(Just to get the flame bait out of the way, Visual Basic is the best language ever!)
Every language is (probably) the best language ever -- for some task. Just sayin' ...
Old saying ... (Score:2)
Rewriting the code in another language would have, in the long run, made development much more nimble and sped up delivery time, but finding the time for the major rewrite work would have been exceedingly difficult.
“If you don't have time to do it right the first time, how will you ever have time to do it over.”
Sometimes you just have to suck it up, bite the bullet, and redo it.
Never happens (Score:2)
What! That never happens with C#. cough
Seriously though, I would not have used Rust for that kind of app. But I also don't think it should have made that big of a difference.
Project would have been a mess in any language (Score:2)
1) He said there was a need for a rewrite.
There is never a need for a rewrite in microservices when done properly. You simply transition and as you refactor, you replace sections of code.
2) He claims it
IMHO Language is only one small part... (Score:2)
Re: (Score:2)
Re:Oh whatever. Maybe you hired morons? (Score:4, Insightful)
People wrote Java and Python using punch cards? Hmmm...
If you read the article, you'd see solid reasons about the reason certain things are not recommended to be developed using Rust.
Read it, you might just learn something. Or does user name check out?
Re: Oh whatever. Maybe you hired morons? (Score:2)
Again: you can write it in C if you like and still get a working product on time and on budget if you hire people who know how to write code in general and write code in whatever language you're using in particular.
There's this godawful system called MUMPS that arose in the 60s for medical records and is fucking unreadable to the average person...it's still used in some places and more to the point...people wrote whole medical records systems with it. That worked.
So yeah...not buying the excuses.
Yes it's st