121–130 of 355 posts
The goal is to deliver products and iterate as fast as possible. Productivity is key to success.
IF (and it is a big IF) your startup ever gets to the point of having to scale up (nice problem to have) then just throw money at AWS, hire senior engineers and let them figured it out.
What matters is customer experience; nobody cares of what’s behind the scene.
With a competent teacher, experienced devs should be able to pick up on the memory model pretty quickly, and that is really the only initial blocker to productivity. After that a dev can essentially write procedural code if they want, like other common languages, while refining their thinking and practices towards idiomatic Rust.
I'd say the author brought a good point of why you should use Rust even for a CRUD app. (and yeah, I am a Rust fanatic and quite biased too). But hear me out. > 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. At this point, Rust is providing security and protection from technical debt. You have lots o…
True for most startups.
You should be using the language you know best or dynamic languages when you are trying to move fast.
Earlier quoted context omitted.
Just out of curiosity, why is your perf-critical layer running so slowly? Are you any closer to cracking it?
I can only give you some guesses, but I think there's some false sharing type of bug going on. There's also an issue with the fact that LLVM hasn't released a target for my CPU yet (I use a Zen 4), and who knows what bugs are caused by targeting the wrong CPU. In a single threaded version, it beats C#, though not by as much as I would have expected. The essence is that I have to run the same calculation on a large ar…
"Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial" Great point
The problem is that, while the benefits of trading safety vs. velocity go to the company, the costs go to the user, as it is the user whose data or identity will be stolen. And this goes well beyond Rust and "mere" memory safety: this extends to every kind of taking things slow and being careful in your coding rather than just throwing something together and later finding out you've made a serious error. This is why…
- Rust tends to push you to make good decisions. In my case, one of these good decisions was to ditch an ORM (which has always slowed me down) and instead write Postgres queries directly via SQLx. The compile time checks against an actual DB helped my speed dramatically
- Free performance can be a really big help when you are trying to figure out an API or algorithm. It's really helpful to know that my unoptimized code won't tank the server, and also helps me save costs on the cloud.
- "It doesn't compile, or it doesn't break" is kinda a mantra for Rust, and really helps me focus on problems at hand, instead of hunting down bugs.
> You will have a hard time hiring Rust developers.
I've found that there is a drastic difference between hiring devs willing to learn Rust, and devs that want to work with you because you are using Rust. The bar of those devs that seek out a Rust position tends to be very high.
> We made a huge mistake early on by adopting Actix as the web framework for our service...(To be fair, this was a few years ago and maybe things have improved by now.)
Actix-web has gone through some version-churn, but it's never been "buggy" in my experience. The experience multiple years ago is vastly different than today, but even my older services written years ago with Actix-web are still running fine.
> Libraries and documentation are immature.
Perhaps in years past, but I've always found the docs for Rust and its libraries to be very good. Folks write entire books on elements of Rust, and the standardization of the display of crate docs keeps things consistent.
> Rust makes roughing out new features very hard.
The "json!" macro can come in handy here. Also Github Copilot is a godsend for this.
> What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again.
Hours? These type of corrections are spoonfed to you via errors at compile, or via the IDE. I've never had to spend hours on this. Everyone of these changes could be a bug, and having a typesafe language is a huge help here.
I recognize I might be in the minority, but I've really enjoyed using Rust for services for my startup. It's helped me move fast, but maybe I'm a special case. I'm curious to hear other's experiences.
Earlier quoted context omitted.
The problem is that, while the benefits of trading safety vs. velocity go to the company, the costs go to the user, as it is the user whose data or identity will be stolen. And this goes well beyond Rust and "mere" memory safety: this extends to every kind of taking things slow and being careful in your coding rather than just throwing something together and later finding out you've made a serious error. This is why…
“Software doesn’t exist yet” is a huge user cost
I really, really, really, don't understand why people want to use Rust for CRUD/web stuff. Every GC language is better than Rust for CRUD/web when you are in the less than 10,000 users phase. I understand why Rust is trying to shove its way into the CRUD/web space--that's where all the programming is. I just don't understand the converse.
I cast glances at it every time my company's Python services break because of a runtime error that could have been caught with a better type system, or because they ran out of memory and need bigger boxes, or another developer has to spend a week debugging their environment to get the complex web of dependencies aligned for five minutes, or my laptop strains under the weight of a dozen docker containers attempting to…
Can you elaborate on the issues of Go's type system?
Earlier quoted context omitted.
Rust still won't save you from logic errors, so I guess I don't see your point.
I don't disagree?... The idea that moving fast is more important than correct and safe code--because a startup can't afford to waste time on these matters as their competitors who "don't give a shit" will eat their lunch--goes well beyond Rust and mere memory safety.