Rust Absolutely Positively Sucks
ฝัง
- เผยแพร่เมื่อ 21 มิ.ย. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact - วิทยาศาสตร์และเทคโนโลยี
![ทททททททท #27 [หลุยส์ เค โตมายังไง ณ สระบุรี]](http://i.ytimg.com/vi/CaKoYw_Xmtg/mqdefault.jpg)
Who ever forced this poor java dev to write rust deserves a gold medal for comedy and a new position / job
"a new position/job" because you only ever promote people if they're terrible at their job
Promotion to customer
@@CielMC XD
@@araarathisyomama787 promoted to floor mopper
yeah blows my mind how they didnt even consider Go for this task. Not only is it syntactically similar of Java, its also better, blazingly faster & async/concurrency is Go's other main selling point.
Damn, being told that your language is overly verbose and convoluted by someone who likes *Java* really stings.
It truly is verbose tho, sometimes it feels like writing Java. Everything has to be .unwrap()'ed and type names can get annoyingly long.
@@harleyspeedthrust4013if you unwrap everything you can use anyhow and use the ? operator everywhere. For type names-you mean the multiple levels of nesting types? Personally if that ever happens more than once I just use a type alias for reuse.
If there is a lot of boilerplate you can’t avoid, you can write proc-macros, but those are REALLY hard to learn how to write. Not that hard to read, but there is sparse material to learn lol.
@@sohn7767well you start with macro rules, but yeah, there's a bit of a cliff to start with proc macros. Like a lot of things in Rust, there's crates you're expected to know to use, and it's really nice then... but otherwise it's a total nightmare.
@@harleyspeedthrust4013 why are you unwrapping everything
@@harleyspeedthrust4013 You don't have to unwrap everything. They discourage the use of `.unwrap` because it panics. Return errors: just `?`.
ADDITIONALLY... Who TF put an old C/Java dev on a project and forced them to do it in Rust seemingly against their will. 🤣
the one time tom was not a genius
The name... is The Primeagen.
I write Java at my job, but I was learning rust before, the stuff I am able to do with a garbage collected language seems downright illegal to me sometimes. I can feel this guy's pain. Cliche but I do feel like learning rust made me a better programmer in other languages.
Sounds like a hideous idea for a sadistic reality show.
the scrum master
Forcing someone who has never used Rust before to write production code with a deadline is complete lunacy of that company.
It's like making someone without license drive a 40 ton truck and then doing suprised Pikachu face when they crash on the first turn.
This is the real take
I think he assumed as an experienced dev, he'd be able to pick it up quickly
@@dipanjanghosal1662 Or maybe he knew it wouldn't be straightforward and was genuinely stuck.
When learning a new language most people tend to fall back on the experience/knowledge from other langs to make the transition smoother, which in some cases can be very difficult, specially with Rust, it requires a whole new mindset to approach it (not that it's alien or anything, just harder).
Either way, the company royally screwed up on that one.
@@dipanjanghosal1662which would have been true if he had been forced to switch to C# or even modern C++. Almost everything would work as he'd ex0ect with barely any new way of doing things. Just new library functions and minor syhtax differences. I did that and it's easy.
I need to change my way of working and thinking to do in Rust, what I can do easily in C++ and C#.
@@stacklysm I woudn't say it's the Rust, specifically. I had little trouble coming from Python to Rust, because I'd already evolved my way to a fairly Rust-like coding style independently to make my projects more pleasant to maintain. It's more that Java and Rust are more or less polar opposites in terms of what code patterns you need to use.
Rust's borrow checker does *not* like "Enterprise OOP" and Java was born in it.
Yeah, having to write performance critical, C-interoperable, multi-threaded, asynchronous Rust as your first project sounds like just about the worst case scenario, especially when coming from Java.
Is it easy to write C-interoperable, multithreaded, async Java code?
@@peter9477 I doubt it.
@@peter9477 Wouldnt be that hard if you know how to use the jni properly
The simple answer is you don't. You write most of your application in C/C++ then use jni to interop with parts that absolutely have to be written in Java. I'm looking at you Android windowing integration code. Yeah I'm trolling 😂
@@hilligans1 yes, it's pretty easy with jni, and I had to use it both "directions", but mostly calling java stuff from c.
poor guy bro. he just wanted to code in java.
99 problems, but a borrow checker ain't 1.
Stockholm syndrome
@@Spookyhoobster we'll see how smart you are when the unsafe {} come
I love the “You’re having a problem with rust? Borrow checker. That’s not your issue? Borrow checker.”
Reminds me how the C community gaslights me, when I complain about C's garbage collector not working as I am used to from Java.
classic
lol
C garbage collector? Wtf
@@JosueRodriguez08that's the joke
LMAO
At least it’s someone with experience and sharing a different pov
true
I doubt an experience of a java monkey amounts to anything valuable though...
@@vitalyl1327 Even if they programmed C for 30 years, you will still say the same thing if their C code after 30 years is poop. It’s not about the language. Stop the stereotypes. And I’m not even defending Java.
@@An7Hoang he did program C, a language not that different from Java. This guy have no experience whatsoever, he knows just one language (considering C and Java almost the same), no experience in understanding semantics fudamentally different from what he already know. His opinion is quite worseless.
@@vitalyl1327 C and Java are worlds apart, you have no idea what you're talking about
it's as if Prime starts reading a sentence from like 2 or 3 tokens in by predicting what he skipped, and it almost pays off in speed except for where he guesses wrong
probably true
chatgpt: We are not so different, you and I
I'm something of an AI myself
@@Phasma6969 Why yes, I am indeed prone to hallucination.
Tokens
In my last job, we hired a bunch of typescript devs and had them write rust. They picked it up quickly. The main reason why they didn't run into much friction while learning is because we supported them and the projects they started on were somewhat trivial in regards to how many rust features they needed to use to get them running. Asyc absolutely can be painful; even after using rust for 6 years in prod, I still have some hiccups with async here and there. Tokio and rayon however do simplify many of the issues with async and there are plenty of little idioms you learn along the way which help with the other rough edges in the language.
I feel bad for this guy because he's taking out his frustration on the language where it's obvious that the issue is with the person/company who forced him into this position. Yes the rust community can be a little bit dogmatic but what programming language community is not? Look a JavaScript for example... That language is such trash and yet so many people will swear by it.
When I started learning rust back in 2016, I "broke up" with the language at least three different times for at least a few months each time. Like the author of the Reddit post, I have been an experienced professional programmer for a couple of decades. I stuck with it on hobby projects and now I am able to use it professionally on more advanced projects. It would have been a nightmare for me if I had needed to complete advanced projects immediately using rust when I first started.
"Do the dumbest thing first" is also the advice you get from Casey (the Handmade Hero guy) as well as others in that space. He usually phrases it as "do the simplest thing" because you can apply that same advice to improve your initial dumb implementation after the fact. You write the code that accomplishes the task. You don't try to write the most optimal code, you don't try to write the most flexible code, you don't try to write the most elegant code, just the simplest. This tends to result in a happy medium of all of the above. It has pretty good performance because it's not doing things it doesn't need to (like managing a bunch of abstractions), it's pretty flexible because it's easy to read/understand a simple solution and modify it, and elegant solutions are often simple solutions too. It avoids the problem of trying to be clever when you really shouldn't be.
what the guy is trying todo is really simple and basic, rust just makes it complex
That is an argument against rust then, because it quite literally is preventing him from doing the simple things to solve the problem, forcing him to adopt some random paradigm to work around the borrow checker.
The thing is Rust actually pushed this guy away from a questionable design-decision, he just didn't realize it because most garbage collectors don't really have any opinion on how much *garbage* you generate; I don't even want to look at a dump of his java heaps.
He basically wants to keep a prepared statement around for the life of the program (thread), essentially he wants the thread-safe equivalent of Statement
@@DMitsukirules It's absolutely not an argument against Rust. There's this misconception that the borrow checker has some arbitrary limitations that other languages don't have. That's not the case. Rust basically just makes sure this kind of stuff is dealt with at compile time instead of chasing runtime errors, or data corruption, later.
Rust allows you to easily move that kind of check to the runtime. Just wrap everything in smart pointers with interior mutability (Rc) and you'll never encounter the borrow checker. Rust just also happens to be the only language that fixed raw pointers, because that's really all borrows are, which generally is the better solution. Not only is it faster not to have to do runtime checks, but everything you don't have to check at runtime will not cause runtime errors, making your software more robust.
A simple example: If you insert something into a Java collection while you're iterating over it, that's a runtime error. In Rust that's a compile time error. It's not hard to imagine a situation where the insertion only happens once in a million calls. Your Rust program won't compile until you come up with an actual solution. Your Java program will just occasionally crash.
Rust will occasionally ask you for more work up front, although that becomes rare with experience, and rewards you with faster, more stable and better maintainable software.
@@swapode What do you mean that's not the case? Literally the Rust specification says that you CANNOT write ALL safe programs that exist in Rust. Rust allows you write a subset of all possible safe programs. The borrowchecker, along with the other features from the language's syntax make it impossible to write certain programs that would be valid and safe in other languages, because Rust makes certain guarantees to make sure that ALL Rust programs are correct and safe. That is what the Rust people preach about all the time, right? So don't change your narrative now, the Rust language DOES force people to write things in a certain way due to arbitrary limitations of the language that exist to ensure that all possible Rust programs are safe, if you don't limit the things you can do with your code, you can't expect the compiler to be able to magically tell when something can go wrong, it's literally a feature built into the language. So yes, it is the case that Rust has built in limitations, and yes, I personally find it to be an argument both for and against Rust. You want a hobby project and you can take as much time as you want? then by all means, knock yourself out, enjoy Rust as much as you want. You have a deadline and you need to have your project finished to put food in your plate and pay the bills at the end of the month? Then it's not like you can allow yourself to take your time, right?
and about learning rust: i took it like "i don't know how to write code, i don't know anything about rust, so it's a great time to learn". so i started to learn rust with a near blank slate and then i was like "ok, this is familiar on how i've seen in typescript". thus, it was simpler to learn rust instead of being stubborn that "this works in X, it also has to work in rust"
It's a really bad situation for the OP. Most new languages seem to take the approach of "easy to learn, a lifetime to master", and so it's easy to make the mistake with rust that you can just jump into a project and muddle through and learn as you go. One of the tradeoffs rust makes is its incredible steep learning curve in the beginning, and the overall complexity and number of features and unique design patterns that you have to be aware of to make any progress early on. The other issue is that since it is still relatively new there isn't as much support available online.
This is why I love good old C. It does take a lot of work to learn but once you've put in that work it doesn't magically change.
I think being tossed onto any major project not knowing the language and needing to get something done would be frustrating, rust or not.
Cause you would want to do it the ways you know how to do but this isn't that same thing.
I was ready to shit on this from the title, but I get it. Rust is great if you can shape the problem you need to solve into what Rust is made to be good for. Sometimes, you don't want to. Sometimes, it's not worth doing so. In either of those cases, I'd agree that Rust is not the right solution for your problem.
I don't want to do game dev stuff in Rust because games require really complex state management and interactions that you *can* translate to the Rust way, but like, fuck that.
I still absolutely adore it for my pentesting stuff though.
My game dev experience is pretty tame for me. I'm using bevy and have never touched lifetimes
@@yuitachibana8829 If you ever do touch lifetimes in Bevy you're either doing engine development (and deep internal stuff), or you're trying to approach a problem with the wrong mental model. But Bevy is an absolute treat as far as (code-first) game dev goes.
Game dev in rust is a nightmare, at least if you don't want to use an engine that does all the state management stuff for you. The traditional ways of structuring your game don't work and you need to do everything completely differently
Idk, writing a game engine has been a pretty good experience, much better than my C++ attempts. Borrow checker is just gone after like a month of practice. I honestly can't understand why everyone is saying that Rust is bad for gamedev; y'all trying to overengineer it with inheritance and shared references but can't, or what?
@@theultimateevil3430
> y'all trying to overengineer it with inheritance and shared references but can't, or what
I saw at least one guy doing exactly this
I love how he says "I wish Rust wasn't hyped as a fast language" and then a comment on the Twitch stream says "BLAZINGLY FAST!" 😆
Nothing wrong with code in Java. It pays you better than most jobs out there. Dont fall for a bunch of kids on the internet hating on the language. What matters is the job should be done.
Yes this. Enjoying a language at an academic level is fine and a good time but when your livelihood depends on it, why should people be criticised for making good decisions for them and their families?
Java's a nice language. It's boring which is the biggest compliment I could give any language. The library ecosystem is mature and rich.
I have always found the strong opinions on languages very bizarre, tbh.
If you're a software engineer and know what you're doing, any language you have to work with (provided it's not Brainfuck or something) should get the job done.
@@Meta7 Agreed, I am indeed a Software engineer and I used to work with Java (now C#) but getting takes from someone who is working at Netflix is bullshit. Although it is mostly for views.
@@Meta7 Yes, but doing it in Java simply isn't fun for me
I only have 20 years of experience, and my first Rust project was a Linux window manager. I completed it just fine... I don't know if Rust sucks or not, but I won't use it anymore unless I am paid.
For X11, or what?
@MH_VOID yeah it only works with xorg right now. I am collaborating with someone to make it work with Wayland cuz that is just sort of beyond my expertise right now. But I'm trying to learn!
my first real OSS contribution was an X11 WM written in rust too, and i actually came away with the opposite conclusion. now, a project being written in rust makes me *want* to work on it lmao
Good for this guy. It's hard to voice an opinion that's against the grain like this, but sometimes you don't have a positive experience with the technology. I have had the same experience with SvelteKit
i really want to love svelte/sveltekit but resources on it are so scarce
@@misteki Same here. It's understandable as it's a newer framework, but it's difficult to find information sometimes, even in the docs
@@raenastraIt doesn't matter if it's good if nobody can use it.
What don't you like about it? I really like it from an outside perspective and I'm planning on using it in a pet project
@@asdasddas100 I like the framework overall, but there's a few things that frustrated me on my last project -
1. Ecosystem and design are not very mature yet. There are a lot of nice features, but "basic things" still feel like they need some time to be ironed out - docs included
2. The client/server loading model is relatively complex, which is fine, but it's difficult to understand edge cases when the docs don't go into much detail. The "magic" is nice until it's not, at which point, the docs aren't strong enough to catch you. There are a few good YT channels that save you here though
3. There's still no official method to auth guard a set of routes
4. Also no official way to handle client-side form validation, which happened to be a big part of my project
5. No official internationalization yet
6. The multiple layers of build steps (TS transpilation, Svelte compilation) make it difficult to debug with breakpoints
It's a good framework otherwise, and it's young. I think most of this will be solved in a few years, especially considering that it's increasing in popularity.
It's great for hobby projects, but imo the ecosystem and docs are not polished enough to scale as well as other options currently. Depends on your project's requirements and size though - I'm using it for another small project now, but would probably pick Vue/Nuxt (or a completely different language) for the next big project
I swear to god 6:41 is the reason I can't use Reddit. Redditor, make a point without using condescending rhetorical questions challenge (impossible). Just say "Hey man, sounds like you had a rough first go at Rust, sorry about that. I bet anyone with your requirements and timeframe would have a similar experience. Learning Rust takes time, and it's a shame your management can't seem to budget for that. For what it's worth, I believe that time would be well spent."
Shoutout to ZZaaaccc for doing almost exactly that _plus_ some really great advice.
also i love how they basically ignored the whole post. The dude isnt taking his time to learn rust... because he cant, he's got a fucking deadline, that is the point of the whole post lol. But alas, the redditor needed to make their snarky comment to feel good and get some internet points and completely ignored all of what was being addressed.
@@AlFredo-sx2yy To be fair, the OP started with "Rust sucks because my company's management is incompetent".
@@nikolaoslibero are you also going to ignore the main point of my post?
Anyway, putting your Rust scent aside, let me try to answer without triggering a nuclear reaction from you...
The complaints from the OP about his company management are secondary to the post. They are a big part of the story, but the main point of the post is that Rust sucks for production because you cant expect to make a product if you cant produce code fast. Do you think programmers eat air? You must put foodies in your tummy, thus you need to produce something when working on a project or you're going to have to start getitng aquainted with living under a bridge. If a company buys the Rust bs then yes, the company's management is incompetent, but Rust sells itself as something that it is not.
The company is the issue, not Rust. I'm 95% sure anyone would hate any language if they're forced to use it in their work environment.
You gotta be insane to take a Java dev and tell him to make production ready code in Rust.
I am completely jazzed that you are referring to SQL as "squeal". I've been trying to make squeal happen for thirty years.
I agree that rust is much for difficult than any other language i have learnt before. But the benefits are insane. There is a project (called MediaTracker) that takes 330mb idle memory. I rewrote it in rust (and added some features) and the damn thing takes like 12mb. I haven't even gotten to actually trying to optimize it. It makes me very happy.
I made a GUI program modeling a double pendulum as my first complex project in Rust and the binary weights 500kb, while working on both Windows and Linux with no issues
@@yds6268 Just curious what library did you use and would you recommend it? I'm looking to write something very lightweight.
@wrong1029 macroquad. Out of all Rust libraries I tried it was the easiest one to work with
What was the original language? 330MB sounds like a garbage-collected language is involved. C would be on par with Rust.
@@JodyBruchon it was typescript (obviously)
13:16 LOOK MA IM ON THE TV!! Thanks for the positive feedback for my feedback, it really means a lot to me!
I know that it sounds like React data management lectures with Rust, but that's because it's actually the same advice. Once you learn it, you're quick again, and you're also quick to point out when the rules aren't followed. In Rust, the compiler is another guru code reviewer om your team, but the compiler won't let you get away with it, evem for the time being. That's because although you plan to come back and fix it, you never will.
There are for sure some async skeletons that are impossible to know without understanding the async runtime and even then its overly difficult (IE: wrapping an async reader/writer, it's required to use the `pin-project` macro to persist your struct between polling calls)
realistically speaking about managers: if there's a "new shiny programming language" and it has a lot of hype, they're willing to give up everything for their team to work with that -- no matter how bad that is. and in a healthy team, the engineers has to talk about it, not swallow that. it won't hurt the business if the team won't go on the "i don't know the business nor the language" path. it's safer for business to go with "i don't know the business, so we're going with something we know"
It seems like the same exact arguments that were used to defend prolog are being used to defend rust. No shade on either, but prolog is very obtuse when compared to other languages. Once you learn how to use it though, your program is written correctly the first time. It's easy to debug, but difficult to optimize. Anything that you do to make the code more convoluted is an optimization step.
same thing with haskell for me. I feel great writing code in Haskell but if I come back in 3 weeks and look at the code it's completely unreadable
I don't know I'm kinda on this guy side. It shouldn't that much of learning before you can begin implementing code that isn't even highly performant. That just doesn't seem like is going to pay off to business. I mean it is going to pay off to you personally if you managed to convince whole industry that this is the way to do and now you manged to make entry level hard. If you don't need the most fast the most mem efficient code instead you need code that is fast to ship and easy to maintain then there is just a lot of options to chose from that are much easier to learn and write than Rust.
This exact thing happened to me...50 years programming Assembler -> C was the main arc of my career, at low level, (kernel or lower) then dropped into Rust.. It has some nice features but I felt I was working with both hands tied behind my back.
Same, both the depth of experience and the reaction to Rust. But I stuck it out for 6 months, got over the hump, and will never go back. It's been absolutely worth the effort.
@@peter9477Damn dude, 6 months? I had planned to put in a few weekends ...
@@hebestreitfan6973 That's enough time to get the basics, but nowhere near proficient, IMHO. A week learning Rust gets you maybe as far into it as a half day with Python. But keep in mind I'm an old guy now, so my brain cells aren't as malleable as they used to be. Maybe you can do much better!
It is curious how it is in fact harder to switch to rust when you have more programming experience. Rust makes it quite easy to dive into really complicated systems by "just adding a couple of crates". For any dev no matter the experience this may quickly become overwhelming, and then progress slows down. Rust has nothing to do with it as such, just slow down and avoid using the truly complicated concepts. Also, getting a faster CPU and SSD helps with compile times quite significantly.
I'm not so sure a beginner actually learns rust more quickly. But it is undeniable that a person experienced in other languages will hit speed bumps that the novice avoids due to fewer preconceived notions.
This is an enterprise environment. I don't think they're compiling on a Nokia.
@@gagagero You'll be surprised what kind of dinosaur poop hardware (as well as software) is often found in enterprise environments. And that includes Nokia.
#koreanadvice - just get a faster CPU bro.
The advice from ZZaaaccc is generally how I approach problems regardless of language. It's better to make things work and then refactor, because then you know what everything is supposed to do. It doesn't matter if something runs like shit the first time you make something, at least it's running and doing the thing you want it to. There are loads of optimizations you can do easily and gain a lot of performance, but doing it before you know you're doing the right thing is wasted time.
that's an odd way of working
the very first thing you have to do is to know what you're doing
why does knowing what you're doing have to come _after_ getting the code to run?
@@RenderingUser I think that's just a misinterpretation of what I wrote. You've certainly done things and ended up rewriting it all before. It's not that what you made didn't work either. It is part of the iteration process. Your code is never perfect the first time you write it.
There are also cases where the requirements aren't as set in stone. There may be complications that show up partway, etc.
I read in a youtube comment once
"We don't care how fast you can make the code not work."
@@CottidaeSEA "Your code is never perfect the first time you write it."
that's the part i think rust tries to challenge.
clippy handles most issues on my. i have to compile almost every time when i do gamedev
now i hardly have to touch the compiler until finishing writing several lines of code in rust
"There are also cases where the requirements aren't as set in stone. There may be complications that show up partway, etc. "
that much is true
but how it much it effects the initial plan depends on how fast the requirements change as the project is developed
@@RenderingUser If you're doing something new (which is basically any project worth building), there will likely be unexpected problems along the way. You run into those, work around them the first time, and crush them the second time.
"blazingly safe" doesn't quite roll off the tongue
Funnily enough, this is the crux of the matter I believe. Rust is C++ with training wheels. Just like Typescript is Javascript with training wheels. It does get in the way and slow you down. The tradeoff is long-term protection when you have lots of developers dealing with the code
The two biggest hurdles that should be a priority for Rust to get right in my opinion are: Async, still too immature, everything that uses async today requires a lot of work arounds and when you couple that with traits, and generics you get a huge mess. Macros aren't that great, they would be if they were a quick and easy way to get some stuff done at compile time, but they are limited to the InputStream you pass and don't know anything else about your types, are kinda hard to debug. I limit my use of them for VERY SMALL code generation, don't fall into the trap of instead of working on your problem you end up working on the thing that builds the thing that solves your problem.
So far I found that just letting go of ownership instead of worring about references and lifetimes helped me avoid cloning too much. But If I have to clone is not the end of the world either. Most languages do it all the time and perform just fine, no need to go optimizing too early.
I learned Rust by using it to build a project which needed to get done in 4 months. The program was multithreaded and needed to do some custom GPU work. It was honestly a fun time and I enjoyed the experience. I've used Rust for other stuff since then and I do like it but imo C++ is just better
What a rollercoaster of emotions!
Honestly curious, since I lean in a similar direction: in what ways do you feel C++ is just better?
Hmmm yeah i'm curious as well. Why is C++ better? In terms of DX, festures or support, or in which sense?
OP explain! Genuinely curious about your opinions!
Yeah that comment at 6:50 "you can just do that with Go", I can totally feel it. I've learned Go on the side when I went to school and it's so amazingly simple.
Some of my most enjoyable and successful programming experiences have been with the worst languages and environments. Free of being able to do it well, i had to figure out a way to do it at all and that became fun
Ive only toyed with basic rust for wasm and such so far. The errors all made sense (i didnt know answers, but made sense) but i find overall it is always better to get it running before thinking performance. Half the time it wouldnt matter, and the other half you have a working version to check against.
"I am having trouble with async in trait functions" That hits me right in the feels. AFAIK you can't use (even in nightly?) async in trait functions.
correct, async_trait or whatever the package is. then toss in impls and its a great day
It has been in nightly for a while(since November last year) . It's under "async_fn_in_trait".
@@dynfoxxis that a... Promise?
@@htspencer9084 What do you mean? Just look up async fn in trait.
I can related to the thread local issue. Sometimes rust doesn't let you write code that is perfectly thread safe, but every other language does. It feels like the rust compiler is pretty dumb.
Threading is very difficult to get correct. Most people even knowledgeable people get it wrong. The issue is that most other languages are not thread safe. They let you do things that are not correct. That can be an issue as it can cause random issues.
Rust does stop you from doing some things that are safe. This is due to limitations in the tooling and langage. When you get good enough you can force it or you can find another way to do it.
Like all things it's a tradoff. Do you want correct threading with some limitations you may have to work past. Or do you want freedom with the chance for threading issues.
If you have an example I could explain it better why they are unsafe if they indeed are.
I'm at the early beginner stage with Rust. I've read the Rust Book so far, and am trying to build a collection of simple 'toy' programs that cover the various aspects of the language. So far I have always had to 1) have a good go on my own; and 2) then go to the Rust forum to ask how I should have done it. Just like vim, Rust isn't obvious. But I'm also of the view, so far, that what Rust forces you to do is the kind of discipline that you should have with any lower-level language in general.
Re slow compile times, it's always the linking step, not so much the static analysis rust does in the compilation step (though that does come at a cost). Since rust can integrate with the superfast mold linker, this should not be so much of an issue.
My bren to smol for c++. Do i need Rust?
I have been a C++ dev for 20 years now but when larger scale chages are needed or with growing complexity, it always manages to kick me in the proverbial nuts. Sure i can sketch things out quickly in any number of languages but is it worth the pain afterwards?
"Rust is verbose"
- Java User.
I'm a Java user, and I agree. Java is verbose because it's precise. Rust is verbose because the compiler yells at you everytime you try to use the built in features because you have to catch every problem. Just casting is an ordeal and requires several things in a row and the docs/warnings still tell you that it's the wrong way to cast. In Java, it's just (typename). I also prefer actual object oriented languages because I was taught how to do it right. I don't like function-based code or builder patterns because it muddies the waters between composition and what is effectively "piping". To be clear, function-based is okay when it's f(g(h((x)), not x.f().g().h(). I can tell the first is piping results. I can't tell what's really going on in the second from a quick glance.
I'm a Java dev, and I'm working throught the Rust hello world tutorial and...
Yeah, the guy seems to be about right. :p
@@HrHaakon fn main() {
println!("Hello world")
}
Is very consise imo.
It's true that cloning is surprisingly fast. I had the same experience with Golang, where cloning structs is the default behaviour (unless you explicitly pass references), and the the fintech system I built in it was surprisingly fast, even though I avoided references a lot.
@16:38 what is this "Grug thing" which helped realize abstracting in Rust happens faster? is this an article about Rust with the Grug? does anyone know?
My absolute first Rust project was FFI between C and Rust on an embedded system and boy oh boy did I have fun
I feel like Rust requires you to know what you're going to make and what you're doing if you're making someone big. If you poorly structure your code, it can cascade. Going through the Rust book and the standard library can teach you a lot. I only recently learned what MPSC was, and it's great.
It did take me a few days to disassociate & from other languages use of it as a pass by reference rather than an immutability indicator. Threading and closure captures and lifetimes also take a bit to sort out so the code says what I want in a way the compiler can verify. The biggest issue has been the fact that rust structs behave as if continuous memory so if the struct is borrowed for mutation the parts are implicitly borrowed for mutation as well. Coming from languages that implicitly box their contents and thus allow different parts to be mutated separately. But, after a few days I am productive and love the performance and stability. If it compiles I can trust it to run well.
Just stumbled across your channel.. I love it. You speak volumes. I would say, though, that I noticed your pause with the 'I have to call a spade a spade.' Well, the guy that wrote this is more than likely a Brit, as am I. When a Brit says this, he means that he likes to keep things simplistic. It means, 'If I see a fork on the table, I will use it as a fork.' However, I have lived on the other side of the pond, and I understand that the connotations of 'spade' may differ. Brits are unaware of the derogatory sense of the 'clubs, hearts, diamonds' of it all. My line manager used that twice in Teams calls with our Canadian owners. The first time I let it ride and cringed inside. On the second time, I suggested that he remove it from his professional lexicon. I showed him a screen shot of what google thought of it. He was shocked. Keep the videos a-coming to share your insights... :)
"A swift death" means the same thing for both meanings of swift
I know I'm a week late to this but if no one at that company knows Rust well enough to code with it, how do they know it's the right language for the job they're trying to do? Shouldn't a subject matter expert be the one to suggest it in the first place?
The one thing I had to really work on, as a developer, "make it work, then make it pretty/fast/efficient etc"
I started to learn rust as a hobby, as a node engineer, in 2019. For the god sake there were moments when I thought I will go insane. You really need to invest ton of time to understand and get used to how things are done in rust and I will still not use rust for a full scale enterprise project, do not trust my skills. We use it for native extensions for nodejs with some success.
similar to my story :)
13:02 "I wanna help the guy get it up." -ThePrimeagen
"How are you with Rust?"
"I hate it."
"An experienced user then."
This was exactly my experience when trying to use rust. CLI apps are perfectly doable, parsing is excellent, but anything more complex that that and I was instantly running into libraries being way too high level and basic rust features not being implemented yet. (async functions exist, but refactoring into an async lambda is not allowed, what???)
I genuinely don't understand how people can program rust in its current state, almost every library < v1.0 and all the frameworks I tried feel ultra janky and hacked together compared to other langs. from my view it's the JavaScript of systems languages
Being sub 1.0 is just the fact that the Rust community is really strict about semver, which is the reason why Cargo works well in practice. Basically, the versions are for the sake of Cargo's SAT solver when it picks the versions of your dependencies, not for humans, and setting 1.0 before your project is basically a legacy library is strongly discouraged
If you want to know how mature something is as opposed to how long-term-backwards-compatible it is, you probably want github stats or crate downloads instead
then again Rust has the uncanny ability to adapt to what you need with macros. I have a template macro that lets me write async lambdas like this [stuff in square brackets is cloned]:
async_move_fn!([camera_controller, allow_mouse], |(_, (dx, dy))| {
// do stuff
})
It still has some limitations but really helps when the situation is right. All this to say - you're not entirely wrong. Using Rust seriously takes a lot of effort and pioneering spirit. "Janky" and "Hacked" aren't the words I'd use when stuff like Javascript and PHP exists, but you definitely have to get your hands dirty in a different way.
Here is the macro:
#[macro_export]
macro_rules! async_move_fn {
([$($var:ident),*] |$($param:pat_param),*| $body:expr) => {{
$(let $var = $var.clone();)*
move |$($param)*| {
$(let $var = $var.clone();)*
async move {
$body
}
}
}};
}
Wow you went too far comparing it with js
@@BosonColliderThat's a terrible solution to a manufactured problem.
Exactly. A cat clone needing 140 dependencies is insane while the entirety of coreutils (which has around 50 other programs too) is a whole 14 dependencies.
Completely fair reddit post imo, and great responses too. I came from Java also so I can immediately imagine he wants the annotated types to all be traits and impl traits, like having a phobia against seeing concrete implementation types.
It still makes my skin crawl a little bit to see the type of mapping an iterator. However once you get used to it, you realize concrete types are your friends in rust.
Type inference almost entirely eliminates the need for refactoring type annotations when changing the implementation, in contrast to for example Java where a "Map" type helps mitigate refactoring work when changing Map implementation.
Doing a butthurt rant on a language because of poor management decisions? I don't think that's a fair post
@@samcolserra2425 awww come on. Have a little empathy for the newbie.
@@samcolserra2425 Yeah how dare the guy to expect a language to actually be usable without becoming a cult member who writes nothing but it for half a decade.
@@zaper2904 That's not at all how I see it. I see arrogance and overconfidence. Just image for a second having spent two decades doing nothing but C and Java and then some smooth brained manager asks you to do write a multi-threaded database frontend in Haskell. No one in their right mind would even expect to become proficient enough to make the switch from imperative programming to pure functional programming in a matter of weeks. It's just a ridiculous mindset to start with. It's similar with Rust.
Any sufficiently complex language requires time to get familiar with; And the problem with veterans (myself included - I'm a professional developer for over 25 years, too) is that they expect to "just get it". They've simply forgotten their own struggles 20+ years ago when they were noobs and mentally refuse to accept the fact that they're noobs again. It's simply an unfamiliar language that works differently to what their brains have been wired to over the decades. C isn't immediately usable to someone who spent 20+ years doing Python or Matlab only. Java isn't immediately usable to someone who only knows ML and Haskell. It's just bonkers expecting to be able to solve complex issues in a matter of days in a language environment you never worked with.
@@totalermist Haskell is the example you're going with, really? Because both it and Rust are considered notoriously difficult to work on (with very low adoption rates to boot).
In the place I work I switch between 3-4 languages most of which I had little to no experience with before starting, saying a programming language requires an excessive amount of effort in order to familiarize yourself with when compared to other languages is a completely fair criticism.
If I was forced to use a certain language I’m not super familiar with and have a deadline I’d pissed af as well 😂
You don't like change if you stick with Java for 20 years. That is the main reason for the frustration that he has.
What was that grug thing mentioned 16:31 ?
I wanna know too
I am really into reading and i am curious what books can i read to be better programmer?
In fact, this guy as an experienced C dev will find it very easy to do with Go.
My experience with rust is totally opposite. I'm a Java dev as well. Sure unlike him, who was pushed to a complicated language for a project without learning it properly, I enjoyed learning rust and took my time.
I was fed up with hitting rock bottom on java. The environment of java is flimsy and terrible, the language Design leads to spaghetti code fast and the possibilities of optimizations is limited. This and niece features often includes stepping out of the language (jni, ffm, ffi) and the overall experience is often unsatisfying.
Don't get me wrong. I love Java I think the language is evolving beautifully. But the devs are to stiff to make big steps to bring the language out from the 90's.
Rust on the other hand makes stupid code Design a punishment. For example if you use mutable statics and there is a different way to do it rust will punish you with unsatisfying unsafe blocks until you scrap the mutable static and use a better approach. Or storing to much references somewhere leads to lifetime issues that force you to rethink and refactor. Most of the time the direction you where going wasn't the best.
TLDR;
Java let's you write spaghetti and makes it hard to refactor.
Rust shouts at you early that the path you are going is wrong.
There are two types of programming languages:
Either
#0, everybody hates
exclusive or:
#1, nobody uses.
I'm jumping head first into writing my own interpreter for a highly concurrent blockchain language and I'm writing it from scratch and this is my third/largest Rust project. I'm frequently fighting the borrow checker, derives and async functions (we've all found out that async can't be used in trait, unless you enable an experimental feature, we've all been there) but other than that compiler does a lot of handholding and it's very gratifying language to program in.
The take on telling your manager your skill set with said language is not good enough to get the job done.. for them to assign someone else, etc.. I think sadly would go bad in most companies. Most managers would not be like "Oh ok.. no worries.. you go back to some task, we'll find someone else who can do the job better than you.. all is fine.". It would be ideal if you could talk to manager/whoever and they would say "Hey.. we're versed enough to understand that these things take time, and Rust we're well aware of is a long learning curve for the best engineers.. so we're going to give you 6 months to get up to speed and comfortable, and then we'll start to expect some results." We all know that is NEVER the way things go though. Problem here is most managers/etc just expect if you're a senior eng with 10..20.. or more years.. you should be able to just jump in and learn as you're working and get up to speed in no time. Reality is it almost never works out like that and certainly not with a more robust capable language like Rust that really does take some time to learn and then be productive with before you can actually work on a project like this.
Systems programming is hard, and that is why Rust is hard.
Frankly, at this point i'm so sick of all "new" languages being the same that i'll respect anything that attempts something different
There is nothing Rust does that C doesn't do with less pain. New languages are like expensive phones: they may have utility but they're ultimately just a status symbol.
This has nothing to do with Rust and everything with proficiency in a specific domain. You can’t expect even a talented sw developer to pickup a totally new language , read the language doc, follow some tutorials and then expect to be proficient enough to work on some of the most complex aspects of software development. This would be the exact same problem for a skilled rust developer tasked to do a similar thing in Java if they have zero experience in Java development. Learning a new programming language syntax should not take more than a few hours, learning the ecosystem, the standard libraries, the canonical way to do things in this new language can take weeks if not months.
Ultimately this is shitty, substandard people management. This poor guy got setup for failure and eventually got disgusted to pursue experimenting with Rust.
I think Rust is a very neat language. But not for everyone, and especially if you are forced to use it, without any prior experience, in a complicated project that has to get done in a timely manner. its like throwing someone who has never seen water into the antarctic ocean and expecting them to like swimming
I would love to get tasks with a technology i do not know for my job.
I could have written this rant a year ago. I'm still slow with Rust, but at least it's starting to make sense.
Frankly, posts and articles describing how one language "sucks" and others are "great" are nothing but gibberish. Other than COBOL no language sucks. Some are great, others not so much. There are different philosophies that may suit different problems or different developer personalities, but having used dozens of languages since the 70s it's generally just creators using the "easy button" to create content about how any particular sucks.
hahaha... I like the one where the guy thinks you can go into your boss and tell them you need to work in the language of your choice. In my experience, someone else with more clout makes the decision and that's it. You'd be forced to look for a different job on a different project.
I don't program in rust. i program privately in C/C++ (though i want to get rid of the ++) and Lua/Ruby and professionally in JS (And potentially i will have to learn VB because of legacy support of our company for the old product). But Zzaaaccc there gave a generally good advice.
When you start out with a programming language that has an foreign concept to what you are used to or when you are generally new to programming, don't be afraid to write programs in a "dumb" way. You can optimize it later when you are done with your project or a section of the project. That advice is specially good in a professional environment when you have just a week to finish something when you are still not that experienced with that language but also have to maintain the software after the deadline.
Also i agree also with the video that rust should have been more promoted as a great type system. That it is "fast" comes basically automatically by being a language that addresses lower levels. And also when you are new to Rust, it does not feel "fast" (talking here about typing and not compiling or running right now. When i heard someone say "Rust is fast", that person also tried to sell me on the typing point and not just running/compilation. Though that person could be just the only one who tried to sell it this way)
I only learned a tiny bit of rust, but it felt that i wrote it way slower then when i learned C a decade ago because it tackles programming solutions in a different way. That does not mean it is either in development or running a slower language, it just means i have no experience with it.
I was a Java programmer, when I moved to Rust, it was the complete opposite of painful, it was exactly what I was dreaming it would have in Java. Async/await, Static Thread Safety, no GC, zero cost abstractions.
Has he tried using channels? When a thread that has a prepared statement wants to execute a query, it can send a message via channel to the thread which owns the connection. The thread which owns the connection can then send results from the database to the thread which sent the prepared statement via a channel. Or he can open several connections, one for each thread (definitely not feasable, bevause if it was feasable he would have done it).
Rust is a cognitive hog which to be fair has is place, but in my own experience that place is very niche. As an architect I'll rarely choose Rust over any other language for most real life high performance solutions out there. You know, we need to think about ease of maintenance as well. Rust has is place but I hope that place is far away from me and my team.
I've found Rust exceptionally good in terms of maintainability. Despite being not the most readable language, it's extremely amenable to refactoring (with the compiler effectively telling you when you're done), and unlike all the many other languages I've used in over four decades of coding, when it compiles again my changes work, period. Plus no matter how old the code, or how updated the dependencies may be, it will always still build. Also cargo test. And more.... so I'd disagree Rust code is even slightly hard to maintain.
@@peter9477 Well of course I'm happy for you if that's the case. The more power to you. But try something, run a survey with around 20-30 peers of yours and see how many feel as confident as you about Rust. That is my life and I can assure you that my survey results never see Rust in the top 10 of maintainability.
In the end, like I said, I may suggest Rust but only for certain specific cases where I know the benefits will surely outweigh the cognitive and maintenance burdens fro the teams.
@@peter9477 I've heard this a lot "not the most readable language". I mean, is german less readable than english? It is if you don't know the language. I agree at the start Rust was harder to read than going from python to javascript, but after you're mind starts thinking "in Rust" I would say it's *more* readable because you can relax the part that's trying to keep track of pointers etc. because you know the compiler has you covered. Then you can just start thinking in terms of structure and higher level architecture, and what it is you actually want to do.
@@kylezs I agree to an extent, but there are many crates from others where the complex nested types, lifetimes, etc, and especially use of some macros make understanding exactly how they've made it work extremely hard compared to e.g. if it were Python or C. That said, I'm only proficient in Rust, but not an expert yet so maybe you'd find that code quite readable compared to me.
Well in that case I hope that YOU are far away from any serious programming as well...
I like the advice about programming rust dumb the first time.
Premature ejaculation is the root of all evil.
I'm learning rust and suffer from the curse of trying to make things perfect the first time.
I have a way to trick myself. I have a script for creating new projects, it creates a directory containing an implementation dir, a notes dir, a couple of other things and *an experiments dir*. Initial implementations go into the experiments dir, that way the pressure feels off, and I feel like I have licence to just make it work anyhow
one of the notes in a pet project i have (that i'm procrastinating on right now) reads:
poc-fractal/ - P.roof O.f C.oncept crate for trial and error (t&e)
* examples/ - small scale t&e
* src/ - medium scale t&e
.git - large scale t&e
And by god the amount of diagrams i have drawn... i keep a separate folder for those, my notes are just in the top level for whatever reason along with the readme, and that's not even counting the actual documentation and comments...
Would it hurt to link the article on the description?
Nim's macro system is easy to learn. Compilation-time is fast and the release binary size is so much smaller than Go, for example.
Anyone have the link to prime reading the grug thing?
I think they're not making a good comparison to other languages. Yes, it won't let you do other things, but other languages let you do things that just don't work with zero warning.
16:16 "Zig no need big brain. Small brain good."
xD
I use Rust for real projects. You won't learn it overnight. I've been programming for longer than this guy, and it wasn't easy, but it was worth it. I haven't had any runtime issues.
I went from assembly to C and I thought it was the best thing since sliced bread. I had a massive struggle with Rust too. And yes multi threading in rust the way we pass things around in ac/c++ doesn’t work unless you either do unsafe or nest in Arc Mutex.
I’ll never be as fast as in C/C++ for sure. But I think it’s charming though but massive parallelism is enormously complex for sure.
I fell more in love with Zig because it’s so like C.
To be honest go seems like a very good option for a bunch of junior engineers, it's way easier to get onboard and get's 90% way there
Hello Prime, love your videos so much.
Not to be nitpicky but I just thought you might be interested.
At around 18:30 you said Traits are just Interfaces. Infact Traits are NOT Interfaces. Interfaces are types while Traits are predicates/types constraints over a type. They both address similar problems. However Traits are far more powerful. I tried to post a link earlier but the comment go deleted. But you can find a lot of examples for this when looking for Haskell Typeclasses vs Interfaces. Rust Traits and and Haskell Typeclasses are really the same concept with different names.
In Rust, we can represent interfaces via dynamic traits.
agreed, but if a crowd of 2k people want to understand them its simpler to use defined concepts is your head and say "they are interfaces, but really nice" :)
@@ThePrimeTimeagen good point.. I can see why you put it that way
My first thought when you were going through the first post was it was an attempt to leverage Cunningham's Law. But OP's responses make me think this isn't the case
Well yeah, there's a lot of hype on using Rust for everything now. I get it how project managers chase the new shiny thing. I got into it recently because of your content actually. Mostly. I still like Go marginally better but I've also used it longer. Go Workers are easier for me now so I'd reach for that before learning that specific branch in a new language. I'm not in a position though where I have to commit to one language as I don't code for a living. I just make my own tools occasionally when I need them.
"I get it how project managers chase the new shiny thing"
Personally I don't get it.
I can see why developers would like to chase the new shiny language but what does it bring to the project managers ? They will not be the one experiencing with it and it will probably slow down the project at first and may even represent a risk.
@@sacha9593 It's a box to tick: "Trendy thing" acquired.™
When a manager pushes an "innovative product" for the devs, the manager is seen as "on the ball" by the higher-ups. So when something gets delayed the manager can go "but I gave them the newest and best".
@@sacha9593managers don't know the industry they're in and just succumb to whatever marketing they're served
14:00 This is the lesson I've been learning from trying to port a 500 line Python project to Rust. I tried too hard to make a convenient struct to initialize once and share environment data between threads and functions, before eventually initializing the environment on a per-function/per-thread basis. It works, and now that I've read through the crate docs another two times, I've noticed the functions I was missing before to deal with the borrow-checker and lifetime loops I was encountering before.
The trick to really getting async is to just understand call with current continuation.
I accidentally paused at 4:03 and thought it was some kind of joke for like, 3 seconds. lol
I have more confidence in the code that is written in rust compared to any other language.
I have a team working near me (I handle a large test tool system so luckily I have the power to go "I'm not getting involved in that" when new projects come up). None of the developers on the project are python devs. They made the requirement that all parts of the system must be written in python. There argument was that python was better at math (can any python devs explain this to me?). The kicker is this project by definition is built for the cloud. They are now a year into developement and finding everything to be too slow. I also come to find they are just hosting a linux box 8 hours a day (work hours to save moeny) on the cloud instead of using micro services. To me any management team that starts a requirement document with the language that software will be written in that you are in for a bad time. I get this guys stress.
"OOP" isn't synonmous with the habit of Java programmers to create clusters or a sea of objects, never considering ownership and when things should go out of memory. That's a byproduct every object being referenced garbage collected. You wouldn't find any decent C++ programmer approving of (not) managing instances that way.
When I saw someone who have mastered the language get surprised by how it worked is when I knew rust is going to take some effort to learn.
I feel the guys frustration with what he calls gaslightinig. Rust and Julia both have what I call a toxic positivity problem. People love them sooo much it just feels nauseating. Kind of like scrolling through Linkedin.
I think it comes from how languages that are early in their existence often suffer from much undue FUD. This often leads to an overcorrection by their most ardent supporters, leading to a near cult like situation. This kind of mentality grows as the language gets more popular, leading to it only getting worse as you're always worried you won't be perceived as a "true" supporter, which is essentially the equivalent of being a hater.
This amongst other things is why I don't really enjoy the python community.
While it is true, in OP's case, the dude was just saying Rust wasn't object oriented. How is this gaslighting?