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.
> 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.
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.
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 😂
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
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.
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.
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.
@@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"
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.
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
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.
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)
@@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.
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.
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
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.
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.
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 :)
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.
@@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.
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.
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.
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.
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.
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...
@@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
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. 😂
"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.)
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?
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.
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.
@@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.
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. :)
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.
@@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.
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.
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…
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
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.
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.
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..
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.
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. :)
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.
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.
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.
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.
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.
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.
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...
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.
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.
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 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
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...
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...
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.
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.
@@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.
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
Honestly I don't understand the rust hype, each time I see rust code I have a hard time figuring out exactly what it does, this only happens to me in one other language which is caml, on the other hand python, Java, C, C++, C#, go, ruby, Fortran makes sense, even assembly... This is probably due to the learning curve but man this does not seems the way. I hope that using AI assisted compilation we will be able to have a language similar to python without losing on performance or security.
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.
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.
"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"
On hiring: I feel like just where the ecosystem is right now people will take a job BECAUSE it's Rust. Yeah, there's less people out there who know rust, but the people who know rust usually love it and are looking specifically for rust jobs. I feel that you could actually stand out in this market by being rust-based. Also, imo, everyone should try to be language agnostic amap. But that's neither here nor there.
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 …
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.
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.
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.
This reads like why you shouldn’t pick a language you’re not familiar with for a startup. It’s not a personal project, if you’re learning on the fly that’s time you could have used to build a feature in a language you know better. No silver bullet essay basically explains there’s not an order of magnitude difference in most tools. Cost benefit probably doesn’t pay off in the short term.
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
I wrote a NEAT algorithm in python... I'll never do that again. Have no types is so awful, and I just end up with hundreds of print statements to look for issue as the errors were pretty terrible (it would error at a line, but that actually error would occur somewhere else usual because something outputted undefined) No way I could of done it in anything else tho. But I would of loved to do it in rust, if I had the foresight to learn it and wasnt on a deadline
Startups are all about timing and if something doesn't come through when you need it, you can always blame the language you're using. Not even just the language itself, you can blame its lack of adoption. I wonder what's the current state of hiring people to do rust. Can startups find rust juniors?
This person doesn't want to use _Rust_ anymore for reasons that don't seem to have much to do with _Rust_ . It's more a matter of being able to hire people who are as competent with _Rust_ as they are with _JS_. This is not a technical flaw but a market flaw: historically, _JS_ arrived before _Rust_, nested in universities and hobby clubs, spread like a swarm of Zergs, so that it is now a little difficult to switch to extremely better technologies.
I hate JS because it is too easy. Yes this definitely gives speed when building products but when you try to make things more performant then it becomes so hard. Let developers help to the compiler a bit.
