Prime Reacts: Building a Startup in Rust; I won't do it again

[@ze2like]

I tried and failed to build an entire startup in Rust... I created an array of 1000 Customer instances but no money went to my bank account.

[@ThePrimeTimeagen]

damn

[@lucaslopes1260]

Maybe you forgot to implement the pay trait on the customer struct.

[@RenderingUser]

​@@lucaslopes1260 I don't think it's possible The customer may have the broke trait

[@brutetriple8637]

did you forget to call `.collect()` to actually collect it from the iter?

[@RenderingUser]

@@brutetriple8637 sadly, the IRS called .collect() on iter first 😔

[@fish1r1]

IMO the dude who wrote the article and his team were slowed down because they were trying to build a startup in rust while also learning the language.

[@bug3937]

Literally this.

[@3DArea]

Is it not how it is usually done?

[@flarebear5346]

Why would you build a company around something that you are not good at?

[@spyseefan975]

@@flarebear5346 how do you protect an idea for years while you learn something new?

[@rednafi]

These language wars are so funny to see when you've worked in multiple successful startups that became successful writing their products in Django, Laravel, Node.

[@tomaszn9201]

Actually it is completely bullshit. Over 50% of the most successful startups started with Python backends: google, youtube, dropbox, spotify, instagram, pinterest, uber, tinder, stripe, reddit. Rest started with PHP, java, erlang. Startups biggest disaster is hiring javascript full stack developer...

[@rodreiser]

@@tomaszn9201 source: my head

[@joshuaokunola6261]

​@tomaszn9201 node just came into the picture in 2009. Most of these companies u mentioned are older than fullstack js itself.

[@rodreiser]

@@joshuaokunola6261 yes, and they all have nodejs api's as well.

[@tomaszn9201]

@@joshuaokunola6261 Give me the list of very successful companies started with nodejs.js . Nodejs is is red flag for VC the same like TDD or 100% coverage

[@trebabcock]

It definitely took time to become efficient, but I absolutely love writing a separate backend and client. Go for backend, Vue for frontend. Keeps me sane.

[@trebabcock]

@@darthvader1191 I mean, I don't choose what I use at work, but everyone can choose what they use for side projects.

[@daphenomenalz4100]

I love rust, nd will never stop loving it. But man it takes time to do almost anything, so I started using go. It is also fun like rust, nd atleast I am able to do stuff with time constraints 😂

[@HotakaPeter]

I write in Erlang. I have two uses for Rust, performance critical code, and low level interfacing. For proof of concept and quick prototyping Erlang is great.

[@richardgeddes630]

A mate who programs in C/C++ tried Javascript and was confounded by the plethora of values in a truth table. His final approach was to use === and its variants. However, there so much code out there that depends on == and its variants, that you're force to cope with it.

[@Flameandfireclan]

Js stands for: “Just Stop”

[@jonaskoelker]

> confounded by the plethora of values in a truth table. I'm mainly confounded by the fact that == is not an equivalence relation. Here's stuff I expect from _every_ equality operator: (a) x == x for all x (b) if x == y then y == x (c) if x == y and y == z then x == z (This is the definition of an equivalence relation.) I remember that JS violates at least one of these but I can't remember which one(s) or how many. Other confounders: there is no simple 'add' operation, there is only "coerce my arguments and then add whatever the results were". See also Gary Bernhard's "Wat" talk. I could go on.

[@sacha9593]

Is there any JS dev who still use == instead of === ?

[@richardgeddes630]

@@sacha9593 There's plenty of legacy code that relies on == . That's the reason why == won't be deprecated any time soon.

[@sacha9593]

@@richardgeddes630 I was talking about writing new code with ==, not about deprecating the feature.

[@wadecodez]

Ah yes a planned rewrite on the client’s time that will go smoothly.

[@ThePrimeTimeagen]

classic rewrite

[@abdelhaksaouli8802]

man why did not prototyped with python. if things work go on full performance mode and re-write it with rust ?

[@StingSting844]

Agree with the article fully. The saying "done is better than perfect" is always correct. Optimization is the enemy when you want to find a product market fit. Once you start making money, then you can figure out the slowest parts and rewrite as necessary. This doesn't apply for products which require hardened security from day one. For ex, auth, financial products

[@sck3570]

👌

[@irlshrek]

i dont remember where I heard it but I really like the "make it work, make it right, make it fast" order. are you saying that you cant really do that in rust?

[@StingSting844]

@@irlshrek definitely not saying that. But doing that in a language that has a steep learning curve is not a good idea. We can do it but capitalism is brutal and the product can go under very fast. I have worked in a failed startup and it was hard even to do it with easy to write languages. We rewrote large parts of the app according to feedback from the market/investors. Doing things like that in rust would have been unimaginable.

[@akshay-kumar-007]

@@irlshrek startups follow the ideology of fail fast and build fast. We as developers are obsessed with building the most beautiful piece of code but that takes time. There's a whole separate world of product management and sales (even though i hate those). Shipping things faster can really put you ahead of competition. Also, people leave companies and hiring/re-hiring someone for a language that's just used by 1% of developers doesn't make sense. Rust is a great language. But in my opinion it should only be used for systems where we can leverage whats unique about it. For majority of the projects Java/Go, React and React Native are a perfect stack.

[@CuriousSpy]

I'am as a developer don't write code as much as i edit it. Unlike with js, with rust i'am always confident that my app works lol. Delete/Rewrite half of the App? easy! In js/ts? OMG WHY IS THIS NOT WORKING!!!! wasted few days just to find a bug :D

[@kenchilton]

I suspect everyone who tries these startup efforts (which in some ways are like running and tying your shoelaces at the same time) regrets decisions they made and thinks that the grass would have been greener if done another way. However, every way of doing it will be wrong in some way - that is (unfortunately) the nature of the beast and one reason why not everyone can do it. My experience is to lean toward processes that produce results that you can live with forever. For code, every line you invest work in can be one that will be in the code base when it ships. Yes, it is an investment in your future, and the cost now will reap rewards later. The more you can do to make the right investments, the better. Yes, the customer may require changes, but what does not change is closer to shippable, even if not perfect. If you want the product code in Rust, hire coders who know Rust and write it in Rust. And please, stop writing _anything_ in Javascript. 😂

[@sacha9593]

"My experience is to lean toward processes that produce results that you can live with forever. For code, every line you invest work in can be one that will be in the code base when it ships. Yes, it is an investment in your future, and the cost now will reap rewards later. The more you can do to make the right investments, the better" For most startups this looks like a terrible advice. It depends of course of the kind of startup* you want to build and the kind of money you will be able to raise or invest at first but for the typical reasonably small app/website/software you will probably have at the beginning: few customers, little availability requirements, no need for performance, not enough money to hire the kind of developers you would like to have, potentially quite a lot of change to do all the time (potentially many full pivots when you will drop most of your company's code)... Yes if you are successful you may run into scalability/technical issues later because of this strategy, but by then you will have the money, people and experience to handle them.** By priority: - Choose a language that many people use in your domain or location - Choose a language you are confortable with (if you are the tech lead) - Choose a well established language (not a recent one) - Choose a still relevant language (a language that it still widely used for new projects) - Choose a language that allow fast iterations - Choose a language that is junior friendly (if you don't have the money to hire seniors) Don't be fancy if you don't really have too. *Of course if your startup launch satellites the problem is not exactly the same. **The scalability issues tends to be overblown: GitHub is still a Rails monolith, using a language notoriously slow and a framework that allows fast bootstrapping but is known to be difficult to scale, and it works fine. (Not that I would recommend Rails nowadays.)

[@dadlord689]

Many old projects have died and have burned all the money they made in attempt to get rewritten. This was the reason some authors have wrote books about design patterns. So having money in your pocket today is not saying you will keep them. And so the project planning is indeed a big thing. The scalability and flexibility are essential. Unless you can just sell the product and forget it (like a mobile game or just a single player one). And so I would say that architecture is far more important than language. If you can't plug/unplug stuff without resetting the whole thing - what are you even complaining about?

[@SokimMan]

I guess its just because I have not gotten used to the Rust syntax yet but readability being one of the top pros is kinda surprising to me. Rust code does not immediately seem incredibly readable when first learning the language. Probably because the syntax uses a lot of punctuation marks, that you just need to learn.

[@sk-sm9sh]

"Just have to learn" this is the opposite of readability. If you swim long enough in poop river poop river doesn't stink anymore. Same with ugly code.

[@BosonCollider]

@@sk-sm9sh using :: instead of . in some places does not make something inherently less or more readable, it just means you are free to give . consistent semantics where it is always member access. Rust makes everything explicit, without requiring you to write a page of code. As far as readability goes, that is its main value propositions. It makes any potential footgun explicit.

[@06kellyjac]

I will take code that is easily readable for experienced devs over code easily readable to new to the lang devs any day. You only stay new to a lang so long

[@sk-sm9sh]

@@06kellyjac there is no such thing as "code easily readable by experienced dev". It only gets slightly easier due to experience however mental toll persists forever as your brain is decoding it whilst it could be doing something more useful. Asking junior devs opinion is great tool to use as experienced may become unaware of constant complexity that their brain need to solve. Also you must consider situation where experienced devs might join team whilst not being experienced with your language you will be losing a lot of essential time there - and training experienced devs ain't cheap.

[@06kellyjac]

@@sk-sm9sh everyone I've interacted with who've spent a just handful of hours with rust grow to love the syntax. It is objectively true that golang's if err != nil xyz blah blah. is easier for beginners to grasp than `?` because `!=`, `nil`, `return` are concepts someone is bound to have picked up previously, ? is used for many different things in many different languages. But there's a reason why goland goes and hides all that guff doing essentially what `?` does in the first place.

[@michaelz8260]

"Rust provided us with an incredibly solid foundation" Never again...

[@ThePrimeTimeagen]

haha

[@Originalimoc]

What happened?

[@Holobrine]

@@Originalimoc The Rust Foundation

[@creativecraving]

😂 Well, a solid foundation is quite antithetical to a startup, so that's not surprising.

[@rostislavzhuravsky3342]

One point that I think is really important as well is how many developers you can choose from when it comes to hiring and their cost. Usually Rust isn’t their first language, which means that a developer is likely to be a senior.

[@jk-pc1iv]

But if you hire for less seniority and js to be quick on your feet, do you re-hire once you decide it’s time to start building a solid foundation.. 🤔 everything will take even longer then

[@mario7501]

Fully agree with you "get it done first" mentality. Optimising before you have anything useful not just makes you waste time on low value things, it also burns you out because you don't really have anything to show for a very long time. Writing rust feels like writing a decluttered version of modern c++ which doesn't carry decades of baggage. It's truly amazing and if you look at where modern c++ is going for example it feels like they are trying really hard to be more like rust. The only thing I miss when writing rust is more flexible operator overloading and function overloading in general. Generics are a bit lacking compared to c++ as well, but I guess that's where macros come in. Something I still have to take a closer look at

[@robrick9361]

C++ is always trying to be more like everything..............which is the problem. Gotta get every damn feature into the language. But the problem is that every standard does have some stuff that I like. So I guess I'm part of the problem.

[@not_ever]

This doesn’t make sense. I can’t wait for the, “I thought creating a start up in some other language and rewriting it in Rust would be a time saver but I was horribly mistaken” article. There so obviously are better reasons not to use Rust, I can’t help but believe this is Rustacean reverse psychology trolling.

[@ThePrimeTimeagen]

yes, the idea of writing a startup and then rewriting it in rust once you find your direction sounds like a real bad idea. it makes no sense (i should that out in this)

[@not_ever]

@@ThePrimeTimeagen yeah I heard you shout out. I agree with all your takes, except the Go thing, since thankfully I know nothing about Go. It was an interesting video about a terrible article. I just have a hard time believing the article was this awful by mistake.

[@echoptic775]

And people dont usually do that, but keep expanding using nodejs

[@Cookiekeks]

What are the obvious reasons not to use rust?

[@not_ever]

@@Cookiekeks I said obviously better reasons than the ones given. Not obvious reasons not to use Rust at all.

[@shaunkeys7887]

I find that writing in Rust dramatically increases my productivity during prototyping when using “unclean” rust (clones, extra loops, Rc, etc). When you’re still figuring things out, the “fearless refactoring” principle is invaluable, because I don’t have to throw out the entire codebase or spend hours or even days trying to figure out why the connection between these two modules no longer works. Rust Analyzer tells me *everything* and walks me through my execution and information flow, leading me directly to the problem. Every bit of time you lose writing slightly better code is immediately gained the moment you have to change a lynchpin module in your prototype

[@sk-sm9sh]

Have you been living under a rock? Static languages had been doing this for more than 30 years. If until now you chose to go with Perl-like philosophy of pulling strings together and "hoping it works" it's kind of your own fault. And even in most popular languages that didn't used to have static checking they got it solve. For example in case of javascript - google closure compiler enabled (if you learned how to use it) writing statically checked and sound code about 15 years ago - long before even typescript arrived.

[@zzzyyyxxx]

Exactly, just clone where required, get product market fit, then optimize. The difference with TS is while it may be fast at first, you literally can't optimize it later on (perhaps when your AWS credits run out after a year which is usually how long they give you them for) simply due to TS being garbage collected.

[@cherubin7th]

I stopped prototyping in python because I became slower in it than Rust. I learned Rust after years of using unhappily Python. I am just wired for Rust I guess.

[@zzzyyyxxx]

@@cherubin7th Same, and the frustration for Python begins from the toolchain itself. I was trying to set up a new project for some AI stuff and it was like pulling teeth compared to a simple "cargo new"

[@doxologist]

What I've started doing is creating my own boilerplate framework, where I define a skeleton I'd use for almost any project, built on top of existing packages e.g: REST (Actix), DB (sqlx), Errors (thiserror + anyhow), Integration Testing (bespoke framework), MQ (lapin). This helps me iterate really quickly since dev-processes can be easily documented, and we don't need to think much about the underlying technology, just write the business logic (endpoints, queries, etc). Once the startup fails we just move along with the same skeleton :) Quick.

[@bug3937]

Sounds good, would it be possible to see a repo of the basic skeleton starter?

[@jk-pc1iv]

Yeah share it 😊

[@nandans2506]

Its about libraries and community for me, typescript/ golang community, packages and libraries are so vast that there's very little custom things you need to build and get most things done fairly easily. This is very important for early stage startups with very limited resources.

[@Cookiekeks]

Isn't that true for rust too? There are tons of crates out there

[@Luxalpa]

I found Rusts ecosystem way more mature than javascripts. The main thing is that I don't have to dive through weird docs or simply no docs at all and I don't have to deal with monkeypatching etc. The Rust crates just have all those methods and you just immediately know if they are fallible, if they can return None, what kind of types they expect as parameters, etc. With any new JS library I first need to learn how to actually use it by trying different things because even with Typescript typings, they are very often inaccurate and very hacky.

[@TheMrKeksLp]

Rust's ecosystem might not be as big yet but the libraries are almost universally much higher quality than any other ecosystem I have seen

[@dealloc]

With regards to the two modes of Rust. One thing to consider here is idealistic vs. realistic. Ideally we would write things fast and make it nicer later. But in reality this is rarely the case, especially considering you're also building a startup. Let's say you wrote all your business logic with this mindset and you get to a point where things take up a lot of memory and you end up with slow hot paths. During profiling you recognize that the problem is that you're cloning things and passing them around. To avoid this, you now need to start pass references which means you're going to deal with lifetimes. Depending on the scale of your project, this can be a massive undertaking and not easily done in isolation. Anything that uses those APIs will also have to deal with lifetimes. That said, I love Rust and personally also take the approach to write quick and dirty code to get an idea, then later, once I've found the right approach, rewrite it with a nicer API and error handling. However these projects are _tiny_ compared to a lot of startups.

[@ThePrimeTimeagen]

i do this in small scopes though. i am totally on your team with this. I get the smaller chunk well thought out, then move into the more "beautiful / idiomatic" code. I would never do a project like this. I always do what i call shitty / not shitty coding :)

[@Luxalpa]

The advantage of using Rust here is obviously that you probably never actually optimize your code because it's fast enough from the get-go, while in garbage collected languages we need to optimize the hotpaths pretty much always as the GC makes things very slow. Also another thing I love about Rust is that you know while you're writing the code how to optimize it. Like, when you put `clone` everywhere you can immediately write the todos, and also when looking at rewrites later, you can easily find the places where you used `Rc`, `unwrap`, etc, because these things are all explicit in Rust.

[@dealloc]

​@@Luxalpa That depends on what you're doing. Clone doesn't always mean that memory will be allocated-it may very well be optimized away; it depends on what happens at runtime, over time, as you scale. Rust doesn't automatically make all your worries about memory leaks and CPU loads dissapear. Some things just cannot be optimized away by the compiler, and others may require a different approach to prevent these types of issues which can cost $$$ if you're not careful.

[@mario7501]

His analysis isn't wrong. But if you build your system in python and want to scale it up, what path are most companies going to take? The answer is they will probably build systems around python to prevent having to rewrite the entire code Base, creating more and more technical debt.

[@guycomments]

The technical debt is there whether you rewrite the code or not

[@JustinBarak]

Who cares if you need to rewrite it in 5 years when you’ve scaled up?

[@MrIlsundur]

If your solution to a scaling problem is changing the language of your code base, then you didn't have a scaling problem in the first place.

[@vikramkrishnan6414]

You first cache your reads, queue your writes, you split up the high volume stuff into its own service. When all of that stops working you rewrite in a new language

[@MathiasRitter]

You would be suprised how big of system you can make with python.

[@orterves]

8:56 it's true, the type system is a real draw of Rust - sum-types are massively underrated and I wish more developers were willing to put in the effort to understand why. I think the biggest benefit from Rust is how it has combined multiple concepts into one great language (with a few missteps to be fair, like Async), it has all you need to build solid, reliable, maintainable systems for any purpose.

[@syzore2]

I think he meant *Above and Behind the scenes* , which would be like above and beyond but behind the scenes in such a way that you don't event notice it..

[@rammrras9683]

I read that article one week ago and I didn't understand why he wouldn't recommend or use it again from the beginning. It's just one basic downside and a lot of great features expecially for his startup that seems to be around safety logins or something

[@Leto2ndAtreides]

When you're doing a new startup, it's good to prioritize just making things work. If you take the AWS credits... Again, you just don't know yet if your startup is going to live. Most startups likely don't come anywhere near using up their $100K in credits... Because they fail before that.

[@fiskegalendbpk]

I built a million dollar app in typescript, now all my dependencies keep deprecating every two weeks, what do i do? All my friends say I should refactor to a “real” language, but I can’t hear them over my soy latte and M1 ARM chip…

[@__jan]

Seeing the progression of Prime's opinions on Rust as he learns the language more has been interesting. At first sceptical, just dabbling in it a bit, still under the belief that other languages are just more productive and the safety/performance are not good enough to offset the supposedly lower productivity. Then as you start using it a bit more for more involved projects, those belief systems kinda fall apart when you realise you're actually just as productive in Rust, but you also get all the other benefits. Suddenly it seems like Rust has no downsides... why isn't everyone using this thing?!?! And now you're a full-on Rust propaganda machine. It turns out that a well-thought out static type system (traits and enums with pattern matching) combined with best-in-class tooling (cargo, rustfmt, clippy, rust-analyzer) is such a massive productivity boost that even with the lower compile times and "type juggling" you still end up churning out blazingly fast code blazingly fast. Last step is realising that the language is actually kind of incomplete and there are still tons of rough edges. However, seeing the steady progress without compromising on the core values of the language means it's only going to get better, and the future is bright. :)

[@ThePrimeTimeagen]

:) i like this answer

[@roblesrt]

Prime's tries things in Rust, so you don't have to.. err so you get better insights in Rust. Thanks a lot Prime for sharing.

[@SumoCumLoudly]

Rust analyser is not best in class, it's bloated and slow. Cargo is great, altho compile times are a joke. As someone who doesn't shoot myself in the feet, and who doesn't have any issues whatsoever with memory management, Rust doesn't really appeal to me. The only time I'd ever use Rust is if threre is a better library written in rust compared to the cpp version. This rarely happens.

[@neildutoit5177]

@@SumoCumLoudly what's your secret for memory management?

[@fulconandroadcone9488]

@@SumoCumLoudly say what you will, you almost never work alone and the amount of gunshot wounds I saw was immeasurable in js, you might be good but if language doesn't allow bad things every one will be good.

[@bsmithril]

I come from a place where I have no idea even remotely what "line didn't live long enough" could be referring too. I can see it being a good example of the compiler learning curve.

[@pangolinSoftware]

I like Go error handling. It does make the code a bit more verbose, but it's very straightforward, like all other things in Go

[@jasonwhite5578]

Yes, sir. The error handling model in Go forces the programmer to handle them, it provides transparency and is definitely not a weakness of the language.

[@CuriousSpy]

erm... No

[@mohdsalmanansari5992]

no

[@_slier]

the most shitty error handling in the universe..

[@avithedev]

Agreed

[@richardgeddes630]

The problem with using Rust or any other language sparingly, is just that. You won't become productive by "timid" programming. When you code, day-in and day-out, with a particular language, you become productive with it. Stick with it, the "muscle memory" will kick in.

[@___gg421]

Always find it strange when people try to choose the right language for a project when the right language is the one you know well.

[@georgehelyar]

I don't think writing it in one language then rewriting it in another language is a good idea for start ups anyway. You start, hire a few language X devs, get something working, then tell them to throw that away and rewrite in language Y, which they are probably not as familiar with. In reality these early decisions will stay with you for a long time so start as you mean to go on.

[@Luxalpa]

Exactly. I've been in 3 startups so far and they all suffered from this same problem: a few years after the initial launch of the product, their code is in very messy state. They don't even want to switch to Rust because all their devs are familiar with JS, their code base is far too large to change anyway, and it's so unmaintainable that even small changes take weeks to complete. Like, I know the Rust compiler is quite slow, but looking at how long some of these Typescript projects take to compile in the CI given their rather medium size, it's crazy.

[@joshuarowe8410]

I'm testing out Elixir and Phoenix for my backend so I can iterate fast. So far I'm really liking it

[@sandworm9528]

That's Erlang right

[@lod2414]

@@sandworm9528 same runtime I believe

[@lhd7105]

Hmmm has anyone written a guide/book that essentially lasso's together all the techniques that one can employ to rapidly prototype with Rust? And then in the advanced chapters show how to refactor the "dirty rust" code to something respectable. Maybe talk about guard rails or bookmarking code that are "dirty rust" so that you don't leave them accidentally behind.

[@MrVeps1]

I agree wholeheartedly that postponing is expensive. There's always something new to add, unfucking old mistakes that still aren't a huge problem will always just help you sustain your current revenue flow. Suddenly, you'll find yourself in your tenth year of your two-month refactoring project wondering why people won't leave you alone to focus on fixing ancient code. Technical debt is a real thing, and when it hits, it hits hard.

[@NickWindham]

I was about to comment, “Why not use Go as the happy medium?” Then you immediately launched into explaining exactly why. Thanks!

[@ThePrimeTimeagen]

i think go has a lot of potential

[@ducksies]

match is very common across post-ML functional programming languages

[@BlurryBit]

IMO it should be a case per case thing to decide the tech. Not every startup (heck, not two startups even if they are selling the same thing) are the same. Money, team, management are different. Even the customers can be different for different businesses even if they are offering the same thing (depending on what audience they are targetting). Don't Deny or Accept a tech just because someone told you to. :)

[@shivamjhaa]

"When you are building a product, boring is okay"

[@TheSkepticSkwerl]

at my work, when i'm building a product, probably 20% of my time is spent deciding how to write it. then i build it out. doing it right the first time has so much more time savings than anything i've ever noticed.

[@marusdod3685]

tldr: they were more in love with the language than the product they were building

[@AshleySamLeslie]

The best part is, almost 90% of the "pro's" and "reasons" to use rust, exist in Java, except that Rust is more performant due to absent layer of interpreter. So, as a Java developer, I am actually pretty happy here and have plenty of jobs to choose from :D And another point is... Java is actually very good nowadays and GC have been improved dramatically.

[@arturfil]

I know this channel is very pro Rust and I have tried Rust myself and I like it (dont' love it) BUT for rapid prototyping and also having a good dev experience and be able to train and hire I do find Go very easy to choose as a language. For me, in terms of syntax, has some similarities to typescript but obviously has a lot more features once you get to know the ins and outs and I would feel that it would be a good language to choose, to build a startup.

[@pascualsu]

I totally agree. I really like rust but I doubt I could ever be as fast at prototyping something as I currently am in go

[@peter9477]

​@@pascualsuFor me the jury's still out on that question. It feels like the only reason I'm not producing working prototypes in Rust as fast as I can in Python is my relative unfamiliarity with the right libs. Sure, I can write lines of code faster in Python, but then I need to test/fix/test/fix and deal with unexpected runtime failures because I was a bit too fast and sloppy. With Rust it goes a little slower up front but then just works. And when I need to refactor (mandatory when prototyping) with Rust it's trivial and with Python I'm back to test/fix/test/fix. So once I'm more comfortable with the right Rust crates I now expect to go faster with it than with Python even in the prototype stage.

[@michaellatta]

I agree you can code rust for early iterations using things like ARC rather than the super strict version. The challenge is identifying the risks and eliminating them quickly. Then rewrite/refactor as you progress toward MVP.

[@ericdonaldpitcher]

Slow iterations is a relative thing I suppose. How quick are you in your editor and how experienced are you in the language you’re developing in. Varies from developer to developer. The design phase is also a point where you should be able to determine if your product idea is useful. Figma has such great prototyping tools that it almost can feel like the real app were you to demo your idea to friends or potential customers

[@marcusrehn6915]

I like the fact that you pointed out that even if you are a good programmer in another language, that doesn't mean that you will write good Javascript. So finding fantastic rust developers who are also good javascript developers, and who are willing to even touch javascript, will probably be hard.

[@theplanebrain]

I enjoyed your prototyping examples using “clone”. It’s a great point.

[@alpsavasdev]

Love your thoughts. Very informative too. Thanks for these videos.

[@PouriyaJamshidi]

Nim seems to be a better option than Go. It has a better and optional GC, syntax, features and more mature imo.

[@s3dev]

There is Wails for Go UI. It's kinda like Tauri, but for Go and is amazing in combination with Svelte.

[@akshay-kumar-007]

No offense, but I don't understand why people have an urge to combine both frontend and backend in a single framework. I have written Django code for 3 years and I absolutely hated it(atleast writing UIs). There was always some complex JS/JQuery which I had to write. At that point just use a simple JS framework like Vue, Svelte or React. I code in React/Next.js and NestJS/SpringBoot(for Backend) and I really enjoy the separation it offers.

[@Ash-qp2yw]

@@akshay-kumar-007 Probably because that means using Javascript, which is a horrible language. I've specifically designed my current project around Go's built-in HTTP templates instead of working with something like svelte just because I don't want to have to work with JS or TS

[@s3dev]

@@akshay-kumar-007 You misunderstand. Wails is for Desktop apps. So with it you write a "backend" (that communicates with the filesystem, handles logic etc) an the frontend is separate from it. Wails automatically generates the bindings between front- and backend in a really easy to use way. It's not really "combined".

[@biskitpagla]

​@@akshay-kumar-007 Your frontend and backend is still separate in Wails. They just bundle the app down to a single native binary that uses the default webview of the platform. The last part is important here. People have use cases where you don't want to target the web but using web-related technologies is a nice way to go. It seems that you don't have this use case and that allows you to target the web the way its meant to be targeted. As for Django, afaik it precedes the JS boom of the last two decades. Almost no one was writing complex frontends back then and so it makes sense that Django doesn't play nice with the modern JS ecosystem.

[@akshay-kumar-007]

@@s3dev oh my bad.

[@floriansalihovic3697]

“Inherently colours your thoughts” - a valuable idea for a lot of people

[@RedHandedBug]

This video gave me the inspiration to make a startup in Rust.

[@ThePrimeTimeagen]

rewrite rust in rust

[@wlockuz4467]

@@ThePrimeTimeagen Isn't the Rust compiler self-hosted? so technically its already writing rust with rust.

[@cherubin7th]

@@wlockuz4467 Rewrite it again and again in Rust. XD

[@AdrianDiaz-ob8qn]

that fly-like thing at the bottom of the screen was triggering my anxiety levels to the roof, I think I need therapy now

[@highlyevolved4977]

For me, the biggest negative for rust is actually that it’s not statically compiled. I love everything else about it..

[@Cookiekeks]

What does that mean? Sorry I'm new to this.

[@Luxalpa]

It is statically compiled.

[@einfacherkerl3279]

if you read the book database systems by C J Date, the inventor of SQL, he clearly mentioned that STRUCTURED QUERY LANGUAGE should be pronounced as S.Q.L not sequel or "squeal".

[@sawood2010]

I used dotnet for my server because I already had years of xp with it and wanted to get my ideas off the ground. Dotnet does come with a bit of overheard, I'm learning Rust and hoping to implement it in the future.

[@uppu04]

Any good resource for learning rust that you recommend?

[@sunitjoshi3573]

I’m in the same boat. I like C#, but Rust just seems fascinating.

[@PotatoGameDev]

"Above and behind" seems like a fantastic porn movie title!

[@u9vata]

Why I choose to stay with C++ instead is because for me its just so much faster to develop. Rust I find more beneficial in bigger teams where code review would not scale well anymore... People also misunderstand why people use C++: I don't give a shit that I can shoot myself in the foot, I give a shit for zero cost abstrations that are FAST TO WRITE. That's all. This is why C++ and RUST live together and not one over the other because the reason why one picks up a tool is actually totally different. To be honest more web people pick up rust than C++ people I would say.

[@abhisekde6841]

I am building a product in my spare time in Go. I just wish Go had enums out of the box.

[@narekasadorian]

i think the article should be renamed "building a startup in rust while learning rust" if you already know the language, you can move really quickly...

[@orychowaw]

Sounds a lot like they decided to use Rust for their startup because they heard good things about it, but where not proficient with it. So they had to learn the language at the same time as building their value. IMHOP a) they would have been happier with using a language/tech stack they were already comfortable with and b) now that they are familiar with Rust it will be easier to use for a new startup...

[@herkulessi]

One important point is, you can (relatively) safely throw something together without any real error handling and stuff like that, because Rust basically forces the crate devs to write good code. The only time I managed to have a library panic was nesting Tokio instances... Basically telling async code to block forever...

[@dawngunz]

I would _love_ to see you give a solid explanation on how you perceive proper error handling. I'm still new-ish, but I dont really have an issue with error handling in go.

[@bionic_batman]

The core idea of Go to handle errors as values is great and it is a proper way to do error handling (unlike hidden control flows with try/catch and exceptions). Rust does it exactly the same way Some people just hate it because it is verbose Personally I find it a bit more readable than Rust "?" operator which often feels a bit like magic if you are new to the language although It essentially does the same as err != nil check in Go but implicit

[@BennyDeeDev]

I would love to use Go, but everytime I do, I just hate how much boilerplate code is needed to write some small task like adding a query to my Url. Then I just quietly go back to my TypeScript.

[@MarcosVMSoares]

Elixir you don't need k8s, it's faster to write even than JS, Ruby, GO etc because it's no OOP and not strongly type. And you have case/1 instead of match. And don't forget too, sqlx it's amazin but ecto ... and you have sandbox mode when testing.

[@zzzyyyxxx]

Elixir is kinda the worst of both worlds to be honest, no static types means there will always be some bug or another, plus not as fast as TS, much less Rust.

[@MarcosVMSoares]

@@zzzyyyxxx not fast as TS? are u crazy? Static type dont save you from bug, is much better to have good testing for that propose.

[@zzzyyyxxx]

@@MarcosVMSoares hahaha, static typing doesn't save me from bugs? Good one, I had a good laugh. Manual testing is in no way a substitute for something I can have the computer do automatically, like why would I manually write out data type checking tests? Waste of time (not other types of tests though of course) And yes, Elixir is not as fast in runtime as TS which when transpiled to JS runs on V8 and its very fast

[@MarcosVMSoares]

@@zzzyyyxxx ok with you say so ^^

[@TheEvertw]

5:00 - This comment shows that he was both starting a new company AND becoming acquainted with the language Rust. NEVER start a company on a language you are not deeply familiar with. You can not afford the additional risk.

[@tordjarv3802]

I love how you pronounce SQL (squeel), it is the first time I have heard someone pronounce it that way but it is way better than those that say "CQL"

[@peterdecroos1654]

go also has a garbage FFI. I think ocaml is a better middleground with the exception of the ecosystem being smaller

[@esra_erimez]

I'd go so far to say boring is good. We are migrating our backend from C++ to Go. I find C++ to be a waking nightmare with unexpected surprises and Go to be boringly predictable. I like Go because it is feature rich like Java and C# and at the same time natively compiled. It is unlike C# that is closely tied to the Microsoft ecosystem and unlike Java which needs a JVM.

[@ThePrimeTimeagen]

appreciate this

[@metaltyphoon]

Sorry but have you been living under a rock? C# is very much free from MS ecosystem only for more than half a decade. In fact I use C# from macOS do deploy to Linux environments on AWS 😂

[@RemotHuman]

I think you can compile java not to need the JVM but I'm not sure

[@jasonwhite5578]

@@metaltyphoon She doesn't mean that it doesn't cross compile, she means if Microsoft decides to stop supporting C#, you're done. Another thing that's nice about Go, I can download the whole language and have it entirely separate from anything Google. Don't even have to install anything on my PC. Just point an environment variable to the language folder, and I'm up and running.

[@hck1bloodday]

@@jasonwhite5578 since c# is opensource, you can say the same about it, download it, compile it and use it. also google is known to kill its products whenever it feels like, so I would be more worried about go losing support from google than C# losing support from microsoft

[@jaredsmith5826]

Hot take: language development for the last ~15 years has been trying to find the sweet spot in terms of how strong the type system should be. At the time Rust, TS, Swift, Kotlin, etc were being created we knew that Haskell was too much and Java/C#/C++ and the popular dynamic languages were not enough. Go is the outlier: a conscious rejection of the zeitgeist. Time will tell I guess.

[@akshay-kumar-007]

Go is perfect sweet spot for writing backend code. Change my mind.

[@jaredsmith5826]

​@@akshay-kumar-007 Imagine that you had to defend Go based solely on the support you get from the compiler/type system. Go has many many sterling qualities: fast cycles, simple familiar syntax, best-in-class concurrency primitive multiplexed seamlessly to real OS threads, solid toolchain/ecosystem, strong corporate backing, tons of pedagogical resources, etc. But all of those (except the first one and _maybe_ the second) are orthogonal to my point: you could conceive of a language that did everything Go does but gives you a better DX via a less primitive type system. Don't get me wrong, if you're asking me to choose a backend language in a carte blanche greenfield project I might very well pick Go, but if I were to design my ideal language it... wouldn't be quite like Go. Adding generics has helped a lot, but even Java had those in 2004. Still, in terms of what language to pick in 2023 it's a very solid choice, maybe even the best choice, it's just not the best *possible* choice. At any rate, my point wasn't even really about Go, it was more about how similar all of the other languages that came out in the same era are, and my stab at an explanation of why.

[@chh4516]

@@akshay-kumar-007 Try Kotlin. You get all the Java Ecosystem for free, have amazing typesafety, nullsafety, super readable code and a wide variety of options to solve your problems. It is made to be simple, beautiful and powerful.

[@boredstudent9468]

Holy shit that pronounciation of SQL...

[@benwilcox1192]

Anyone notice that when Prime highlights text, he always leaves out the first and last letter from the selection? 7:33 9:24 lol

[@batboy49]

I like writing Go code, I like writing Rust code, I like writing C Code, I like writing Python Code....I think I like coding ;) That being said what is the most fun? RUST just feels like APPLE PIE ;)

[@thomassparrevohn8577]

This is most common argument you hear when it comes to code for startups, but behind it seems to be an assumption that the main reason to do the start up it to get it it sold and move on hence architecture, longevity and future cost is of little or no concern. It's one of the things you normally look out for when assessing aqusitions or long term financing. Unfortunately there are often a common synergy between "startup" and people who specialise in financing startup's where immediate results are more important. Nonetheless 80% of the future cost relates to these decisions and very often the viability of the product

[@laughingvampire7555]

when the time comes to optimize for scale the decision is always to defer as much as possible, because coding time is always more expensive than CPU time.

[@stephenreaves3205]

wholeheartedly agree that Go's lack of UI tools hamstrings it in certain scenarios

[@jasonwhite5578]

But what language actually doesn't lack UI tools to some degree - they all do, even Rust. Show me one language that has the robustness of Go and at the same time provides the developer a cross platform UI toolkit built in, and I'll tell you you're high haha.

[@stephenreaves3205]

@@jasonwhite5578 rust wasm at least feels native. Doing any Golang wasm feels so hacky

[@DNA912]

real talk, I have a bachelor in CS and been working at my company for a few month. I still have no idea what I'm doing in JS

[@myname2462]

Well, JS is garbage

[@ernesto8738]

"Slower iterations" i think is more about "am i building the right features" not "do i have the right solution to this technical problem that itself is contingent on us having product market fit already"

[@diadetediotedio6918]

10:00 the definition of entrepreneurship

[@dn5426]

Go with a slightly better type system would be perfect.

[@PaoloCarraro-k9v]

ah... rust scares me, i'm in go... but the statement at 12:00 about go it's hard to not be agree

[@replicator__]

For me, Gos biggest weakness is that it misses so many nice syntax features I love in Rust. Macros are on the extreme end of that. Go is designed to be super simple and, for my liking, it compromises too many features for that. But I get the reason and understand why it's the case. Still, even with go modules and go workspaces it doesn't convince me.

[@NuncNuncNuncNunc]

Not sure what was being said about not being able to handle error in javascript with fetch_user. It would be either a Promise, an awaited Promise, or an Observable, and all of those have patterns for handling thrown errors. I'll grant that an '?' is more succinct than try/catch but that's it. If it's really a burden configure your ide to write the try/catch block.

[@grim.reaper]

This video makes me want to learn rust 😅. The channel itself was enough boost but Prime reading the article and explaining things I can relate it to missing pieces in Go …

[@nieczerwony]

So the guy just said:"F**k it, I'll build with Rust". Without actually doing proper recognition etc. You pick tools for the task not just random. Let's say I love chainsaw, and it's a perfect choice if I go to woods for some trees, but if I go to cut down some boards or plys, I'll take skill saw, not chainsaw just because I love it.

[@rohanpandey9957]

Basically he's talkin about not using rust before reaching the line of prime 😭

[@pxkqd]

I read this article a couple days ago as well. I don't know Rust well, I mostly do Typescript. And I disagreed with it. If you already know rust, use it.

[@bobweiram6321]

Most Rust programmers have never programmed in a systems level programing language.

[@owenwexler7214]

Got a backend rewrite in either Go or Rust planned for 2024 so this is very timely.

[@owenwexler7214]

Hmmm I think we are solidly in "it's time to scale"/"we have a solid direction and don't want too much tech debt" mode. Gonna do some prototyping with Rust and either Diesel or sqlx depending on the DX and if it fits our needs.

[@MrWorshipMe]

I'd use python for prototyping, then replace safety critical and performance critical parts with rust.

[@cruz9617]

07:31 This was literally me 🤣😅

[@ferretcode]

it seems like a lot of companies are choosing go rather than rust for startups

[@ggnorton7]

Realistically for a startup, MVP and all of that - just pick either JS or RoR, there’s really no reason not to

[@mattiasmartens9972]

My main gripe with Golang is the type system, particularly doubling down on Java's mistake and saying "not only is null always an option for pointers, but 0/empty string/empty array (sometimes) also means null". I also dislike that the type system is not covariant so a lot of things that seem obviously possible coming from other strongly-typed or firmly-typed languages just don't come out of Go. The latter part I can accept given Go's role as a builder's language. But the penetration of "everything is an implicit union with some kind of null value" is very dangerous, forces you to write defensively, and still causes production failures all the time.

[@bionic_batman]

> but 0/empty string/empty array (sometimes) also means null except they don't Nil is only for pointer types, strings cannot be nillable (and they definitely cannot be 0) The only issue is slices which can be both nil and empty but usually it is quite trivial to check for both of that cases by using len(slice) > 0 condition

[@mattiasmartens9972]

@@bionic_batman I did not communicate this clearly. I am talking about the values a primitive can have on initialization. In Go pointers are initialized to nil and all primitives are initialized to their "default" value (0, false, "", etc). This initialization, especially when it happens implicitly when declaring an object, is the source of many bugs. Maybe you will say it is trivial to avoid this, like it is trivial to check the edge case of an uninitialized array? It's true. It is. The problem is that bugs that are trivial to fix are also trivial to cause. Trivial bugs break production just as well as subtle ones. Better languages make it harder to write trivial bugs that compile.

[@bionic_batman]

@@mattiasmartens9972 I honestly disagree. Imo, default values are one of Go's best features and they are extremely helpful in actually avoiding bugs. You can always count on that your variables are initialized with proper defaults and not some random nonsensical data like in other languages or something like undefined (which is way worse). If I create a struct and I know that it is not a pointer I always can safely access its properties without breaking the program. Haven't seen any bugs caused by this behavior either.

[@mattiasmartens9972]

@@bionic_batman Have you ever had to deal with someone else's adapter code for mapping two structs of similar shapes? If you had, you might feel a tad less gratitude for golang's feature of helpfully allowing the programmer to omit any field. Allowing any field to be null is indeed worse. What golang's approach has in common with that choice is that it allows incorrect behavior to propagate throughout the system that could have been caught at compile time.

[@timseguine2]

You have been showing up in my recommendations for a while, but never clicked because a lot of the titles seemed click baity. From this video at least you seem to have your head on straight. So I guess I will be looking at more of your content.

[@ЏонМастерман]

The question is, what would he choose if not Rust ? And how worse/better his roadmap would be with that language.

[@tuskiomisham]

The only time not to use anyhow is if you're not writing fn main(). if you're writing a crate or consumed lib, don't use anyhow.

[@br3nto]

12:20 yeah rewriting and starting again in a new language is a pretty big call. At what point do you make that call? At what point is it too late? And it’s not just the code, it’s also the whole deployment pipeline, and any other tools you’ve written, and the people hired with the specific skill sets. And maybe the frameworks used with the two languages aren’t exactly compatible, so you may have to restructure the code too. Not that it can’t be done… it’s just a big call… Personally, I would only make that call if something had catastrophically gone wrong with the first language choice or the first choice was going to financially ruin the company or hold it back in some significant way.

[@JeyPeyy]

I haven't done much Rust, but isn't match pretty much the same as any pattern matching in functional languages like Haskell or F#?

[@nairjithus]

I get the developers love of rust but for a startup, I'm gonna defend this person and say that Rust is not a great choice for most (at least of web-based) startups. It depends on the product ofcourse. Something like fintech product, for eg might need safety and performance. For the most web cases, why not just use JS. And if performance is a serious consideration, just use Go. And if you reach such a scale that Go has become a bottleneck, then reach for something even faster like Rust. Engineering and programming language beauty is great n all, but frankly, the product's users mostly don't care about that. If a competitor builds a product with JS/TS with more features and iterates faster than you, then eventually you're gonna be at a disadvantage. Will the users then care if your app is 200ms faster? I doubt it.

[@deiminator2]

200ms is a shitton lol

[@nairjithus]

@@deiminator2 Probably. I was just making a point. 🙂

[@Luxalpa]

The problem is that you'll be much faster writing your App in Rust than writing it in JS. People put safety and performance as being separate from the code but that's not true. Every application has the same requirement which is that it works properly, and it just happens that Rust's approach to correctness is the quickest one for the developer. You can write super performant JS code as well and make it bugfree but that will take you much longer because you spend all this time dealing with code organization and hunting bugs and fixing issues and writing tests and debugging, etc whereas the Rust user only has to deal with the actual business logic of the program and can skip all those extras. And they get documentation for free as well.

[@nairjithus]

@@Luxalpa I don't deny the benefits of rust. But saying that Rust productivity is *always* faster than JS... I don't know about that. Long-term what you say is probably true, it'll be ultimately less time consuming to build and maintain an app using Rust. But when you start out, you're almost never sure the product you're building will work out. You'll have to constantly change. Rust will probably be a major productivity hit for such an environment. Being completely bug-free, or edge-case free would mostly don't matter in those situations. Unless your app needs to be extremely performant, secure, going to serve to millions right out of the gate or any other cases where Rust just-makes-sense - I'm not sure Rust is gonna be faster to develop than JS.

[@ykhi]

It was again super interesting to hear your thoughts on this!!

[@roccociccone597]

We use go for our APIs at work, I do like it. And it's a heck of a lot better than Java.

[@Danielo515]

You keep praising rust for features that are in other languages, that are better than rust in compilation speed, ergonomics and ease of use and quite good performance. Result was not invented by rust