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.
@@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.
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.
@@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.
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.
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.
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 😂
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
@@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.
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.
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.
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
@@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
"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.
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
@@ShinDMitsuki 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?
@@tiranito2834 I highly recommend you actually give Rust a try, instead of making bold statements based on your misunderstanding of the marketing material and social media nonsense :-) Sorry, that may sound a bit harsh but it's rather obvious that you aren't talking from experience. What you said is true for safe Rust. But unsafe is there this very reason. It allows you to encode these kinds of programs in a way the compiler understands. That's really the thing about Rust. Talking about any aspect on its own doesn't do it any justice, it's how incredibly well those aspects interact with each other. I understand that it seems hard and like it has to get in the way, but if you're actually moving fast and actually care about quality, Rust is a massive productivity gain, because encoding all that correctness information in the type system once removes the overhead of juggling that information in some other way. Of course that's hard to grasp if you pretend like that information isn't relevant - or don't even realize that it exists. But that's how you get poor quality software. Seeing Rust's features as limiting is just such an odd perspective. Let me put it this way: The C++ community virtually banned the use of raw pointers even by seasoned professionals - Rust gives them to people who never programmed outside a JS framework and it's not a problem at all. The borrow checker isn't limiting, it's the ultimate liberation. The hardest thing about Rust is making the average programmer accept that computers do in fact exist and very much are not magic ;-)
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?
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.
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.
I know this is old, but I wanted to offer a different perspective. It's my experience that TS devs actually pick up Rust way easier than C++ or Java people. The reason, I suspect, is that the languages are far more similar than people realise, and Most TS codebases are not heavy on OO, instead relying on just simple records and functions. Then, TS's expressive type system allows devs to be very precise with their types. All it takes to get into Rust from that is understanding manual mem management, and since a lot of good patterns that the borrow checker enforces are already enforced in TS, it seems the transition is very painless. But a guy coming Java land will keep trying to do things the Java way, and it just doesnt work. As for JS being trash, it's such a cliche. It has a wonderful core, suffering from loads of really stupid decisions and group think. It's insanely easy to pick up and do something with it, but it's overused in domains/fields where it really shouldn't be used.
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.
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"
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.
@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 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.
@@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 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
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.
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 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."
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.
@@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.
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.
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"
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.
@@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.
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
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.
@@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 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.
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.
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
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.
@@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.
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
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)
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.
@@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.
@@AlbatrossCommando 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.
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.
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.
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 } } }}; }
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.
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.
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...
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.
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.
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?
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 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.
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 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.
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.
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.
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.
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... :)
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.
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.
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
well, I had a similar experience with Rust so far. I mainly code in C# and F# (love it), but one time I decided to rewrite a small cli tool that does soem statistics on a net router logs. It reads each line as an xml, find lines with specific information, created data objects from those (basically deserialization), and then does some group by, filter, sort etc, and print a nice summary - for example find computers that switch between two access points often (you know place in your office where wifi sucks? it's because of that). So, in C# it took lie 40 minutes to figure out what I need, write the code, do the publish (it compiles to native), and the program can analyze 4gb files in 2s. All within standard library, using xpath to get the xml element, data is streaming - no loading everything at once. All done with LINQ (iterators, with map, filter etc). You slap AsParallel in one line, you get mutlithreading. 150mb memory usage tops. So, I tried it in Rust. First of all, how the hell do I read XML? There were some libraries, but so slow, they weren't usable - just parsing first 1mb of lgos took more than the whole C# program (yes, in release mode). There is one, but it's internal to some music create, and it doesn't support xml without the schema row - they have an explicit check for that, and an issue to add that and remove the default schema. Why? Because FU. So regex it is, cool. Now we deal with lifetimes. This is super frustrating, becuase for something so simple, I already have to annotate things with them. BTW, "fixing" lifetime problems boils down to adding a separate lifetime on everything, then it magically works. Why the compiler is not able to do it on its own? If there is only one correct configuration for those, couldn't it be automatic? I must say that the compiler error messages are quite nice, but again. Why do I really need to put "move" on a lambda? Couldn't the compiler just do that for me implicitly, if this is the only way to get the program to work? On top of that, couple observations. The debug mode sucks major balls - it is so slow, and the debugger itself is not that helpful. Really, C# tooling spoiled me so much - it's fast, easy, logical, had hot reload on breakpoints for a decade (if not two, and now it has it also for just running programs). Cargo as a dependency tool is good, but still decades behind nuget. Also, what's the deal with manual reloading after changing dependencies? Oh, because it is so slow that automatic one would be frustrating. End result? Program took like 10s to run, 5x slower than C#. I managed to get data to be streamed with iterators, that's good, but memory usage wasn't that much lover - probably because of the strings and regexes. I also tried Kotlin, which was, well, also super undewhelming - if I remember correctly, more than one minute. Is the XML the problem? I am pretty sure MS invested tons of money into xml parsing and the engine is just super fast, but holy crap, I never expected it to be that much faster. So far, I will stick to C# and F# - next year we are getting discriminated unions, probably traits. Async is already here - the OG! :) I will keep learning Rust, but so far I struggle to see a practical application. Maybe a message processor for our rabbit mq? yeah, but we have MassTransit for C#, and for like 100$ a month another k8s cluster - we will stick to C# :)
there's a great fast XML library called quick-xml which I've used for quite large xml files amd it's pretty fast. idk if you're still willing to improve it but yeah.
Did u try using rust like 5 years ago? Not a fast XML library? Don't understand why you are annotating lifetimes? A lot of this is just inexperience and frustration. "The debug mode is so slow", "debugger isn't useful". How much experience do you have with debuggers? Why are you using the debug mode for anything where speed is a factor?
You are spoiled by C# 🙂 The big advantage of Rust is that it compiles to one single exe, which does not require any framework installed and does not need an installer or deployment. The compiled exe will run for the next 10 years unmodified.
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.
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.
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.
Hah, I have ran into and "solved" that problem he's alluding to with rusqlite and mysql. And rusqlite is the worst offender because its Prepared statements are bound to the connection, it wants you to use its caching mechanism and send the same string to hash again and again. This goes against java conventions which is to prepare a statement and hold the statement. The worst case is when you get transactions in the mix, because both of these use a wrapper (to enforce RAII) which will not expose the prepared statements (you cannot deref to your own wrapper which would hold the Statements). My solution was to encapsulate the connection handler at the point it comes from the pool, thus converting the pool to a system that produces these wrapped connections, and adding my own code for managing the tranasactions (often not using RAII for that). Works a bit like a pluggable business layer converting between types and exposing queries as concrete functions. I've actually talked (on discord) with the creator of the rusqlite and believe opened an issue on the matter, I do believe this is a deficiency with all major sql libraries because it in some sense presents an ownership dilemma. I can confirm its solvable now (I use the same basic structure for all my actix-web systems now)
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.
To summarize the whole thing, the issue is Learning Curve. Nothing more. You really NEED to like the language, and you really NEED to want spending hobby time to it. 🦀 From that direction, you _might_ grow to Rust professionally. Which has not even happened to me, yet. I still mostly write in other languages, especially C# professionally, since the beginning that it existed 20 about years ago. Really great language too. But at least I spend went through the entire Book, went through the rustlings tests and more, and spended a lot of time experimenting with many things. I consider this the minimum for myself to even start thinking about calling myself actually knowledgeable with the language. However it makes an huge difference when you have seen a lot of different programming languages and technologies already. Maby not for that C and Java programmer. But my decision is that Rust is going to have an important place in my future developer years.
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 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.
"It's amazing how the Rust community gaslights everyone who doesn't fall for the hype" Dude just said that Rust wasn't object oriented. If I say that fucking C is not object oriented, am I gaslighting people trying to do OOP stuff in C? OF COURSE NOT! IT'S COMMON SENSE THAT C IS NOT OBJECT ORIENTED!
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 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.
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.
Well in C if you use gif -Wall -Werror -Wpedantic for every issue that the compiler will see but most people don’t use it because they just want to ship the code if it’s good enough in where rust kind of force you to fix errors
Don't know much about C, but the quality of the errors is also important. The Rust compiler is annoying, yes, but its also helpfull more often than not.
Agree but it’s a matter of trade off and sometimes you don’t have that choices, their are a lot of hype on languages but in reality their a huge dark matter developers that code in unpopular languages.
Rust was really the one language I could actually make a lot of good stuff in. I don't have to worry about my program crashing/NREing suddenly, because everything is in Results/Options. The language is inherently low-level, but the wealth and abstraction the standard library brings, along with macros and generics can bring so much safety and automation (Box/Rc Drop impl for example).
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" :)
"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.
The problem with rust, and the comments of people who write it, is it's useless information. Rust wants you to program in some paradigm. Why is your paradigm correct? Because whoever made rust said it is. Want to move away from that? No, you have to program it the rust way. Do move away from that? Literally get harassed out of the "ecosystem" I do not find rust code clean. I don't find it useful. I never found the subreddits or anything surrounding it helpful. It's literally just the next cargo cult. Is zig annoyingly strict sometimes? Yes, but it never fundamentally forces you to solve a problem according to the arbitrary definitions of someone Mozilla programmer 10 years ago. Lots of useful languages are getting traction lately and can be used in a ton of domains, and all the rust hype literally just seems like a concerted marketing effort. If you love simplicity in engineering then you will hate rust. There is no use for me to change my thinking about it because to do so I would have to lower my standards as an engineer
Rust just isn't proven, There's no killer app that can prove that all the abuse you face from the borrow checker is actually worth it. Maybe it'll change soon, who knows?
While every program does not need to be fully safe or correct Rust strives for correctness and achives it with a few rules. These rules are based on understanding of hardware operating systems and compilers. While with all languages best practices evolve over time and are just made up as they go the core rules of Rust are not. Infact the core rules can work in most languages C, C++ Zig and more. Rust is not the only langage to achive this though. There are a few ways to do this however most ways include a garbage collector or require heap allocation. This is where Rust is different, since it works without those limitations. If you ignore Rust rules you will not be able to compile a program. For Rust this is better then compiling an incorrect program. Just like if you ignore the rules C,C++ or Zig you will get a bad program. Rust just has stricter rules and ones checked at compile time.
@@sumansaha295big companies move to rust for quite a few things, a lot of important webassembly modules are written in rust like webgpu. It has certainly proven itself. Imo rust is like just bringing the big guns for big problems, otherwise bringing that gun to little problems will just kinda backfire
@@dynfoxx Rust doesn't prove a program is correct. That is literally impossible. It's called the halting problem. Rust proves what it says it proves on the tin.
@@ShinDMitsuki Just like any langage Rust has things it checks. It does prove parts of a program to the extent you use the type system and Rust tooling. Not sure why you thought I said it solves the halting problem.
I love the "write it poorly, then go back and fix it" advice. Seems pretty solid unless you've ever been an actual been a software developer for a company that expects results. 95% of the time, the first version of code deployed is the only version ever deployed. Sure, you'll constantly be deploying new features and functionality, but being given time to go back and improve something that works (regardless of how poorly) is just an dream in most places.
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.
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 `?`.
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.
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
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
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
I love the “You’re having a problem with rust? Borrow checker. That’s not your issue? Borrow checker.”
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
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
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.
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.
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
@@tekim16755 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
13:16 LOOK MA IM ON THE TV!! Thanks for the positive feedback for my feedback, it really means a lot to me!
"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.
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
@@ShinDMitsuki 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?
@@tiranito2834 I highly recommend you actually give Rust a try, instead of making bold statements based on your misunderstanding of the marketing material and social media nonsense :-)
Sorry, that may sound a bit harsh but it's rather obvious that you aren't talking from experience.
What you said is true for safe Rust. But unsafe is there this very reason. It allows you to encode these kinds of programs in a way the compiler understands.
That's really the thing about Rust. Talking about any aspect on its own doesn't do it any justice, it's how incredibly well those aspects interact with each other.
I understand that it seems hard and like it has to get in the way, but if you're actually moving fast and actually care about quality, Rust is a massive productivity gain, because encoding all that correctness information in the type system once removes the overhead of juggling that information in some other way. Of course that's hard to grasp if you pretend like that information isn't relevant - or don't even realize that it exists. But that's how you get poor quality software.
Seeing Rust's features as limiting is just such an odd perspective. Let me put it this way: The C++ community virtually banned the use of raw pointers even by seasoned professionals - Rust gives them to people who never programmed outside a JS framework and it's not a problem at all. The borrow checker isn't limiting, it's the ultimate liberation.
The hardest thing about Rust is making the average programmer accept that computers do in fact exist and very much are not magic ;-)
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
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.
I know this is old, but I wanted to offer a different perspective.
It's my experience that TS devs actually pick up Rust way easier than C++ or Java people. The reason, I suspect, is that the languages are far more similar than people realise, and Most TS codebases are not heavy on OO, instead relying on just simple records and functions. Then, TS's expressive type system allows devs to be very precise with their types. All it takes to get into Rust from that is understanding manual mem management, and since a lot of good patterns that the borrow checker enforces are already enforced in TS, it seems the transition is very painless.
But a guy coming Java land will keep trying to do things the Java way, and it just doesnt work.
As for JS being trash, it's such a cliche. It has a wonderful core, suffering from loads of really stupid decisions and group think. It's insanely easy to pick up and do something with it, but it's overused in domains/fields where it really shouldn't be used.
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.
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"
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 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 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 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)
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.
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 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.
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.
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"
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.
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
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 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
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.
"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
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 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!
"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.
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)
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.
@@AlbatrossCommando 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.
"A swift death" means the same thing for both meanings of swift
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.
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.
The one thing I had to really work on, as a developer, "make it work, then make it pretty/fast/efficient etc"
I am completely jazzed that you are referring to SQL as "squeal". I've been trying to make squeal happen for thirty years.
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.
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 absolute first Rust project was FFI between C and Rust on an embedded system and boy oh boy did I have fun
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...
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.
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.
13:02 "I wanna help the guy get it up." -ThePrimeagen
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?
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 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.
I could have written this rant a year ago. I'm still slow with Rust, but at least it's starting to make sense.
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 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.
In fact, this guy as an experienced C dev will find it very easy to do with Go.
You don't like change if you stick with Java for 20 years. That is the main reason for the frustration that he has.
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.
"How are you with Rust?"
"I hate it."
"An experienced user then."
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.
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.
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... :)
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...
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.
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
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 😂
well, I had a similar experience with Rust so far. I mainly code in C# and F# (love it), but one time I decided to rewrite a small cli tool that does soem statistics on a net router logs. It reads each line as an xml, find lines with specific information, created data objects from those (basically deserialization), and then does some group by, filter, sort etc, and print a nice summary - for example find computers that switch between two access points often (you know place in your office where wifi sucks? it's because of that).
So, in C# it took lie 40 minutes to figure out what I need, write the code, do the publish (it compiles to native), and the program can analyze 4gb files in 2s. All within standard library, using xpath to get the xml element, data is streaming - no loading everything at once. All done with LINQ (iterators, with map, filter etc). You slap AsParallel in one line, you get mutlithreading. 150mb memory usage tops.
So, I tried it in Rust. First of all, how the hell do I read XML? There were some libraries, but so slow, they weren't usable - just parsing first 1mb of lgos took more than the whole C# program (yes, in release mode). There is one, but it's internal to some music create, and it doesn't support xml without the schema row - they have an explicit check for that, and an issue to add that and remove the default schema. Why? Because FU.
So regex it is, cool. Now we deal with lifetimes. This is super frustrating, becuase for something so simple, I already have to annotate things with them. BTW, "fixing" lifetime problems boils down to adding a separate lifetime on everything, then it magically works. Why the compiler is not able to do it on its own? If there is only one correct configuration for those, couldn't it be automatic?
I must say that the compiler error messages are quite nice, but again. Why do I really need to put "move" on a lambda? Couldn't the compiler just do that for me implicitly, if this is the only way to get the program to work?
On top of that, couple observations. The debug mode sucks major balls - it is so slow, and the debugger itself is not that helpful. Really, C# tooling spoiled me so much - it's fast, easy, logical, had hot reload on breakpoints for a decade (if not two, and now it has it also for just running programs).
Cargo as a dependency tool is good, but still decades behind nuget. Also, what's the deal with manual reloading after changing dependencies? Oh, because it is so slow that automatic one would be frustrating.
End result? Program took like 10s to run, 5x slower than C#. I managed to get data to be streamed with iterators, that's good, but memory usage wasn't that much lover - probably because of the strings and regexes. I also tried Kotlin, which was, well, also super undewhelming - if I remember correctly, more than one minute. Is the XML the problem? I am pretty sure MS invested tons of money into xml parsing and the engine is just super fast, but holy crap, I never expected it to be that much faster.
So far, I will stick to C# and F# - next year we are getting discriminated unions, probably traits. Async is already here - the OG! :) I will keep learning Rust, but so far I struggle to see a practical application.
Maybe a message processor for our rabbit mq? yeah, but we have MassTransit for C#, and for like 100$ a month another k8s cluster - we will stick to C# :)
there's a great fast XML library called quick-xml which I've used for quite large xml files amd it's pretty fast. idk if you're still willing to improve it but yeah.
Did u try using rust like 5 years ago? Not a fast XML library? Don't understand why you are annotating lifetimes? A lot of this is just inexperience and frustration. "The debug mode is so slow", "debugger isn't useful". How much experience do you have with debuggers? Why are you using the debug mode for anything where speed is a factor?
@@derschutz4737 fresh build of that file takes 4s on my machine, that's ethernity in C# world for a program that fully fits on your screen
@@Qrzychu92 Slow compile times are 100% annoying if you work on extremely big projects. But everything else is just bad decisions.
You are spoiled by C# 🙂
The big advantage of Rust is that it compiles to one single exe, which does not require any framework installed and does not need an installer or deployment. The compiled exe will run for the next 10 years unmodified.
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.
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.
There are two types of programming languages:
Either
#0, everybody hates
exclusive or:
#1, nobody uses.
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.
People feeling personally attacked because a language is criticized is lame as hell. Stan culture should stick to K-pop and stay out of programming 😭
Hah, I have ran into and "solved" that problem he's alluding to with rusqlite and mysql. And rusqlite is the worst offender because its Prepared statements are bound to the connection, it wants you to use its caching mechanism and send the same string to hash again and again. This goes against java conventions which is to prepare a statement and hold the statement. The worst case is when you get transactions in the mix, because both of these use a wrapper (to enforce RAII) which will not expose the prepared statements (you cannot deref to your own wrapper which would hold the Statements). My solution was to encapsulate the connection handler at the point it comes from the pool, thus converting the pool to a system that produces these wrapped connections, and adding my own code for managing the tranasactions (often not using RAII for that). Works a bit like a pluggable business layer converting between types and exposing queries as concrete functions.
I've actually talked (on discord) with the creator of the rusqlite and believe opened an issue on the matter, I do believe this is a deficiency with all major sql libraries because it in some sense presents an ownership dilemma. I can confirm its solvable now (I use the same basic structure for all my actix-web systems now)
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.
To summarize the whole thing, the issue is Learning Curve. Nothing more. You really NEED to like the language, and you really NEED to want spending hobby time to it. 🦀
From that direction, you _might_ grow to Rust professionally. Which has not even happened to me, yet. I still mostly write in other languages, especially C# professionally, since the beginning that it existed 20 about years ago. Really great language too.
But at least I spend went through the entire Book, went through the rustlings tests and more, and spended a lot of time experimenting with many things.
I consider this the minimum for myself to even start thinking about calling myself actually knowledgeable with the language. However it makes an huge difference when you have seen a lot of different programming languages and technologies already.
Maby not for that C and Java programmer. But my decision is that Rust is going to have an important place in my future developer years.
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 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?
"It's amazing how the Rust community gaslights everyone who doesn't fall for the hype"
Dude just said that Rust wasn't object oriented. If I say that fucking C is not object oriented, am I gaslighting people trying to do OOP stuff in C? OF COURSE NOT! IT'S COMMON SENSE THAT C IS NOT OBJECT ORIENTED!
"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 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.
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 reminisce about the early days, when all the programming was done using sliced bread.
Well in C if you use gif -Wall -Werror -Wpedantic for every issue that the compiler will see but most people don’t use it because they just want to ship the code if it’s good enough in where rust kind of force you to fix errors
Don't know much about C, but the quality of the errors is also important. The Rust compiler is annoying, yes, but its also helpfull more often than not.
Agree but it’s a matter of trade off and sometimes you don’t have that choices, their are a lot of hype on languages but in reality their a huge dark matter developers that code in unpopular languages.
16:16 "Zig no need big brain. Small brain good."
xD
I would love to get tasks with a technology i do not know for my job.
Poor guy. I hope he didn't get turned off by this experience. I hope one day it will click to them
Rust was really the one language I could actually make a lot of good stuff in. I don't have to worry about my program crashing/NREing suddenly, because everything is in Results/Options. The language is inherently low-level, but the wealth and abstraction the standard library brings, along with macros and generics can bring so much safety and automation (Box/Rc Drop impl for example).
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.
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
*Whaaaahhhhh* Wow I wish somebody would "make" me use rust.
yes 😂
"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.
The problem with rust, and the comments of people who write it, is it's useless information. Rust wants you to program in some paradigm. Why is your paradigm correct? Because whoever made rust said it is. Want to move away from that? No, you have to program it the rust way. Do move away from that? Literally get harassed out of the "ecosystem"
I do not find rust code clean. I don't find it useful. I never found the subreddits or anything surrounding it helpful. It's literally just the next cargo cult.
Is zig annoyingly strict sometimes? Yes, but it never fundamentally forces you to solve a problem according to the arbitrary definitions of someone Mozilla programmer 10 years ago. Lots of useful languages are getting traction lately and can be used in a ton of domains, and all the rust hype literally just seems like a concerted marketing effort. If you love simplicity in engineering then you will hate rust. There is no use for me to change my thinking about it because to do so I would have to lower my standards as an engineer
Rust just isn't proven, There's no killer app that can prove that all the abuse you face from the borrow checker is actually worth it. Maybe it'll change soon, who knows?
While every program does not need to be fully safe or correct Rust strives for correctness and achives it with a few rules. These rules are based on understanding of hardware operating systems and compilers. While with all languages best practices evolve over time and are just made up as they go the core rules of Rust are not. Infact the core rules can work in most languages C, C++ Zig and more.
Rust is not the only langage to achive this though. There are a few ways to do this however most ways include a garbage collector or require heap allocation. This is where Rust is different, since it works without those limitations.
If you ignore Rust rules you will not be able to compile a program. For Rust this is better then compiling an incorrect program. Just like if you ignore the rules C,C++ or Zig you will get a bad program. Rust just has stricter rules and ones checked at compile time.
@@sumansaha295big companies move to rust for quite a few things, a lot of important webassembly modules are written in rust like webgpu. It has certainly proven itself. Imo rust is like just bringing the big guns for big problems, otherwise bringing that gun to little problems will just kinda backfire
@@dynfoxx Rust doesn't prove a program is correct. That is literally impossible. It's called the halting problem. Rust proves what it says it proves on the tin.
@@ShinDMitsuki Just like any langage Rust has things it checks. It does prove parts of a program to the extent you use the type system and Rust tooling.
Not sure why you thought I said it solves the halting problem.
I love the "write it poorly, then go back and fix it" advice. Seems pretty solid unless you've ever been an actual been a software developer for a company that expects results. 95% of the time, the first version of code deployed is the only version ever deployed. Sure, you'll constantly be deploying new features and functionality, but being given time to go back and improve something that works (regardless of how poorly) is just an dream in most places.
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.
You cannot fix a$$hole management. 🤷
He shouldn't accept the task using a drastically unknown technology to him in the first place.