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 - Наука та технологія
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.
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
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.
I love the “You’re having a problem with rust? Borrow checker. That’s not your issue? Borrow checker.”
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
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
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.
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.
"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?
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!" 😆
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
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.
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
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 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
13:16 LOOK MA IM ON THE TV!! Thanks for the positive feedback for my feedback, it really means a lot to me!
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)
I am completely jazzed that you are referring to SQL as "squeal". I've been trying to make squeal happen for thirty years.
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
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.
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
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"
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)
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.
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!
"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
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.
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.
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
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.
"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.
"A swift death" means the same thing for both meanings of swift
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.
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?
My absolute first Rust project was FFI between C and Rust on an embedded system and boy oh boy did I have fun
The one thing I had to really work on, as a developer, "make it work, then make it pretty/fast/efficient etc"
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.
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.
13:02 "I wanna help the guy get it up." -ThePrimeagen
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... :)
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.
"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.
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?
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 😂
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.
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.
@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?
I could have written this rant a year ago. I'm still slow with Rust, but at least it's starting to make sense.
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.
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.
"How are you with Rust?"
"I hate it."
"An experienced user then."
You don't like change if you stick with Java for 20 years. That is the main reason for the frustration that he has.
I would love to get tasks with a technology i do not know for my job.
There are two types of programming languages:
Either
#0, everybody hates
exclusive or:
#1, nobody uses.
Would it hurt to link the article on the description?
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 :)
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
Being thrown on a project, using language you've never seen, can be frustrating and painful. No matter what language it is.
Anyone have the link to prime reading the grug thing?
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.
Poor guy. I hope he didn't get turned off by this experience. I hope one day it will click to them
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).
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...
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.
The trick to really getting async is to just understand call with current continuation.
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.
I reminisce about the early days, when all the programming was done using sliced bread.
16:16 "Zig no need big brain. Small brain good."
xD
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.
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 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 have more confidence in the code that is written in rust compared to any other language.
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.
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.
Channelling Gilbert Gottfried in that intro, god damn
full channel :)
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.
Frustration posts about programming languages might be the literary form of our generation that has the chance of being worth preserving in the archive for the distant future super galactic AI.
I have no prior experience with rust, and I'm in a similar situation: we are rewriting one core service in rust, and I'm pretty happy with my progression speed and I'm very proud of the error handling and UX we are getting. Maybe this guy is uses to insanely fast development cycle, don't know
Rust brings the most experienced rock-stars developers back to reality that they know nothing.
And now you have a choice, give up or push through accept that your perception of reality you knew for 30 years was fake and rebuild a new reality that is way cooler than you knew before.
@@olafbaeyens8955 i would feel the other way around. These so called rock star developers usually do what you'd consider to be crazy unsafe tricks because they understand how the machine works on the hardware and systems level. Rust offers a level of abstraction in a really weird way that most developers have never been exposed to before, meaning that you are now forced to work around a system that doesnt really have a one to one matching with what your computer is actually doing. You can write systems code in Rust, sure, but now you're having to do it in a different way and far more abstracted way than you would if you were writing in C for example. For example, the borrow checker is an imaginary construct that helps you make more correct code, but some of the code that rust does not allow to exist and that you can make with other languages is code that might actually be correct and you might actually want to write precisely that kind of code because you know what it is going to do exactly on a certain machine. Realise that when you're working on an embedded system for example you are going to be dealing with tricks that you would consider UB many many times because you either work with no operating system so you own all of the resources from the amchine or you're using a very light OS thats basically a wrapper, thus you find yourself writing tons of very specialized code that are specific to what you are working on... The perception of reality they knew for 30 years wasnt "fake", it just was oriented in a completely different way to what rust offers. Rust's perspective does not align as well with hardware as the C perspective does, but that doesnt make Rust's perspective fake either.
@@AlFredo-sx2yyyeah, you lost me when you claimed you know something's not UB because you understand the hardware.
That's not what UB is, and it's not what UB is there to protect you from. UB is what the compiler assumes you're not doing, so that it can do all the optimizations when it's trying to make your code fast. UB is you breaking a promise to the complier, not secret knowledge.
There is a scale of embedded development below which Rust isn't really appropriate for, but it's pretty specialist: if you have megabytes of memory you probably are making programs large enough that the optimizer is going to do interesting things to your code, and breaking eg the aliasing rules or reading from uninitialized memory is eventually going to give you a miscompilation (well, except that if you have UB, it's definitionally not a miscompilation.)
The kicker is that most of the time, the valid implementation is not even much more work, and never has to be slower. Throw in a MaybeUndefined or UnsafeCell or use ptr::write instead of dereferencing. That sort of thing.
@@SimonBuchanNz Anyway, since you seem to be lost, here's a very simple example of something that is UB in an environment with an operating system is accessing elements in memory out of bounds, because your addressing space is local to your program.
In an embedded system without an operating system, doing this is not UB because your addressing space is absolute, there is no OS to give you a virtual addressing space, you can work with all of your memory map... this is how reading from pins is implemented, by literally writing memory addresses directly, which is usually considered UB when you are working in an environment with an operating system, but when that is not the case, then why would accessing a certain memory address be UB? If you own all of the resources and you have the schematics from the manufacturer then you know exactly what each address does on an embedded device, so everything is well defined for that machine.
In short... tell me you dont know what UB is without telling me that you dont know what UB is. Cheers.
*Whaaaahhhhh* Wow I wish somebody would "make" me use rust.
yes 😂
Like one friend of my said: "you can program fortran in any language" :)
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
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.
Plot twist, OP is prime.
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
I accidentally paused at 4:03 and thought it was some kind of joke for like, 3 seconds. lol
"swift death" < this is Time Cook for sure.
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.