Why You SHOULDN'T Learn Rust
ฝัง
- เผยแพร่เมื่อ 12 ธ.ค. 2022
- @ThePrimeagen made me learn Rust so you all don't have to. It's a beautiful language but, like, use it responsibly. ❤️
#rust #typescript
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links - วิทยาศาสตร์และเทคโนโลยี
![[LIVE] : ONE ลุมพินี 68 | คู่เอก "พระจันทร์ฉาย vs โจนาธาน"](http://i.ytimg.com/vi/F3IM3w-XchI/mqdefault.jpg)
i would say one thing you missed one important point which is that the type system is the reason why so many people love rust. Performance is not the first reason why people love rust. And one interesting thing is that there is no equivalent in js. there are simply things you can do in rust you cannot do in ts / js for types.
but overall, i agree that you can just move faster in TS, but i am still on the fence if that _ackshually_ makes a software creation impact. TS has a way of building up and allowing for weird software quirks longer and sometimes those are very hard to unwind.
@ThePrimeagen This comment was blazingly fast
Were you as confused as I was when Theo said that Rust is not even faster than JS in the browser (at 10:18) ? So all those comparisons where Rust web frameworks destroy the JS ones are somehow invalid? Seriously confused.
@@vedrankaracic265 Gonna guess Theo’s talking about WebAssembly performance specifically, which is currently slower than running Rust on a server.
We all are waiting for your next vid: "Dont Learn Javascript"
Primeagen's next video: Don't learn JavaScript
I'd watch the shit out of that video
He already shits on JS/Node enough that it would be just a compilation of clips from his old videos 🤣
The whole video is gonna be: "Learn TS"
I'm glad that I thought about that seven years ago. Nice to see that I saved seven years of my life by not learning this type of crap. God bless us.
WebAssembly
It is almost strange to hear about people being blown away by how fast Rust is. This is how fast computers _should_ be. We've had decades of folks being so far removed from bare-metal performance that they really have no idea just how fast their laptop really is.
I agree with both of you. I prefer things like C over interpreted languages, but there's no comparison in the development speed difference
just not efficient to write assembly anyway
@@richsadowsky8580 The longer I am in this field, the more I disagree that dynamic languages make you faster. If your program consists of 4 lines of code then yes, dynamic languages are great. But as a professional developer (even if just doing it seriously as a hobby), everyone works on projects with way over 10k lines of code. The amount of insecurity wild bugs and time to understand or refactor literally anything without causing breaks left and right raises exponentially with the amount of freedom a language gives you.
I'm putting my money on a competent Typescript dev moving WAY faster than a competent vanilla JS dev (after the 2 weeks honeymoon phase of starting any project). Likewise I think a competent Rust dev will move faster than a JS or Python dev.
C and C++ are both faster than Rust. Cope and seethe. Computers aren't getting faster because of Rust, they're getting faster because of better hardware (duh). There are plenty of old C programs that blow Rust out of the water on modern hardware. It's almost as if a good programmer knows how to make an efficient program with the tools he's given... And when Rust limits your tool selection, well, need I say more?
Rust might be a Java 2.0 but nothing more.
@@richsadowsky8580 We should make new high level, high performance languages, like python, but good. Maybe the languages themselves could be made in rust
soydevs telling you to not learn low level languages should be a good reason to learn low level languages
"The fun of serverless is: if you have a memory leak it doesn't matter, the instance dies and gets remade"
The developer inside of me died hearing that.
Now it's not what Theo said, but I see a trend of his of... Don't learn or write Rust just use every tool and library created in it to make your language faster, more secure, more reliable...
Which is fair and makes sense coming from a Js dev lol
@@danielsVirtus Because JS devs can't code. They're basically script kiddies.
literally that’s it right there - he’s a developer, not an engineer. half the reason why every bit of software nowadays is bloat: “cuz it can be” smfh
@@NathanHedglin Agreed, it's been like that since the late 90's early naughties. JS Devs exactly as you said, script kiddies and always will be. They can't create anything from scratch as their dependency on dependency injection and external libraries means they are too lazy to code something for themselves.
There's too many frameworks and libraries out now which makes learning any language harder than it should be; as you have to first learn the language; learn how to implement the framework; learn the framework itself; then implement the libraries, and then learn the libraries. It leads to so much frustration especially when something breaks; as you then have to track down the bugs, fix the bugs, find new libraries if the libraries included in the framework have been deprecated..... You spend less time actually programming and more time developing / introducing new bugs.
Sure, it's "quick and efficient" however in the long run; you end up losing your knowledge of the actual language because you're too mentally invested in learning the framework relying on the libraries to guide you through taking shortcuts on the way.
The end of the day, there's a language for every situation whether Functional, Event Driven, Object Oriented or Procedural.
Every programming language is the same, just syntactically different. Once you've learned Low Level Programming; you can then really get into the nitty gritty.
This guy also isn't really a true developer; he's more of a designer / wanna-be Dev that's why he uses JS. Real engineers/programmers/hackers weigh much more, have beards with medium-long hair; look like Richard Stallman or Linus Torvalds and code primarily in C/C++, ASM, Python utilising Linux with a Tiling Window Manager for enhanced productivity whilst drinking lots of coffee and many many sleepless nights.
These types of guys, like Gabe said above, is the reason why most software is bloatware. Their software has the bloat so they can be lean, scalable, fast, and perform fast at the expense of leaking their memory all over the place. Same with scalability; it doesn't really matter. If you write your code efficiently and choose your tools properly, then your project will automatically scale regardless of what system you're on.
He didn't even understand what the borrow checker does lol... It doesn't manage memory
Learning rust has made me so much better at typescript and likely every other language
That's true for every rust-coder
Yes, Rust teaches you good habits. And also it makes refactoring so easy that I'm never afraid to change something.
I find that going back to Python & TypeScript after using Rust, I start seeing so many things wrong… Learning Rust and using it consistently for a while really opens your eyes to how much uncertainty there is in programming, and just how vulnerable we really are because we rely so much on software that can be so easily broken. It’s a blessing and a curse, because I sometimes get on the verge of a panic attack thinking about all the ways my dynamically-typed code could break and how I don’t have time to patch all the holes. That’s why I like Rust. It narrows down which holes you need to worry about and which ones you don’t. If you’re not doing anything weird with panic handlers or linking against other languages, all code where guarantees are not enforced are clearly labeled and easily found
This is what I was going to say, the reasons given here about why not to learn Rust boils down to, "because it is hard". How is that a legitimate reason?
@@eskomo34 I would think it's a legitimate reason when development cycles have to be fast and you're not building a critical system.
4:07. That mindset for JavaScript, "we don't care about memory leaks because the lambda instance doesn't live long enough" is a bad habit. Your code should not have memory leaks (whether long lived or not).
yup. Waste of memory and CPU cycles = loss of money
Couldn't agree more, when he said that I just had to pause the video and scroll down to find your comment, it really triggered me lol.
bro it only takes a hundred mb per tab in your browser. just buy more ram ok? /s
yeah these all sound like teenage excuses for why what theyre doing actually isnt that bad
Also, memory leaks in lambda can and do happen, and they cause some of your invocations to time out and your app to have sporadic glitches. An invocation lasts a short time, but the lambda instance can live for hours at a time. This spirit of "don't worry about memory" is fine, but it's careless.
Don't learn Rust. You wouldn't want to be mistaken for a real programmer
I write typescript all day at work, and whenever I can relax and code with Rust again in my spare time; it's such a ethereal experience. The borrow checker and type system helps you structure your code better I feel like and that experience carries over to my day to day work as well.
Pattern matching, The Result and Option enums etc are some of the most commonly used things I miss in Typescript.
Rust is slow to program in, and hard to get in, but when my company relied on typescript solely all of our critic services were error prone, after switching to rust we have a hard time coding and a easy time mantaining
"when I write rust, I feel like I have to think" - this dude
He should try C++ :-D
In terms of cognitive load, rust is not much different from c++ IMO due to syntax and memory safe rules.
Rust appeal is it's memory safety feature. That's it. Nothing else is better (maybe the crates package DX too)
I think the big issue with comparing JS/TS with Rust is that they're designed with completely different goals in mind. I wouldn't throw together a website in Rust, just as I wouldn't build a kernel driver in TypeScript. Learning Rust has given me a massive appreciation for how easy languages like Python and TypeScript make it to develop complex code at a rapid pace. However, working with Python and TypeScript has given me a massive appreciation for the level of safety that Rust provides. Rust is the only language where I have ever felt confident in my code working the first time around if it compiles successfully, and it certainly has made it so that I don't want to interact with C or C++ ever again.
Indeed! Couldn't agree more. C/C++ are dead with Rust - only their legacy remains. The first complex project I delivered with Rust convinced me of this - it never crashed, it never broke, there were no memory leaks - and it was efficient as can be sans assembly. There are tricks you can do in C/C++ that you might want to do in rust, and you can. unsafe is there for a reason. But the safety is amazing. I can't go back.
@@seanemery6019 I disagree. C++ will still be widely used for Game Development atleast for the next 10 years. Rust just isn't suitable for game dev unless you want to shoe horn ECS into every game you build and the libraries being lackluster. But in every other eco-system, rust makes sense and should be used over C/C++.
@@TopazCentuallasI’m interested to see how Rust progresses in the tiny embedded space. Ditto OS kernels. That’s going to be C (and C++)’s last holdout. And possibly games, where safety doesn’t justify the learning curve/people cost.
The problem is that when it comes to safety, Rust isn't even close to the only game in town, in spite of what its most rabid evangelists would have us believe. I'm thinking specifically of functional languages like OCaml as potential alternatives. There is certainly a place for Rust in the bigger programming picture, but as computers get faster and memory less expensive, that place actually becomes more and more niche. Back when you had like 4000 words of memory to work with, everybody effectively had to be a systems programmer, no matter what they were trying to build. But it makes zero sense to continue programming this way at a higher-than-system level for modern use cases. Having to care so intensely and directly about memory isn't anywhere near as important for general development purposes as the average Rust fan frequently argues. I highly recommend watching Rich Hickey's talk "The Value of Values" for more insight about why the prevalence of the imperative paradigm (what he calls "place-oriented programming") is not much more than a relic clung to out of convention, completely out of step with the needs of modern information technology.
@@macaroni_italic OCaml sounds really cool, but is a vastly different language compared to Rust. Rust offers performance 3x faster, meaning that for any kind of high-performance computing (kernel, audio processing, video editing, image processing, etc) it is the only memory-safe high-level option. Regardless of how good hardware has gotten, I doubt many people would choose to use a language that is 3x slower for performance-critical operations.
Most of Rust's care about memory is to prevent race conditions in parallelized work. Any language that doesn't offer this kind of memory safety is much more challenging to work with than Rust for these use cases. Compiler-enforced memory-safety to this level isn't something I've seen in any other language, although feel free to correct me if I'm wrong.
It's also important to emphasise that Rust isn't entirely an imperative language. It takes many aspects of its design from functional languages, in fact. If you wanted, you could almost entirely write your Rust code in a functional style.
This barely touches on the mind-bending nature of some functional languages. I spent a few weeks trying to learn Haskell, and the difficulty of accomplishing any kind of task that is remotely complex was extremely frustrating, even if I do have a massive amount of respect for the design. Maybe OCaml is different, but I haven't tried it.
Essentially, the reason that imperative programming is so popular is because it closely resembles the way that most people think about problems, even before they've started programming (consider recipe books, instruction manuals, etc). Needing to retrain your brain to solve problems with a completely different approach to the way most people go about it by default is a fun and challenging exercise, but I can hardly expect it to be something that all people desire to do.
I'm a backend dev and use Rust for very specific things. Recently I had to write a json validator for a batch job operation and it went from 10's of minutes to under 10 seconds. The json needed to be 100% correct, down to the types, and Rust was great for this sort of problem. Once WASM becomes more common, which is inevitable, Rust is going to explode in terms of demand and popularity.
What about Go lang
wasm is only %20 faster then JavaScript at the moment
@@Onrirtopia in the world of backend, we speak in terms of milliseconds for response times. That 20% matters. Considering how immature the technology is, even 20% fast is extremely impressive, and it’s only going to get faster.
@@marcusaccount1008 compiling a garbage collector into wasm and then running 2 cascading garbage collectors sounds like a bad idea. That's why I avoid garbage collected languages in general. They always introduce huge overhead and unpredictable performance. I think the creation of rust really is the last nail in the coffin of garbage collection. Ownership solves the same problems as garbage collection but better in every way.
@@marcusaccount1008 Go had a larger runtime with GC so isn't as compelling for WASM
Agreed with most of what you said but it gave me shivers down my spine when you said serverless takes care of memory leaks.
A car that only works for a year is a bad car, even if you don't care because you buy a new one every six months.
On the flip side, a car whose only purpose is to be run for 35 seconds shouldn’t be considered a bad car for not lasting 100,000 miles.
JavaScript wasn’t originally server-side, but having ephemeral server-side actions is a great option for expanding functionality without *really* forcing JS to be something it isn’t.
Other than that, agreed.
It's not a car, it's a cruise missile.
I'm pretty sure that efficiency is not the primary concern of a cruise missile.
Just playing devil's advocate.
I think developers have kinda lost the plot when they're defending language-inherent memory leaks, but maybe I'm just an Idealist for thinking that our tools shouldn't be broken by default?
He's not wrong, disposable containers really does mean you need to worry about it way less...
@@otockian until a very clever hacker comes around and forces you to worry about it
Learn Rust. As second laguage. This will make you a very strong developer. Rust is young - that's why it has such problems with tools or libraries also this reason why with Rust hard to find a job. But it still cool language that give more deep understaing how programs work, how memopry works, CPU, Garabage Collector and etc. When you are senior FE developer, you should understand this for fix perfomance issues or memory leaks or prevent it while you writing code / planing architeture.
The best that I like in Rust - it hasn't null pointers. I like it so much...
This is a good point. I'm a Front-end Dev, and one of the reasons I'm learning Rust is exactly to have a little more familiarity with the fundamentals. So far, it has been working (though I'm learning the hard way that Rust really HATES a few common abstractions, like trees).
Will it teach you more than learning C? And why?
agreed you could learn javascript without ever knowing what a stack or heap is. Learning Rust will make you a better programmer.
@@TerriTerriHotSauce Forces you to think about your programs more because C allows more shenanigans that Rust will catch.
@@TerriTerriHotSauce C doesn't teach you control pointers, you can lose your point and get memory leak, or you can get underfined behaviour with incorrect work with pointers and etc, RUST will control that with compiler
I think this goes in your reliability point but Option and Result are amazing. They can be a pain to deal with but you don’t have to know from experience where errors could happen, you know immediately.
Rust didn't invent this these are basic functional programming abstractions and can be implemented in many ways in TS
@@meppieomg yet it wasn't as popular or used till rust became popular
@@meppieomg I should've clarified. You can handle Option and Result really well In Rust with pattern matching as well as any enumerated type. Typescript you can't handle them as effectively.
You're all wrong this a functional approach. You don't know it but these are monadic types. Result, option, even eitherOr and different types come from a functional approach. It's great too see these being used mainstream. If you want even stricter type usages and slaps on hands for bad coding try haskell
One thing to add about learning Rust. Harder to get jobs. You will rarely find something as simple as a junior Rust developer role to fill.
I studied and practiced Rust hard. I know a lot about it. But getting jobs in the field was hard for me, because recruiters expect us to be senior developers with years of experience in the field.
If you just started in the developer field and is learning Rust as your first main language. Please study and practice another as a backup. Very few companies are hiring junior Rust devs.
One good thing to add on the GOOD sides though: as a Rust developer, you can be a backend developer, a game developer, a system's developer, an embedded developer, a front-end dev, a GPU developer. All with the same language. It is very easy to learn new frameworks in Rust because the foundations are very solid.
Solid point
What you're saying makes a lot of sense. However, Rust makes you a "better developer". Before Rust, I used Erlang and Haskell for the same reason while being Python/JS developer at my bloody job :)
It's hard to find a job on Haskell. Erlang is not that much better (even with Elixir). YET. I personally don't regret a single second of my time invested in those techs.
I would learn Rust hard by not with intention to get jobs, but with intention to build an incredible thing. Rust hasn't jobs because the market still loves the things that could be retrieved fast, the late capitalism urge for easy reproducible PoCs. There will be a time when rust will progressively fulfills the web and that will be the time when Rust jobs will pop up like javascript does nowadays, because once people were studying javascript past decade and a half its very much like you studying rust today.
ts is my main language to get job I always make cli to automate some simple task for me using c++ but now im convert all of then to rust bcs of crates and cargo package manager for rust no more problem having to go through internet to find c++ or c library 😂
true, i ended up getting a python job, but still code rust for hobby projects
My experience with Rust is it takes more time to code but less time fixing bugs afterwards. One way to think about it is the debugging process is moved from after the fact to into the coding phase ie the bugs are caught by the compiler and thus fixed immediately rather than at runtime. This is of course not 100% the case. But it is very hard to actually judge how much debugging/later bug fixing / customer issues you have saved by using Rust. Its similar to unit tests, that take work to create but reduce work in later phases, but is often hard to judge their usefulness as how much a unit test saves varies wildly depending on the type and complexity of the code being tested.
I think typescript is not synonym for safety. It's just checks your types in compile time but in runtime it's still javascript, I can still make the program do what is not intended to in the devtools.
it's not just that. being able to mess up a program in the debugger isn't really relevant. you can do that in any langauges. but because typescript has to be compatible with js, its type system catches much fewer mistakes than rust's.
What you can do in the dev tools is usually outside of the scope of any security specification. If your website can be compromised from the dev tools its not a language problem, its an implementation problem.
@@wlockuz4467 that's true, but, the language, by its weak and dynamic typed nature, been able to easily change the information sent to backends and also easily manipulate code execution in runtime, isn't a permanent language problem whatever implementation it has?
I've already read this argument, but it's incredibly flawed. Once you compile Rust/C/C++, you don't have classes, traits, structs or enums anymore, you just have assembly code that jumps all over the place, moves bytes left and right, and makes a bunch of syscalls to do stuff. It's a different story if you have a runtime with reflection where some validation can still occur at runtime, although I highly doubt there's any considering the performance cost
@@carlo7416 Your observation is inconsistent with reality. Yes, you can write assembly that sucks, but rust doesn't. The borrow checker doesn't allow it. Javascript has memory leaks. That runtime validation is far from perfect. Javascript eventually runs as binary even though it isn't compiled, and that binary is far less safe. Just because rust could theoretically be less safe doesn't mean it is.
Hey, fair points. I'm a TS developer learning Rust. For now I've been blown away by the performance. Last year did advent in TS et this year in Rust. I can run all levels in Rust faster than two or three in TS.
This being said, I think knowing even slightly a low level language is always a good tool in the toolbelt. It gives your this flexibility.
Finally, Rust contains a lot of useful primitives, tools as well as syntaxes (rust enums + match pattern is such a joy), and seing more and more TS devs trying it only means we will see more traction for these features to go stage 3, which is always a good thing, in my opinion.
For example, when I see the package ts-pattern I'm pretty sure the authors have dabbled in some low level language allowing for powerful type infering matching like Rust or Elixir.
The useful primitives are the primary selling point for me. I spent a month writing a macro system for Python to get something close to Rust's enums (a class required me to use Python) and I would have saved so much time and had cleaner code if I was able to use Rust's enums.
Also, Rust's Options and Results are the best error handling method by far.
Yeah, exactly why I am learning Rust. I just want to have a low level lang in my toolbelt. I hope no one asks me to write a web app in Rust
@@trickypr just use chat gpt to try to help you figure out why the code isn’t clean. Of course the information must be combined with outside research but it’s amazing
it baffles me how growing as a programmer and being a part of seminal works in the industry is such a controversial thing in the js world
I was tempted into learning TS actually but got put off by the lack of sum types. They are a drug. Once you try you never want to go back.
I find Golang easier than TS, yes it has some weird parts but they aren't weird in a complex way. You get used to them very fast.
Rusts borrow checker doesn’t just limit you - it also gives you the opportunity to have more control over how you design your data structures but the satisfaction you can get from that only becomes apparent when you become fluent in it
If not making unnecessary mistakes is limiting me then lock me up baby. I pull my hair at work for having to use JS
If you are struggling with borrow checker simply you can use shared pointer
The biggest issue I'm having with Rust is that half the projects I want to work on, the libraries are still experimental or one feature I need isn't implemented yet. With typescript, since there is a huge community behind it and many $$$ this tends not to be the case.
Like with npm you get a different experience? Most of npm packages are also incomplete or buggy
@@oleksiistri8429 At least they exist mate, I can bare with a buggy application because there's a chance I can fix it. But if the app doesn't exist what do I work on?
Btw I love rust myself just can't suggest it yet because yes, I've felt the lack of packages. I'd jump down to it in a second if the packages are there.
I'm gonna hard disagree on the DX with typescript. The headaches involved in making sure all of the modules you want to use are properly configured to be imported into your typescript and compiled to your chosen target tend to distract me terribly from the task at hand. I'm always getting unexpected import errors that I have to solve by downloading some kind of @types package which almost inevitably seems to be outdated or otherwise incompatible with what I see in the package's documentation. Maybe I'm doing it wrong, but it's been a lot more of an obstacle than an asset for me, at least on the back end. I did have a little better time working with it in Solid JS on the front end, though. Less dependency management issues, I guess because I used a pre-built config that was pretty good at solving module problems automatically.
For the record, I'm a full time front end dev and there's no worse developer experience
than having to download packages that lint and test. Then you have to compile ts, transpile to es3 + JSX and then bundle it all together. All of these packages need their own configs that sometimes don't work with each other (because you're on the wrong node/react/npm version) and also leads to 500mb node_modules folders in every project. You also need to know every single random quirk about all browsers + the language it self. No standardisation and not a good standard library either. That there is a library called is-object speaks volumes for the problems with TypeScript.
The NPM echosystem is a monster out of controll.
@@winterz32 Typescript is lipstick on a dead horse when it comes to beauty. Beats dead horse without one by a very long shot
@@winterz32 It has to die someday
lmao you say all that stuff like you actually do it manually. Frontend dev using modern frameworks is as simple as just running: "npm run build" and you are done. You may need to change the configs once a month, maybe, but it is only 10 minutes of work.
I have used Vite a lot, and now I am using NextJS at my workplace, and there is nothing complicated. "Downloading packages that lint and test"? - that's 1 single command. Configuring them? 5 minutes. Compiling and transpiling stuff? 1 command again for both at the same time. "All packages need configs" - a straight lie. Even if they did, you would only need like 3-5 minutes for each (4 total?) of them. "Don't work with each other" - use latest versions for everything, problem solved. "Big node_modules folders" - use pnpm, solved. "Need to know every random quirk" - a straight lie. You don't "need" to know it. You fix the things that come at you IF they ever come at you(nowadays they don't). "No standardisation" - I don't see why it is inherently a bad thing. "That there is a library called is-object speaks volumes for the problems with TypeScript." - there is also is-even package, but that doesn't mean any actual dev ever use it seriously. I can also create a library that just *adds two numbers* in Rust, Go, or any other language. It doesn't say *anything* about those languages.
Really you just cried in your comment for the sake of crying. People that just complain out of thin air exist and you are one of them. If you work with outdated technologies and frameworks, that's your problem. All of your problems you listed are either a lie or non existent in any modern web frontend framework.
Mr. "full time front end dev" probably still works with webpack and react class components, no wonder he complains. Either that, or this is a cry comment of a junior dev.
@@twothreeoneoneseventwoonefour5 Why in that case in languages like C# you don't need all of that crap? Tenantive answer: because all of that is useless BS
This sounds a lot like the arguments I got from Java developers 10 years ago about how Node.js could never compare to their rich, mature ecosystem. 😆
yeah, rust will definetly improve in usability / ecosystem with this boom of popularity
I agree with the java developers, I can't see any reason to migrate from something like Spring boot to nodeJS (t3 stack). Spring security and JPA alone convinced me to stay put. I haven't seen anything close to it anywhere else.
To be far most companies that matter are still using Java or C# on the backend. JS on the backend has always, and will always, be an awful idea. Node just lets you be awful and some companies just can't resist the temptation. Not only is JS slow, filled with more footguns than C++, and fundamentally broken - its also not good in the domain. C#, Java, or even Go are much easier to use for backend work. They're much more seamless and pleasant.
I think the mental overhead of Rust you're talking about is super common because it's likely still new. Like learning any new language, there is mental overhead. I don't disagree it's more work to build in Rust, but once you get over the learning curve, it's chill. Super appreciate this video! Thanks for the hot take!
For building any application that isn’t a toy, development within the Go ecosystem is far superior to the Node ecosystem (which includes TypeScript). Deno might raise the bar but it’s not there yet.
I'd throw up on ugly syntax
6 months ago I was about to learn flutter but then Theo made a big rant about it.
I was also thinking about rust few days ago. 🙂😶
Flutter is okay, rust community is growing as huge.
Very nice things are building on rust ngl .
Don't decide what you do or don't based other's opinions, especially influencers whose whole job is to make money while giving hot takes.
If you think something would be fun to learn and would be a great addition to your skills, go ahead and do it!
bro you're getting an opinion from someone *who doesn't even know rust, nor flutter*
if you're going to outsource your opinion, at least get it from someone who has used both typescript and rust
humans are lazy. they try to justify not doing things in any way they can to avoid the pain of learning, regardless of whether the justifications are actually true or not. this is why flashcards are not commonly used despite being scientifically the best way of learning (by a lot!)
But also don't base your decisions on online hype cycles. Rust definitely has its solid points but the fact is 90% of the people hyping it up are never going to get to use it for actual work. It has its niche (desktop applications, mayyyybe web backends), learn it if that suits you, or learn the language that suits your needs better.
Follow your intuition, not a TH-camr
Rust is one language I'd like to know BUT I don't want to put that huge effort to learn it, although if Mr. Primeagen made cool course I'd buy it
Not gonna sugar coat it; Rust requires a LOT of effort to learn, but it's worth it I promise
@@MrJester831 it doesn't require that much effort
@@MrJester831 Rust is not hard to learn at all, it’s just quite limited in features and is very confusing in respect to functionality. Features-wise Rust is something between C and C++.
@@MrJester831 it's not hard to learn at all, it's just too frustrating at the start because you want to write stuff and the compiler keeps complaining, but unlike other languages the warnings it gives you are actually really helpful
@@DaviAreias when I say that it requires a lot of effort, I mean that relative to other languages, to be proficient in Rust necessitates understanding a lot of concepts and active learning. Most languages people can hop in and just sort of passively self-teach themselves without needing to actively learn material, but with Rust it's basically a necessity to read up on things
Nothing about TypeScript is "runtime safety". It gives you more information at edit-time but it's all gone when it comes to actually running the code. It's still a massive win over JS but let's not pretend it's more than it is.
The problems of JavaScript ALSO are solved by c# .net7, super similar to typescript and if you need similar prisma like you have entity framework 7, I usually solve a lot of problems for a specific microservice written on typescript with replacing it with a c# microservice!
I feel there's two mentalities at work here.. Short term and Long term thinking. Theo is a short term thinker... This is the silicon valley startup culture of "move fast and break things". Then there's the long term thinkers. People who want to build super reliable super performant software that takes a lot of care to produce and they don't care how long it takes to write... I'm not sure these two groups will ever see eye to eye.
"I couldn't learn Rust so I'm just going to try harder to convince myself that Javascript isn't a piece of crap"
Yeah lost a lot of respect for him here. It's clear by how he described the borrow checker he made a half arsed attempt at learning rust.
Also adding type checking didn't 'solve' safety. Types aren't new and rust adds a tone of other stuff that reduces programmer error.
But the fact that i can create a simple SPA app without using a stupid framework like CRA speaks volumes about the stupid level of complexity in Js.
The reason you do less work in JS is that it pushes all the work into the future. In other words some other developers are going to be debugging all the bugs introduced by all the poor code structure when users test your app or new developers add new features.
When people leave companies every two years you need a code base that can be easily extended without breaking random things subtly.
Are you suggesting we all abandon our tools/languages and adopt Rust?
The data indicates Js/Typescript and PHP is still the best and fastest way to build web apps, they dominate the web development space for a very good reason.
@@depafrom5277 facebook rewrote a ton of code in rust for a reason, as your app scales it'll be a pain later to rewrite it in a more performative way, but good developers can get ahead of that by just writing the thing in rust from the beginning and not deal with the crap when it comes to scaling js
@@theinsane102 So what are you saying?
@@depafrom5277 that Js is best suited for some front end things and not everything else where people tend to shove it. i mean the thing is single threaded and people want to run backend with it. you save time and money by writing in a more performative language from the get go.
Great video. But I didn’t understand, what issues do you have with Golang. Can you elaborate further, please?
Agree with everything. One point that people usually make is that javascript lets you make too many bad choices. Once you start living with them and your code base grows, you will likely not be able to migrate to the better solutions. I think most devs are just tired of only javascript codebases written in some obscure framework and there is no easy way out in introducing the great tools that you would love to use. In a way, migrating to a tool like trpc or others is like migrating to a new language and in a way you start hating the ecosystem and want to move to a new language entirely (where I guess peer pressure plays a huge part in making you like something you don't truly like). Another thing as an interviewer is that the bar for js devs can be really really low so having someone who knows the best tools in ts/js and can make the best decisions out of the cesspool that is out there will likely make them equally expensive. And they probably know rust as well owing to their competitiveness and curiosity.
I started learning rust after watching this video.
Go lang doesn't have good PR, but after 1 week I am a about 80% as productive as I am in Python and Typescript, which is great considering the type system is really solid for what I need.
yea fr.. i dont get the golang hate, it beats all these old ass languages.. its fantastic for backend devel & automation of simple tasks.
Small and kinda dumb nitpick: Bun is a runtime akin to node/deno whereas V8 is an engine with Spidermonkey and JavaScriptCore (Rust has a JavaScript engine being built too with Boa). Mainly saying this because Bun uses JavaScriptCore.
It's an interesting perspective. I would argue that it's faster to write TypeScript because of the illusion of completing your code faster.
TypeScript, even being single-threaded, does not solve memory safety (null), generally allows you to not deal with issues that can come up during the runtime (but given enough usage, some will inevitably appear), does not solve data races when using async code (even single threaded).
It is faster to write TypeScript because you are writing an incomplete solution. And there is a place for that. When prototyping, there is more value in learning quickly how the user will interact with the solution.
In a production system, you will prefer an annoying picky coworker who makes sure you do :
- deal with situations that might occur
- document the owner of objects
And the rust compiler and clippy are quite impressive replacement for such a coworker. The number of false positives are relatively low compared to human review.
I would disagree with the idea that typescript is better for software that needs frequent changing. You will prefer an explicit documentation over implicit shortcuts as you move over the years of constant changes.
One thing I cant live without anymore after starting rust are its enums and the pattern matching. And I also have to agree with @ThePrimagean. After spending the last couple months with rust and its type system going back to other languages just feels so limiting and like I have to work with a discount version of a programming language.
Rust is one of the best languages to learn for fun, to really get the feeling of what an actually good and well-designed language looks like.
I wouldn't quite call Rust a "well-designed language", sure its got some great points, I like the type system, and lifetimes are an unique and very useful concept if you want to guarantee your code will be memory safe. That said, it's got some terrible points as well, for one, it is as ugly, if not uglier than C++, it is heavily lacking in ergonomics, to the point where it's almost like the language is hostile to the developer (for example, no default function parameters + no function overloading), it is extraordinarily verbose, macros are powerful but are about as readable as regex, and I could go on.
@@deadvirgin428 as someone whos only familiar with surface level C++ i think Rust looks a lot cleaner and readable than C or C++. Closures looked a bit awkward till i learned kotlin and found out they almost have the same type of anonymous functions too (inspired from functional langs, iirc) You have to understand Rust isnt a better C++ but rather a combination of C++ principles and modern programming improvements that have been proven to be reliable. Not hating on your opinion
You're right, just for fun. Definitely not for jobs.
@@randerins For now
Yep, and then after the steeeeeeeeeeeep learning curve you find you can't really use it for that much.
Thanks for the video! Would be cool if you can share your thoughts on elixir experience (maybe additionally comparing to Go)
I'm glad i watched the entire video! Good video, good comparisons. I believe Rust has more deep reasons than just those, and I'm happy to continue to add Rust on my Developer Palette. I feel like once I get over the first hurdle of "why is this hard" and understand most of Rust behaviour, i believe i can benefit from it. Not to mention that I absolutely love TypeScript. In the beginning learning TypeScript felt the same for me, like learning Rust feels right now.
And yes compile time (Rust) just sucks lol.
Thanks for this video!
Still happy with my blue stack, TS + Go. 💙
The "blue stack", I love it. I'm going to start using that.
I’ve made similar comments here before, but just to reiterate, the relevant metric here is the cost of bugs.
When you have a bug in the software you develop, a website doesn’t render properly. When I have a bug on the software I work on someone gets hurt.
If there is little consequences to your mistakes, you can afford to write lines without thinking, but IMO it’s a false equivalence to call those programs equivalent.
By the way, I totally disagree with you on the DX point. There was clearly an issue with your setup on the stream, I’ve had way more issues with yarn or npm than I ever had with the Rust tooling.
I also think Prime set himself up for failure by trying to speedrun you through Rust. It would have made more sense to cover the basics in terms of the type system and traits, rather than trying to cover lifetimes, Rc, concurrency atomics, … in 10 minutes flat.
The main reason for me (JS, TS, Java Dev) to learn Rust is to LEARN. For a couple of years I have been in a routine where I didn't learn "anything" new. With Rust I get those feelings again where I don't understand a concept and even get angry about it until it clicks and this is so damn satisfying.
I still agree to most of this. Rust is not for everyone, especially not in frontend development. But come on, saying "keep write shitty memory-leaky code - just use serverless" is absolutely not a good argument or a reason to use lambdas...
Front end developers won't be able to understand the real advantage of rust, because GC time does not matter in FE development. Rust is the only language on the planet who offers automatic memory management without needing GC.
From a Javascript developers point of view, I've heard most, if not all of the points you have against Rust when they talk about the experience of using Typescript.
I tried Rust a few times and my experience is similar to yours, there was too much friction, but I attribute that to me not really understanding how the language works. You'd have a point if we had some data on the development speed of experienced rust developers, but my personal observation is that experienced Rust developers are just as fast as an experienced Typescript developer.
In my experience it takes a while to reach one's usual development speed in Rust, but in the long run I think it pays off. I often also work in Python and while that's amazing for prototyping and feels really fast, in practice I get random crashes in many situations where the Rust compiler would tell me instantly where I did something wrong. Though to be fair Python is an extreme example, it doesn't even recognize typos in variable/function names until it tries to execute that line, which is simply insane.
@@SaHaRaSquad yes i have used quite a bit of python and it is completely the opposite of rust, you could almost mash gibberish on the keyboard and the code could run for days before it enters that path and crashes
I'll have to disagree with you here, Theo. Here are my counterpoints.
1. Rust is expensive at investment but pays off very well in future than javascript or typescript because it forces you to handle all exceptions and invariants at compile time. If you're a startup or too short on time or just program 9 to 5 for money, don't use rust. In many cases, node js can crash at 2 am and everyone will be losing sleep over why the server crashed just because there was an unhandled parameter in the request. Even though vscode warns you about (string|undefined) value in ts, you have to put an if statement to check that, in rust you can do that with just a question mark.
2. Serverless is a wrong argument against multithreading in rust, because serverless is more expensive than running an equivalent ec2 instance. If you used rust instead of javascript on a 2 vCPU server, you'd be handing out 100x more requests per seconds thanks to tokio than node js and that also on double the number of instances of the same app on 2 courses.
3. Also, why is theo talking about community efforts for javascript but not rust, He is not seen talking about the community efforts in creating tokio(an async library), serder(serialization and deserialization library) and sqlx(sql driver for rust with compile time checked queries without a dsl) for rust. You don't see that kind of community support for *any* low level language.
all fair but the first take is kinda not it cause you could just .unwrap() everything
JS/TS and Rust senior developer here. I agree with most points, except safety regarding TypeScript. TypeScript doesn't have soundness, meaning that just because you declared a variable to be of a certain type doesn't mean that it's really that type at runtime. I've had a ton of bugs where it turned out that the runtime type was different, for example if a non-TS library returns something that according to the documentation should be one thing (which I cast it as), but then turns out to also possibly be another.
This is a failure condition that simply doesn't exist in Rust. If a variable is declared with a type, you can be sure that it's that one and nothing else. This is why Rust code rarely does unexpected things at runtime, unlike TS code.
I think I used a debugger in Rust once in six years. It's just not necessary to observe runtime behavior, the entire code is predictable once you know the inputs.
It's a really bad practice to deploy code that has memory leaks and/or is not performant even with Lambda. Especially if scale or cost are factors in any way. I can say this confidently after working at AWS in a role where I routinely helped AWS customers with Lambda. Imho Rust is a great language for anything related to backend. I'm excited to see what will happen with front-end and WASM in the future as well.
Great video, thanks. While my whole team is considering and learning Rust, I am inclined to go more to TS/GO than there. If I can write utility WASM for web with GO, then I am all fine with doing it easier and faster, than to obsess with every little detail in RS
As a huge Rust fan I agree that you should think twice about using it in teams. It's time consuming to learn and not every project needs the performance. Though at the same time there's also its type system and the excellent compiler messages, which are features I sorely miss in languages like TS and which make refactoring much more pleasant.
the right choice.
it's a tough choice. despite being more complicated and time consuming to get traction, Rust will make your code base much more secure (and not just in the memory usage and leak aspect). the compiler guides you very well with simple, straightforward and easy to understand error messages, you use unit tests to verify the logic and functionality of your components, not to test if the syntax is correct, because if it isn't it simply won't compile. oh, and it's fast.
I think it depends on what your software is and how it will be used. I would use Rust for something like an API that receives hundreds of thousands of hits per second or a load balancer, but for a simple API with hundreds or even thousands hits I don't see the need for it.
I think in this case Rust has better WASM ecosystem than Go but overall I would choose Go for anything else
Using a garbage collected language in WASM has got to be the stupidest thing I've ever heard. If you want a GC language on the web use JS/TS. They're native to the browser, they'll outperform Go and it won't even be close. Running a GC language inside another GC language to talk to the DOM is dumb - it's like buying a Porche and then putting 13 inch Prius rims on it.
That TS crashing server actually happened to me. Idk why but one day I woke up and saw the server was unhealthy. Looking at the server health, it had exceeded mem usage like 10 times the past night. It also became just way to slow to run (4rps lmfao)
I needed to switch to a faster / more mem efficient language to solve for this. Rust was an obvious choice but I was still adding features now so I was kind of trying to avoid it. So Go was the perfect choice. It helped me write code that is both elegant && efficient. Ever since I haven't had any problems, but if I do start facing Go issues particularly in performance, then I might switch to Rust. But for now, I am happy with Go. If TS didn't fail, I would have probably continued to use that since "it just worked" and it was also a productivity boost compared to Go or Rust.
thanks for the reminder to subscribe lol. Your videos have just been popping into my feed without me subbing, so I haven't really had to think about pressing the button because it's so easy to watch the new vids without it.
Cannot agree, typescript is terrible experience
as a TS expert who also posts rust videos, I'd say that when you start out building a rust project things are a bit slower initially, but eventually you can actually start to move faster and faster. Having more fine grained control of traits, mutability, cloning etc can help you reason about your code faster in the long run, compared to a sea of objects with reference pointers where you need to be more vigilant with code quality. Having said that, for someone starting out and playing around with CSS and how html works etc, being able to use a partially dynamic language with fast hot reloading is a win. I feel like developer journey can be something like Python & JS -> Typescript -> Go -> Rust , getting more type safety as you get more experienced. Senior devs can operate in both worlds as to collaborate with junior devs. also wasm.
Great point about feature quality vs code quality. I'm interested into starting with Rust because it satisfies my OCD tendencies on code quality. I always have to be consciously aware of getting stuff working and usable first, to determine if that feature is even cohesive with the feel of the app, and staying away from tunnel vision. It's great to get tunnel vision on a killer feature once you know it's killer...but, in my experience, the best final apps are the ones that evolved based on usability and feature "excitement."
Very interesting video, thanks.
I don't understand why for the performance issue of JS/TS there is no mention of worker threads. We did not need lambda to have a way not to block the event-loop. Moreover, lambda (and other serverless runtimes, maybe cloudflare workers are an exception) have cold starts. If you write small functions, that you minify your code and tree-shake it, you might reduce these cold starts, but they're still significant.
Also, I am a bit worried by the advice regarding memory leaks. It makes sense to say that you shouldn't worry about memory leaks if you use a short-lived runtime (lambda). But it's not because you don't see the problem that it's gone. If you ever need to switch from lambda to a node server (yes, this does happen frequently and for valid reasons), you're gonna enjoy countless hours of fun solving these memory leaks. Maybe a better advice would be to learn to write code that does not causes memory leaks in the first place.
Nailed it. I also love how you created the scale of TS -> Golang -> Rust. That really is a great path to go.
Path to rust
Pascal -> C++ -> js -> TS -> rust -> ???
This is my way 🤣
I think rust has 2 main problem for beginners.
1. Borrow Checker, obviously. (But this got a lot better since NLL update)
2. Trait mindset, almost everything in rust revolve around traits. You need to understand its concept and principal. This concept help me immensely when trying to debug or modify an external library.
1. Pointer and smart pointer.
2. Cloning vs automatic Copy
1. Boxing, RC.
1. Closure, especially async closure which is FnMut
2. Async, with Sync+Send constraint.
how are these "problems" ? you're just listing rusts features. thats like saying interfaces, variables and generics are typescript problems
@@georgephillips6358 it's hard to understand the how, why and when of these features.
@@crasite skill issue
@@georgephillips6358 I believe he mentioned "problems for beginners" in the first sentence
@@stoogel yes but those are not "problems", they are literally just features. the problems is the difficulty to learn to understand the features.
7:05 I think this is true most of the time, but not all the time. Some things are much easier in Rust. There are many amazing built-ins. The standard library is way more extensive. Enums in TS are a dumpster fire, enums in Rust are beautiful
What's the program you are using in the video to write stuff? it looks so nice
Once you get used to it, it does not actually take more time to write code in rust. Just like any other language, you learn patterns. But the Rust patterns are different from what you use in other languages, which is why it feels very hard in the beginning.
I for sure agree. It took me about two months to learn how to use Rust, and about two weeks of those two months were spent learning how to make the borrow checker happy. Now I am able to crank out Rust code almost as fast as I can write Python. I don't use Python much anymore because of this.
Golang is fairly simple and relatively easy (for building web application). If you have strong foundation in JS it wouldn't take you much long to start developing with it.
Rust on the other hand is completely different. My god I got nothing.
It is not hard if you say it is not hard, it hard if you say it is hard. Have a not hard mindset and you will learn rust without problems.
@@pup4301 It's not hard. But my god it's frakkin ugly
@@ReyLamurin Naw go is ugly. I wish I could change how the syntax looked without making a fork of it.
If you come from the C/C++ world then you understand much of the reason Rust is the way it is because you are already accustomed to dealing with memory. I guess most programmers these days may have only had a class in college on it though and have only worked with weakly typed languages. That would make rust quite the leap.
@@entelin I came from the c# world. I just read the rust programming language book.
Great video! Just for curiosity, what is the website/platform that your are using?
Thank you for this video... I've had the toughest time trying to even read Rust code, forget writing something valuable.. I'm happy with the abstraction on top..
Good points. Athough, I don't think the "Rust movement" is targeted at replacing JS/TS stuff. It was more for C/C++ and other lower lvl languages.
I can see why people would want to switch to Rust from TS for every projects though, so that's why I think your video hits the mark.
Of course, this applies specifically to webdev.
I don't write backends in C/C++/Rust and a I don't write HPC software in JS/TS/Rust.
Everything has its place and right now Rust's is being an alternative, experimental system language.
why not write HPC software in rust? rust is a compiled language, it's perfect for HPC software.
Web backends are high performance, unless you run a trivial CRUD application. Servers, you know, actually do things. Maybe that's not the case for ToDo app #51, but for software that matters it is the case. Even just deserializing is extremely expensive. Even logging is extremely expensive.
@t3dotgg amazing depiction of product evolution with your graph. Also can you elaborate a bit on why do you consider golang a terrible language. Great video btw
I absolutely love learning Rust. I am using it in many projects. The time to finish a project is far shorter than in Python, Node JS, or PHP because so many issues are caught at compile time. And the efficiency is so much higher than Java or C#. What a superb language. I am glad we now have this memory-safe language to write actual machine code to run on modern CPUs without virtual machines getting in the way!
All the reasons to learn Rust....
Nice video...
Nothing less than expected from Theo video's
Rust is a poorer dev experience because most people write js/ts, hence all the libraries are written in ts/js. Also, TS is not as typesafe as their marketing promises.
I wasn’t really looking to learn rust but you’ve convinced me to do it anyway, it looks like fun.
prime after spending all that time teaching rust to theo: bruh
Learn rust right now don't wait, rust is hard but we have A.I and A.I is gonna take away a lot of the complexity of the language in a couple years, A.I is gonna turn developing in slow languages a really bad ideia.
I would say this to young developers who are willing to stay in the industry for long time. If you find learning Rust and low-level system programming difficult, that's a huge red flag in your career progression. What you're essentially doing is trying to understand complex math equations without basic math knowledge. If you've been paying attention to economy and tech industry, you would know that worthless fake jobs like scrum master, project manager, people manager, and etc are already mostly disappeared. If you only took some no-name coding bootcamp courses and stayed in JS frontend jobs, you know you're next in the chopping list. Start studying low-level system programming, various software design patterns, algorithms, learn C/C++ first and then learn Rust and/or Zig next. Stay far away from garbage collected languages for your sake. Don't let your brains rot.
What app do you use in your presentation? Looks neat!
Also depends on the dev. I'm learning Rust currently and somehow have the feeling that it better fits to how my brain seem to work :D
With regards to the DX I think we should separate out the language and the tooling.
The language is quite a bit more complicated than typescript and designing good API's is particularly challenging. Typescript is quite a bit better, but some of the dynamic stuff I encounter when js leaks through can really throw me off.
That said I think a lot of the difficulty comes from unfamiliarity. Rust has some rather unique concepts, that take a while to get accustomed to.
The tooling side is a bit of a different story. I really love cargo, but rust-analyzer has a lot of room for improvement and refinement. It is improving quickly though. I don't foresee it matching the massive investment Microsoft puts into Typescript but I'm confident that the tooling experience will get a lot closer.
Especially if you consider that its a very recent language, tooling will only get better.
@@jonnyso1 I don't think age is the deciding factor. More the nature of the language and the amount of resources invested.
Consider that Rust is older than Typescript and that the tooling for c++ is still significantly behind C#, Java, Typescript and co.
Great stuff. Developers should anyways be learning other languages to deepen their understanding. But when selecting a language for a professional project, be pragmatic and learn from folks who have been there.
I have spent time on TS/Flow professionally for few years and find that time I spent fixing type problems there are significantly greater in order to get it right (esp. when dealing with React) than in Rust, which I have been doing it professionally for about half a year or so. Once you get past the early learning curve of fixing type problems in Rust, you know right away what to fix and most of the time it's autofix-able. But slow editor response is real, and starting out will feel powerless since you have to to think more than you normally do in other language cause it forces you to, but once it becomes muscle memory, coding in Rust is BLAZINGLY FAST ... I would say it has the best ergonomic and fun to write. Just need to get past serious programming in Rust for the first few months and understand the basic concepts of it.
And for Golang, it falls to the category of "too simple" of a language where it makes your life hard when codebase grows, lots of boilerplate needed, which can lead to more potential to create bugs.
But with all that being said, I'm in the camp of don't fight the language. If it's designed for a certain job, use it for the job. I will not use Rust for web UI dev (for now) for serious project cause it will create massive headache down the line due to lack of eco and community.
What is a good developer experience depends on the developer. Easy and fast being "good" DX is not universally good to all developers, even though it might be to you. On the other hand, your graph curve between changes often and runs often is a very good point, and I would agree that Rust and languages like it are not ideal for prototyping feature ideas that may end up being bad ideas.
You could learn Rust because you love javascript so much that you want to make it better with Rust (like Deno, Turborepo/Turbopack, SWC and other tools). This is exactly my case by the way. I think that on the near future, Rust and Javascript developers will merge more and more together.
That's a really niche and yet pretty important use case.
Why are we strictly speaking in terms of web dev here? I don't see any pointers towards game dev or os dev here. What's the performance of TS like in game dev?
My main point I'm just trying to ask is why do we suddenly compare a C like language (a better one at that) to JS?
TS basically isn't viable for game dev nor os dev
I dont get what the issue is with go then, it seems to solve all the problems you mentioned quite nicely
i like how this video almost always pops up whenever i try to learn new rust thing lmao
I agree that some people may choose to learn a language based on trends or popularity, rather than because it aligns with their personal interests or goals. It's important to choose a language to learn based on your own motivations and interests, as this can help to make the learning process more enjoyable and effective. Additionally, learning a language that is truly meaningful and useful to you can also help to provide a sense of accomplishment and fulfillment.
random question but what tool is he using to write out the notes?
excalidraw
I started writing javascript when it was first created in 1995. It seems to me like it keeps evolving to patch its original problems (i.e. slow, and highly chaotic), but without ever actually solving those original problems.
Thanks for a great video Theo. As a TS dev looking to create a scalable Web API, you swayed me to stick with.TS for the immediate future. I feel it’s all about the goals you’re trying to achieve as well as having a great DX which keeps your momentum going forwards. Love your videos
Why the hate for Go? Please, make a video about it. My whole Company is using go in a dozen of teams, it is very popular in Cloud Native Environment...
Go's best choice
Yep, still gonna learn Rust! :)
The business case for Rust is very limited
The personal education case would be enormous
I feel the need(curiosity) to understand how a computer fundamentally works
As a bad estimator, I'll be proficient in Rust at 2026
C is arguably a way better computer fundamentals tool than Rust outside of the compiler
I generally agree, but I think certain classes of programs are easier to express in rust than in ts. Some examples:
- Comparing objects (structs) by value, or putting them in a set/map.
- CLIs for users that aren't expected to have node installed.
- Anything mathy.
- Any program where detailed error handling is important.
- [de]Serialization (serde is super simple and powerful).
Think how much could be achieved with Rust, if all the effort put into js/ts was put into rust ecosystem.
Let the poop throwing begin.
Hey Theo - Can you make a video on CI/CD in Web Dev land? I'd love to hear your thoughts. Thanks a lot ✨ !
I think you missed the point a bit. Rust is as priority number 1 a systems programming language. This means that it's primarily competitors are c/c++ not js. It's incredibly that it even runs on the web at all moreover even on part with js. When was the last time you saw a C program running on the web without some serious setup? The fact that you can directly compile rust code to wasm which *IS* the future of all web code is incredibly strong. Rust is one of the most portable languages that exists. That a so versatile language can't compete with a language that (primarily) runs on the web and undergone serious improvements over years is only logical. It's like comparing the first car to a specialty breed race horse.
the Stockholm syndrome is palpable
I had like a year or 2 of JavaScript/TypeScript experience, but it only took me a month of slowly writing rust to understand a lot of the main concepts, and be able to write pretty good code. But i can see how it can get hard, something i didnt understand is the issues you couldve had with the rust language server, its the best one ive used to date. Oh yeah also i like rust because of the smaller features, memory safety, and performance is a plus, but being able to create enum monads, etc. is cool.
@@Jon-ff7vd Mostly everything