"Statically typed" doesn't implies "verbose". Look at Haskell, for instance. I don't know why language creators keep inventing weird bicycles while most of the good stuff has been already invented long time ago. My opinion that Rust is an abomination, it has many good features that older language don't have, however it also accidentally got many ugly things that these language had (for instance, abbreviated keywords, subtyping. C-like syntax, or even worse). Weird.
Wow, just looking at Rust's syntax, I'm convinced it's written by demonically possessed people. Who in their right mind wants to do the mental gymnastics for 100k lines of code written that way? Wow.
@@Henry-sv3wv Idk, I'm writing my scripting language's compiler and interpretter in Rust and it's kept things smooth operating while improving readability and consistency across the entire code base, since some things are inherently long-winded in a language parser. I could see myself easily messing up at some point or creating memory leaks if I were to use C or C++, Rust is preventing these issues inherently. I also don't think I'd consider myself an Einstein, you're an Einstein if you wrote what I've been writing in C without errors the first time you write it. Rust is "holding my hand," so to speak. I have memory management training wheels on, while not sacrificing performance.
Counterpoint: Haskell. Haskell's declaration of map is literally map _ [] = [] map f (x:xs) = f x : map f xs (I wrote it off the top of my head, but then checked and the official implementation is 100% identical) It can't be less verbose than than.
@@vytahReal programs in Haskell have type signatures for all top level functions and often inside functions for the sake of documentation and correctness. All the user defined data types often consist of smaller type helpers and other types too (e. g. newtype definitions). All this is usually not present in the programs on dynamic typed languages.
The more I'm growing up as a professional dev, the more I think the sentence "choose the right tool for the job" isn't actually that relevant an advice. To me, a language should be chosen to be in adequation not only with the task at hand, but also with the team at hand. I belive both are equally important. And to be clear, I'm not talking about the general skill level of the team, I'm talking about their mindset, how they approach software development in general, and how they are comfortable to work. In other words: their preferences. Because we like to think of software dev like it's 100% some objective science, as in "for each problem there exists an optimal path to solve it", and we often dismiss the importance of "mere" personal tastes and the importance of subjectivity in what people consider painful or boring. For instance, verbose type signatures and unmerciful type checkers are actually a selling point to me, not because I think they are The One Right Way (or because I'm masochistic), but because I just hate debugging, and I don't mind longer build times because it means the compiler is doing more stuff for me. Just like you say, I just love that fuzzy feeling when after spending hours on a code with only type checkers hints to help me, never even actually building my code (that's why long build times in Rust are actually not that much of an issue for a lot of projects), I build & run for the first time in hours and it just works. But if such an approach makes a lot of sense in Rust or Haskell, it would be a _terrible_ thing to do in e.g. Python. However, what pains me is not what pains others. Other devs prefer to see results quickly, optimize for iteration speed and are okay with the longer debugging sessions it entails, because they know their tools, they are pretty fast to zero in on the source of the bug, and they may even enjoy the challenge it offers. And at the end of the day their dev process can even be faster than mine. They just don't have the same mindset than I do, but it's equally valid and they are not worse devs than I am for it. It just comes down to preferences and workflow. And I cannot imagine the world of pain they would endure were they to tackle a project in a language like Rust that is so antagonistic to their mindset. True, this claim needs to be mitigated depending on the exact nature of the task at hand (you wouldn't make an OS in javascript, whatever the dev team), but for a lot of projects, there can be a lot of potential "right tools" for the job.
Another point, hinted at but not stated explicitly in the video, is that Rust's borrow checker forces a whole different set of programming patterns than a programmer may like. Yes, this is by design: these patterns are more obviously memory safe (i.e. verifiably safe at compile-time) than their alternatives, and it's generally a good idea to learn them so you can apply them to your favorite non-Rust programming language. But very often, the other patterns are just as memory-safe, possibly even more appropriate under the circumstances, and yet the borrow checker gets overzealous and prevents their use.
The problem with Rust is that they try to reinvent each term. Most of the time you try to rewire your brain to understand that a crate is a library, or what is an arm or a trait.
like, I'm sorry but I was hoping more of a genuine critique rather than a takedown of arguments. this feels a bit like a strawman. (Haskell has also shown us that you can have complex function signatures without them looking this awful and cluttered)
For non-trivial applications language simplicity is more of a liability than an asset. I'd much rather have the compiler discover problems in my code at build time than have my users find them at runtime.
You and me both. Believe me, the worst kind of "magic" that can be on programming is the one that the developer has little control / information on how it works.
@@hwstar9416 that's not quite true. With simplicity comes ambiguity, sure there can be compile time checks but there are still much more assumptions being made by the compiler. (Proper testing can mitigate this concern however)
@@boycefenn "With simplicity comes ambiguity" I'm sorry what? I think you're confusing different ideas with each other. "there are still much more assumptions being made by the compiler" What do you even mean by this?
Long compile times in comparison to stuff like golang and typescript is the biggest surprise and cause of the hate. If you are coming from c++ to rust, you expect it...but from those languages to rust, its a shock
@@ІванБоровик-э8л nah..its not comparable. Compile times of a big rust project and the lint time for a big js project cannot be compared...rust still losses. The compilation time thing is a big issue and will always be a shock unless its fixed
Incremental builds during development are pretty good, imo. Often with Rust, people don't treat it as a systems programming language, and compare it to non-systems languages, like Go.
Its one long compile the first time you start a large Project. Every compile after that will be fast. If you dont spend all day changing your depndencys, you wont notice the compile times.
I think another part of it is certain ecosystem problems. I write in rust for hobbies because I really like the rust environment, but I have so much trouble writing graphical apps or games or anything user facing, because all the graphical stuff in Rust is still in its infancy. It's gotten a lot better with things like Slint, Dioxus, Bevy and the unofficial godot-rust, but these all have bugs or limitations that prevent them from being used for major projects. I do feel like we're on the right path, but I don't feel like there's a mature enough graphics ecosystem for most app developers to join Rust yet.
Huh? Why do you want to depend on some third party code for something as basic and fundamental as graphics? Build your own. Regardless of the language.
@@vitalyl1327 Yeah sure, graphics can be basic, just like an AI can be as simple as a goomba from mario that only walks left and right. you're definitely not writing your own graphics lib / gui toolkit that is cross platform across mac, linux, windows. doesn't even make sense.
@@dany5ful have you seen the Dear I'm Gui library? A perfect example how easily a cross-platform GUI can be written. Look at it, understand it, then write your own.
I went from C to Rust, and the main problem I had with it was the forced paradigms. It doesn't let you code the way you want to code. You can't write intuitively. It forces you to do things that feel gross and unintuitive, because it doesn't trust you. I just don't want to work like that.
I agree. And when you use unsafe to try to tell the compiler you know what you’re doing, the compiler tells you “you might know what’s going on in c, but you don’t know my rules.” So you end up getting a situation where you write it exactly like you would c, but it’s truly undefined in rust. So annoying. As someone who’s using rust actively for a largish project now, I can say I just don’t love it
This is one of the key things that always bothered me with Rust, The fact that it will warn me if I don't use a certain case type while writing out variables or whatever is frustrating.
@@JorgetePanete That's just it, I have my style for variable casing or whatever and I do not want to conform to Rust's style so the fact that it complains for me not using a certain style is infuriating.
I've been learning Rust for a few months now (I'm a Ruby developer in my day job). On my hobby project, I fight the compiler a lot. On the other hand, when I'm done fighting with it, my code usually works.
Ruby is an elegant language. So it's good to ask you: As beginners, we run away from Rust because we hear about it's difficulty? What do you think beginners should do in the first 3 months to keep cracking this difficulty?
I see no real use case in the enterprise software area for a programming language that is hard to learn, hard to write and... hard to read. This is crazy! Who will pay for that? Because it's hard in every aspect it will required just more time for development. Java beats it and JVM is fast enough for handling quite high work-load. That's all what we need.
I really really wanted Rust to be my goto general purpose language... While it does have quite a bit of built in little things that let you ignore good practices and write dirty fast prototype code, it doesn't excel at it compared to some other languages. I don't tend to build programs that already exist, which means a good chunk of what I do is prototyping and testing and throwing away code as I come up with better approaches. The trouble I have is that takes longer in Rust. However, once you know exactly what you are doing and you know the thing you are building will live on and be useful for quite a long time, that seems to be when you want to involve Rust as that seems to be where it shines. Unfortunately for me... that's just not where I tend to sit professionally so I barely get a chance to use Rust.
That's basically the kind of code I mostly write for work as well, with also often having to provide a GUI of some sort from the get go, plus an integration with external formats and/or applications. I normally used C++ and I know enough about it and the ecosystem to not be in pain all the time, but in reality writing C++ feels like walking in deep mud with slippers with no end in sight, a horrible unrewarding experience. I tried Python for the prototyping stage, but it just doesnt make sense in most cases because I'll always have to rewrite in a serious language anyway for a plethora of reasons so might as well not waste my time and use it from the start. I tried Zig, but it's way too unstable and unfinished at the moment, I can't afford having to deal with constant changes to the build system, standard library, etc. Also, it's not the most convenient language for shitting out code that you don't really care that much about. It's great for achieving very particular things in a very particular way. Great for when you want it, pain otherwise. Also, it's extremelly niche and has basically no documentation or resources for non turbonerds to learn, so good luck pitching it to your coworkers and boss. Rust has so far been a hit. It has nice tooling, superb documentation with lots of examples, lots of crates for doing various things, and I find the iterator adapters and various other functional aspects in particular to be a huge convenience for the type of domain code I write. Sure, it is quite hard to learn fully, especially for a newbie, though not anywhere near C++ level of hard, not even close. The difference being that there is a sense of reason and intentional, consistent design all throughout, so lots of things fall into place when you come to understand certain key aspects of the language. Sure, some things tend to be more verbose and inconvenient to write than I'd like, but with all the other positives considered it's still come out on top for me.
To me the annoying part is that Rust programmers cannot admit that the language is complex/difficult, and want to gaslight you into thinking that it's easy if you just learn a few principles and read the error messages.
Does anybody actually say that? I've been programming in Rust for about 6 years, and I don't think I'm an expert yet. But to be fair, people certainly overestimate the difficulty. The classic "fighting the borrow checker" is weird, because you get the hang of it fairly quickly. All you need to know is who owns the data, and that you can only mutate in a single place.
@@tinrabI'm working with Rust for quite some time and I think it's freaking hard to learn. The borrow checker is only the first hurdle. "The function exists on type X but the trait bounds are not satisfied" 😭 just one example. Rust is praised for it's great error messages, but they only make sence once you understand why your code should be written differently. I still love Rust and I'm productive, but it's a painful journey. I think the pain pays off, but it's pain nonetheless 😉
@@tinrab I know what it means, but not how to figure out what trait is not implemented. It's easy for my own types and traits, but hard to figure out if it's from dependencies.
My annoyance with Rust is due to the armies of Rust developers trying to push C++ out of existence. It was refreshing that you made a point of _not_ doing that.
One of the biggest issues I have with Rust is that it's virtually impossible to "pick up and explore". A lot of "modern" languages are reasonably straightforward to the point where you need to learn very little syntax and can get started fairly well. For example, if you've never programmed Python in your life and come from Java, then picking up Python will be relatively easy. But Rust requires you to learn so much before you can do anything, that a lot of developers will just say "screw it" and pick a different language.
Yeah, but that’s kinda by design Rust has a lot of its own design features to force you to make safer code. Obviously, having concepts that basically no other programming language has and don’t directly translate into compiled code does make it a lot harder
@@palmberry5576 It doesn't help that a lot of times those features are enforced needlessly. If I already checked this object for safety, the last thing I want to see from the compiler is telling me I am not allowed to do it because it's "unsafe".
Have you noticed almost every, if not all, beginning Rust tutorials use the macro ‘println!()’ vs ´print!()’. Because you can’t simply write: print!(“What’s your name? “); let mut name = String::new(); stdin().read_line(&mut name).expect(“Failed”); You have to flush the buffer. 😮 print!(“What’s your name? “); stdout().flush().unwrap(); let mut name = String::new(); stdin().read_line(&mut name).expect(“Failed”);
@@GaryChike Well, that's standard in system programming. In C/C++ you have to do the same - stdin/stdout/stderr are buffered, doesn't matter if you use fprintf or C++ streams. You can also disable buffering if you need to.
Devs hate rust because people think it's something life changing and revolutionary but when you use it it's just more complicated for literally no reason.
You forgot one important thing: Rust Cargo crate system! Imagine someone opening a PR with 100s of crates. It will be impossible to review each one of them. The dislike for rust comes from there as some people speculate that cargo is going to be like npm.
yep. that is one qualm i have. the push for just using crates. while on its surface it seems fine, but when one needs to audit the dependencies for supply chain attacks and licensing, it does become harder with more dependencies. i am working on trying to get people to be less pushy about just using crates
The reason people hate rust most, is that developers don't want the restrictions and overhead which come with Rust's bullshit promise of safety. Borrow checker, being one of the big manifestations of that. The performance promises are a lie and the language performs much worse if used idiomatically, than other systems language choices.
7:42 "Don't blame a perfectly designed language on a skill issue" is certainly one of the statements of all time (Edit: for context, he says "jokes aside" like 3 seconds later, of course Rust is not a perfectly designed language lmao)
a perfectly designed language🤡and then you try async Rust. Bro just can't keep Rust propaganda from spitting out of his mouth. I doubt he has any technical expertise aside from being a tech content creator to begin with
@@rw_panic0_0 I think async is pretty good. What does it look like in other systems programming languages? We'll see how Zig turns out. You have async/await, where `await` is a suffix call, which means you can have chaining. The hard part comes with pinning, but I almost never have to write that. Streams are also great. Recently I've been using `async-stream` create, which allows creating streams with imperative code and using `yield` keyword, just like "generators."
I'm from java. 10+ years. I wrote a test in rust. I use testcontainers in it. I fill redis with some data, verify them. The test runs under 1 sec. The biggest relief in my life. No words to explain that. Now the tough part is to find a job.
I'm a developer with autism. Rust is neat and the safety features are pretty cool but it doesn't satisfy my curiosity like C does. If anything, Rust doesn't even compete with C but complements it.
at 4:30 you mention that rust is being used in aerospace and automotive applications. This is demonstrably wrong, rust has no formal specification unlike ADA, C, or C++. Because of this it is impossible to get software written in rust approved by FAA and relevant bodies for use in mission critical systems aboard aircraft or car controls. The rest of your points for rust are reasonable, but lying so blatantly; and for such a key point is disappointing.
I'm actually wondering if it would be possible to create a language that starts out like Swift, easy and relatively safe, and which can get progressively safer if you opt into that. For example, the reason Rust needs all that borrow checking, is because almost all variables in Rust are by default passed by reference, because of course that's faster than copying by default, which is what Swift does. But what if you'd start out with a copying-by-default model, because that's much simpler to work with, but you can opt into a passing-by-reference model whenever you want to make your code safer? let str1 = "This string constant will be copied by default" var str2 = "This string as well, but this variable is mutable" let ref str3 = "This string constant will be passed by reference, ownership and borrowing rules apply" var ref str4 = "Same for this mutable string" Or something like that.
@@SilisAlin Yes I know, but then Swift does not apply the ownership and borrowing rules of Rust in those scenarios. Swift relies on ARC, which works well enough in most situations, but is not as safe as Rust's rules for references. For example, in Swift it's still way too easy to create circular references that then never get deallocated.
@@yuitachibana8829 If I understand correctly, in Rust when you pass a variable, in most cases, you're either transferring ownership of the value or you're lending / borrowing a reference. Both of those I would say is "pass by reference", since "pass by value" usually means to copy the value. And as far as I know, copying is not the default behavior in Rust except maybe for super simple types like integers. In Swift, structs are passed by value, meaning that they are copied by default.
Whenever I see Rust mentioned, most of the time it's the toxic part of the community: bullying Rust devs for `unsafe` code, bullying devs for not using Rust, hostile rewrites, vandalising wikipedia. It seems like some portion of rustaceans are edgy teens from 4chan. Not the people I would like to hang out with.
The C++ templating / meta programming though is *horrible*. Rust is not perfect but at least now I am proficient at metaprogramming and it helps when you build libraries.
@@tototitui Metaprogramming became significantly easier in C++ after concepts were introduced in C++20. They should have done that earlier to be honest. Rust was ahead in the game with its Traits and Generics.
Rust and C are both "hard" but in different ways: C is hard because you have to learn to avoid the dangerous parts of the language: stuff like buffer overflows and memory errors. Rust is hard because you have to learn to work with borrow checking and a more complicated syntax. People don't think of C as hard because it has a much shallower learning curve, but really it's just as hard to do *right* and when you screw up the consequences are far worse
things that would be tiny changes in C/C++ so often require big rewrites of program sections in Rust because introducing new (mutable) references is often illegal. Rust discourages fast development iterations, which is especially damadging when the product vision is not yet totally clear (which is why I can never see it take of for game development). I guess if you want to have super stable, perfomant stuff you rarely need to change, its awesome. But then you are probably a bank and boring af
I don't have fuzzy feeling when my Rust program finally compiles. I have a feeling of wasted time that I spent 10x more time on coding in comparison to similar program in Go.
i get it, the language maybe isn't that bad. But the reason why i don't like rust- is not with the language (though that syntax gives me headaches) - but it is with it's programmer base. And i don't want to sound like an asshole- but i probably will regardless. So here's my reason: For some reason, whenever i encountered a rust developer- be it in university, in the field, through social media whatever platform suits you best- it's always so difficult to have a normal human being conversation with them. Like a normally developed adult. And before you all come slinging words like "we're autistic!" or "you're a boomer" - i get it, but i'm a damned embedded engineer. If there's anyone that's going to be the most autistic out of us all- it's probably going to be me. Yet, I still put my best leg forward, i still take a shower before work- and my classrooms weren't some cult trying to rustify anything (or c-ify anything in my case i guess) We just had our use case, we had a language that's been in this field for litteral decades. And it's our goto language for our complicated engineering needs. But then come the rust evangelists shouting about memory safety and "ackshually xyz" or "you know rust can do that too?" and i just wish they would shut the hell up for a minute. Nobody asked, Nobody cares, and i hardly know any engineering office enviorment that likes people that cannot shut up, just make it work and most imporantly - work together.
@@Leonhart_93 It goes both ways. I seriously saw like 50 of your comments here were you can't stop hating on Rust, despite clearly having no experience in it. The "Rust hater" crowds is just as obnoxious as the evangelists.
while there are some problems like the push to use a bunch of crates, but overall the language and community is fine. using a lot of crates becomes an issue when you need to validate licensing and supply chain attacks
I hate about rust that rust fans will take a video about how and why people hate rust and make it propaganda for rust. You can't just enumerate things people don't like, you want to still enumerate why Rust is so good. I have seen this in fans of other languages, but with rust is taken to another level. This video is "why do developers hate Rust?" and less than 1/3 of the video is about why people don't like rust.
So here's the thing I think happens with things like Rust, and say... Linux (probably other things too?) ... Godot - They are complicated and don't work the way you expect out the box, so people spend a bunch of sunken time trying to make them work, trying all sorts of different things, reading docs, trying to understand from the mindset of the creators ... that you can eventually develop a sort of stockholm syndrom or sunken cost fallicy, where people just start to obsess over the thing and get into arguments over minutia with others in the community, forms a sort of cult, where these videos are the cult leaders. There are definitely other REALLY GOOD tools out there, that get the job done, are not surprising, are even pleasing to use, but since they aren't complicated and confusing, don't get nearly as much air time because there's not nearly as much to talk about - "It does the thing without issue" is not as interesting or mind snaring
it's a mentallity thing. i don't feel like going in to politics - but have you ever looked at their profiles? hell- their github's even, there's a reason why there's 15 different "problems" that nobody else ever heard about. There's a reason why so many have 20 different flags in their bio's. It's not cause it makes them better team-players, and it's not cause it makes them office compatible. I thought being an embedded engineer made me the worst sack of ass on the office floor. But i'm starting to doupt that title should go to the mentally distraught smelly there in the corner.
I agree: I only searched about Rust on Android, not about dislikes; it’s YT that recommended that to me (I should have known better). The 1st video on the dislike topic was a parody, so actually meant to praise Rust. And now this one; second red flag IMO. The last time I experimented, Rust was still developed in OCaml.
I've seen a lot of neat arguments in support of Rust, but the paradiym shift is just a little too much for me - it forces me to think long and hard about every single line of code I write, which makes prototyping just impractical time wise. I want to write something fast and have it work (to get my ideas out), then after have a linter tell me how I can make it correct. During development, code is constantly changing and shifting - constantly putting in the extra effort beforehand unnecessarily spikes development time.
Well, actually, C++ has a similar problem. There is a cppcon talk of Chandler Charruth about the cost of C++ abstractions here on YT, and one of the currencies you are paying for using them is "compile time". Which in C++ is mostly due to all that template stuff, in Rust it is mostly due to delivering libraries as source code. There is big room for improvement here on the Rust side. The other weak point of Rust is C/C++-interoperability. There's cbindgen to get access to C functions and data structures and use them in Rust code or exporting Rust code to C, but there is nothing allowing for the usage of C++ code in Rust. That's why Rust isn't the best candidate for a successor to C++.
Be careful when you guys say "it's easier to refactor and maintain" etc. Unless you are a professional Rust dev in a team, you probably have no idea if it's true in real scenarios. That's why people call for propaganda sometimes. Every tech is amazing when you only use it alone, on a side project i guess
It is true, but it's also the case for the opposite, people cannot say it will be harder to maintain without having done it in bigger projects with a team.
Personally, I’ve put rust on a shelf and chosen golang because of job opportunities. Like in a common joke “there are no junior rust developers”. Rust is mostly used in cases when other tools are not sufficient to accomplish a task, that is, by experienced developers, not newbies like me.
No pun intended, but if you look into Rust as a Python dev, you are looking into your car's engine as a car's owner - you will have no clue, what is going on there. As C is, what makes Python going (i.e. the interpreting engine of Python is build with), and Rust is a more demanding (but also more reliable and more powerful) version of C. Now, I've been around in the programmer scene since the early 80s. My first programming language was BASIC, and when Pascal and C came around, my first stumble was "wait, what, no line numbers to GOTO or GOSUB?". It was a culture shock. Python and Javascript are the BASIC languages of the 21th century, the journey toward writing programs can only start there. If you can get your job done by writing Python scripts only, be happy and do not worry about not understanding Rust.
Yeah, I believe, Nim is a better alternative, especially for Python devs - you get very safe and fast language without the borrow checker restrains and a Python-esque syntax as a bonus.
@olafschluter706 The more accurate analogy is that you are looking at a niche product's engine, while every other engine in the world has a different design.
@@dolorsitametblue I'd take Julia over Nim, but that's because I dislike Python's syntax. I can prototype in Julia as quickly as in Python but end up with fast compiled code.
@@offensivearch fair. I wanted to try Julia, but it really put me off how bloated it is: it depends on a huge runtime, hello world is around 150mb! That almost makes it non-option if you want share executables with someone. It's really hard to justify Julia's runtime size when in Nim, small utilities I write - are all 100-200kb, and can be statically linked (2-3 Mb exe), cross-compiled for linux/windows/macos in one command (with a little help of Zig compiler).
With 5+ years of experience in BE Web Dev with Java/Kotlin/Scala and currently 2 years with Rust, I would never go back. It's so addictive language. Everything has its place, and once you compile it, you can be sure it will work perfectly. So much so that having 3 micro services written in Rust, working for more than 1 year, none of them had any runtime error.
Yeah I remember when I programmed trading bots as a hobby in JS and the bots would crash randomly every 1 or 2 months. And when I joined a new job, I noticed their JS microservices would crash due to running out of memory and the team's solution was to increase the server memory every time. Those experiences got me in interested in learning Rust.
@@OCTAGRAM the government developing ADA then (somewhat) abandoning it to go back to C/C++ (with restrictions) only to start releasing a bunch of guidance saying stop using C... what a mess.
Virgin Rust dev: Pleeease, I need you to compile my pwogwam 😭 Rust compiler: Noooooo !!!! You didn't respect the owner ship !!!! Meanwhile: Chad c++ dev: Trust me bro, this float is now a pointer to a function. Chad C++ compiler: Yes, Master. _Segfault_
@@Giga4ever The more experience you get, the more you get annoyed when a compiler says "you can't do things your way, you have to do it my way". When I tried Rust I was always like "you don't get to decide, just shut up and let me do what I want". It was seriously annoying. Those that life Rust are into being told what to do at every step.
@@Leonhart_93 And when you get even more experienced you appreciate the compiler being your best friend and just trust that it's probably anyway a dumb thing you are trying to do. Helps also a lot with any real world project where you have more than one developer.
@@artxiom It's the other way around, those that don't know what to do appreciate that. I have 11y of experience and my patience with annoying compilers only went down as time went on, especially these days some languages have take it upon themselves to even tell you how to write the code. A very fast way to make me drop the language, not like these days you need to use a specific one.
I've tried Rust briefly. I can program in assembly easier than I can in Rust, and get the job done faster by far. Second, I have yet to figure out how to handle data encapsulation in a way that makes sense. Third, the borrow checker drove me freaking nuts.
The biggest red flag is when you can do something faster in assembly than in a supposedly higher level abstractisation. The whole point of not doing assembly is that it's slower.
No rust takes time to learn because it makes choices of api for memory safety. It takes time to learn new things, and a borrow checker is a complex thing to wrap your head around. Usually lifetimes are needed when the borrow checker is upset, e.g. data requires other data to live, and thats where things get hairy. Once you've figured it out though its a pleasure to work with @Leonhart_93
@@Leonhart_93 Ehh, I just doubt this is true. I'm sure you can do simple things faster in assembly. I seriously doubt you can write anything of even moderate complexity (ie requiring dynamic size or numbers of allocations) easily in assembly compared to rust.
I've programmed 15+ years in C++ and then moved away for JavaScript/TypeScript for the last 6+ years because of the amount of web development jobs out there compared to C++ (yes, job safety is an issue if you're not careful enough). Now I'm slowly learning Rust (bought the Rust book) and I think Rust cannot be more complicated than C++ (which has become a monster language over the years). Also, Rust has solved a big issue with memory safety which would perfectly place the language in the domain of mission-critical applications. Also, the integrated package/build system makes development with Rust so much easier than with C++. You don't have to deal with make files (those are horror stories!), you don't have to figure out how each library must be linked in order to work). You have the whole build toolchain at your fingertips. You don't need a different build/toolchain under different platforms, your development experience is the same under Linux/Mac/Windows. And with big corporations backing the language I think job opportunities will definitely grow in the very near future. Rust is the new C++ for the next 10-15 years.
I was debating whether or not I should write my server in Rust or Elixir. Even though Rust has much better performance, Elixir has a ton of features that make concurrency much easier to build than Rust and its very stable. I'm also a lot more productive in Elixir than I am in Rust. I've settled on using Elixir for most of my server logic and implementing Rust for things like using database drivers, and anything else that requires high performance like training machine learning models. I'd rather deal with Rust when speed is my top priority. Id rather deal with other languages when productivity and language features take a higher priority. I would love to build everything in one language only but I've begrudgingly settled on "use the right tool for the job".
the problem with rust ecosystem is that only people who don’t know the language well or use it for big enough projects say it is a great language. Real experts hate it in my opinion. i don’t think it will replace C or C++ ever. Also it is nonesense to compare it with Golang or such languages, though it will also never replace Golang.
I have been involved in computing since 1971. My first language was Algol 60, then Fortran, Algol 68, Cobol, Snobol, MIX, PDP-11 assembler. That was my first year at UK University. Since then there has been a new language sprung upon the poor programming masses by the purveyors of novelty. After so much practice I can learn a new language, but now in my '70s I am getting rather fed up with the quest for novelty. Most programming is not from afresh, but modifying and adapting code that already exists, and if it is in an unfamiliar language it is often a matter of guessing, or cutting and pasting - techniques that meaning-in-white-space languages like make and Python conspire to make this difficult. I want to spend my time programming, not learning to program.
I think the lack of jobs is a real issue. I have played with learning it a little bit. But my motivation is not very high, because it seems like the likelihood of getting a job, after significant effort, is not great. Doesn't seem like a great investment of time.
@@vitalyl1327 I may be delusional. Definitely not junior. 30+ years at this. I get satisfaction from writing very high performance and high quality code. I can't do that with just any random language. You sound like the kind of programmer that is much more concerned about the problem to be solved. I am concerned about it being solved well. FYI - I currently write code in FP focused Scala.
I'm liking it more because of its strict typing. I came from TypeScript and I'm fairly a newbie in programming as a whole. I don't know much about how its async operations work unlike in JavaScript though. What I don't like about it is that they use tokio, a library, for async.
@@DCameronMauch there is no such a thing as a general purpose language. If you're a "programmer in X language", you're limited by definition. If you're a generalist engineer, you will use whatever language is the best for this particular problem. Or you'll build a domain-specific language for this problem. Just imagine saying that you're a rice cook, or a screwdriver engineer.
My biggest problem with Rust syntax is the ergonomics. I start to feel physical discomfort typing Rust far sooner than any other language I use. The double colon is probably the worst offender.
I swapped my ; with : a long time ago unrelated to Rust and it it made writing code much easier. Luckily Rust has fairly few semicolons if you don't mutate and use combinators when possible so this remapping is a good fit.
As a Rust & Zig developer, i think the example of the use-after-free is a bit... unfair. It's not common to just clean up memory without using defer in any shape way for form. You have the power to do so, but it more than likely is *always* an error and it *will* stand out as "fishy" code.
I have no previous experience with any "low level" programming language, but I have a bunch of people around me who do. One of them in particular sort of lives in his own professional bubble (mostly a branch of embedded, but where you also design the hardware from scratch), so he didn't even know rust existed, but he has the sort of foundation that makes choice of language "all but irrelevant" to the task... so I introduced him to Rust as an attempt of getting some useful tips. After some coersion, he even read The Book! He isn't impressed, to say the least. He said that 80% of problems Rust solves with its ownership and lifetime models are a question of setting a couple of compiler flags nowadays, and the rest is mitigated by having a general idea of hardware processes you invoke when running an application. I can't check that without spending like 40+ years in the industry like he did, so I just sort of present it like I received it. He showed me a bunch of stuff of his where he just implements ring buffers without even knowing beforehand what they will hold or any real way to check really or sets up a UDP without ANY abstraction just by raw-dogging some magical numbers that he just knows should be present on a struct... (I might be butchering terminology here, but you get the point, I hope) He says he HAS to do it because "that's how ALL hardware works under the hood" and Rust doesn't seem to give you the power to. All of his code would be inherently "unsafe" in Rust... I'm still giving it a shot, though. I'm not aiming for his particular domain and it feels like there's a bunch of bias going on, so I'd like to check things out before forming my own opinion.
He probably is failing to take advantage of what could be done at compile time to improve reliability and productivity. But real engineers are used to not having their hands held, without people dying. They distrust abstractions they have not traced to the roots. A convenient abstraction is an extra burden when you accept that responsibility. And they hate modern products made by non-engineers who can't be bothered.
@@sciptick Aren't compiler flags "compile time"? I'm confused... Barring that, I think you've got a point. I did notice a strong through-line with him... about how "you should know how things work" and that "if you do - you won't need all this obscurantist fluff to make them work". The more I think about it, the more I tend to agree. But I also acknowledge that most domains have their quirks some of which make knowing what's actually going on almost superfluous to the task at hand... :| Not everything is a spaceship, a high-speed train torque control system, or a military communication encryption unit... some things are just non-critical software someone uses to draw funny pictures...
Yeah, I don't have the same experience as he does, but I came to the same conclusion. It doesn't seem like Rust is capable of resolving an actual existing problem without creating many others and multiple roadblocks for you.
@@Leonhart_93 My follow-up after a bunch of fooling around and finishing a test project is "It depends", but I think I'm starting to get where he's coming from.
@@arcuscerebellumus8797: "It depends" is probably the right stance. After the few times I've poked at Rust, my opinion was that it should be considered for things like avionics, and Linux, and maybe nuclear power plants, but I also started poking at writing my own language because I just couldn't agree that the language was actually good. It almost seems bad in a less severe form of how C++ is bad... or maybe not even less bad, but instead slightly differently bad. It's like the designers thought of a few nice _pieces,_ but didn't consider the larger language surrounding them. And for the life of me, I have no idea why they haven't made compilation a two-stage process so that precompiled libraries and object files can exist. It should be fully possible to output borrow-checking and similar info so that language guarantees can be completed at link time.
issues with rust that i find from c++ background are absence of variadic template, private inheritance as composition, overuse of macros (which are hard to debug). Its best things are sane defaults, cargo and traits
Curious what you mean by "private inheritance as composition" as an issue? Also, yeah, lack of variadic generics is a nightmare atm (have to do annoying macro stuff). Another problem with Rust atm is that constructors return the value. Compare this to C++ which constructs using a pointer to the class. This makes in-place construction (almost) impossible in Rust.
@@vitulus_ C++ frequently uses a composition pattern like, struct person {string name;}; struct student : private person { grade gpa; }; this is not a polymorphism, but it allows easy auto implementation of traits, serialisation, CRTP etc possible.
@@absalomdraconis if you think so, you do not understand programming at all. Meta-languages are infinitely (literally, no exaggerations here) more powerful than the fixed languages.
It is for programmers that want that low level control. The "complicated syntax" is just more knobs to adjust, to turn runtime into compile time errors.
I’ve spent a year learning Rust for a couple of hours a day. I’m not sure that it difficult to learn. It certainly is if you get into the weirder bits of Rust but for a lot of coding it seems comparably difficult to C# or Java and easier the C++.
Missed my top 2: (1) Rust does not have safe defaults. For example, panics don't have to be declared, and all the built-in integer types can overflow. Memory safety without GC is excellent, but expected behavior can break without warning in other insecure ways. (2) Glacial compilation speed.
Very good points. Another bugbear is that global_asm is arbitrarily not regarded as unsafe, just because the unsafe keyword has no meaning at global level.
I don't think Rust is overly complicated. Sure, it is more complicated than Python. Let me explain. I am an embedded developer, and my employer isn't ready for Rust yet, so we do things the classic way in C and C++. But since Rust has the potential to be a serious competitor in that segment, I am learning the language now. Comparing to other languages I have looked into, Rust is certainly different, but I wouldn't call it a lot more complicated than others. Yes, getting "something" done in Javascript or PHP is easier, but getting it right and safe certainly not. And then there are languages where getting anything done is hard, like Perl or all those purely functional languages where I wouldn't even know why anyone would want to use them.
@@GaryChike not a borrow checker, but look at the move semantics in the docs (=sink, =copy, =WasMoved) which accomplish similar things, but a borrow checker with their memory management model would be redundant
I don't hate. Programming Languages are tools, not our girlfriends. I simply don't use rust often because other programming languages have more tools and libraries that do a good job. I don't have time, or efforts to spare to reinvent the wheel, I just want to get things done.
Of course you would say this, you have rust in your channel name and therefore must be an official part of the rust foundation because there's no way anyone else can have rust in their name, ownership of the word rust was moved so you get a compile error if you try to use the word rust in a sentence now.
I tried it. The vast array of files and directories formed to compile a hello world program was frankly stupid. What's wrong with a single file compiled by a program to a single executable file? Also the super slow compile time. It took minutes to compile it. The syntax doesn't scare me, but the experience of programming with the rust compiler is not good.
Vast array of files and directories? It's literally just `Cargo.toml` (Rust's equivalent to `Makefile`), and a `src` directory containing a `main.rs` containing your `main()`. Sure, it also initializes a Git repository for you by default, but you can opt out of that with `--vcs none`.
Maybe just use rustc is you just want to compile a single file? You are doing the equivalent of creating an entire CMake project, with a src dir, setting up vspkg, etc and then whine that is is not the same as just calling gcc.
@@Giga4ever All the dependencies you're likely to want (especially with Rust's non-batteries-included standard library) assume use of Cargo. That's why rust-script exists and there's experimental RFC 3424 to explore the design space for supporting something similar directly. Invoking `rustc` directly is meant for implementing Rust support in build systems like Bazel. It's what Git calls a plumbing command, as opposed to a porcelain command.
@@Giga4everThat didn't work when I tried it. It was a long time ago, so things may have got better. I don't have lots of free time to keep plugging at it until it gets better. Zig was nice, easy and quick right out of the box and so I was able to be productive with it in a few days of practice and getting fluency in the language. However 35 years of writing C and almost as much writing python, I don't really need to be nannied with new languages. I can get my work done.
I think the main issue with Rust in the domain C++ is applied is its poor C++ interoperability. If you are working in a C++ eco-system, then you want something that can seamlessly use what is already there. And C++ struggles really hard to find a successor language and - since the recent Cybersecurity Report to the US government discouraging the use of C and C++ - is in dire need to have one. AFAIK the first new programming language with C++ interoperability in production quality is Swift (and only since recently, C++ interoperability has been introduced with Swift 5.9).
Don't do it, you will be shooting yourself in the foot when Rust fails to get the right adoption. Just become even better at C++, learn some advanced applications for it, like drivers for low level hardware.
@@Leonhart_93 In my experience if we're talking about drivers it's C++11 tops in production and more often C++03 or plain old C. Newer C++ standards adoption is also pretty low. I personally faced C++17 (C++20 at best for some open source development like envoy proxy). And even with all goods of C++17 it's the gun pointed to your leg in the first place and programming language only after.
@@LiveseyMD Slow adoption of newer features is indeed an issue for mature projects, but due to the nature of the language it's not that limiting. Hell, people still build and maintain performant systems using C, which barely changed at all over the years. But I think that is exactly why C/C++ will always find purchase, while Rust does far far too many abstractions and forces too many liming factors to be universally useful. For example game dev, some required things are just unwieldy in Rust.
My main reason for hating rust is honestly its community. The language itself is mediocre. It has some nice ideas, but is nothing beyond something you play around for an afternoon with. The community, however, hypes it up to be the "next big thing", which it is absolutely not cut out to be. It is needlessly complicated, and it feels like showing a broken sword through your chest fighting the borrow checker just because rust is cannot for the life of me statically analyze at all. Rustaceans might chop this up to skill-issue, but that's a complete joke. You cannot claim skill-issue when rust's core goal (guaranteeing memory safety) is 100% a skill-issue, and it doesn't even deliver on that (rust leaks memory and considers that "memory safe"). The false promises don't stop there. As a big fan of functional languages (Haskell, Roc, OCaml, etc.), I was promised a functional experience with the performance of C. That is miles from what rust is. It is at most a C++ clone that masquerades as a functional language. Most parts of functional programming (brevity, declarativeness, affinity for recursion, ability to reason about code abstractly, statelessness, "turtles all the way down", etc.) almost completely get thrown out the window. Most of them, while possible, completely ruin your performance, because rustc does barely any static analysis and code transformations beyond the borrow checker and expects LLVM to do the heavy lifting. Considering how mediocre and sold and false promises rust is, I find it a shame, that rust is forced into the position of "the next big language", while there are languages that achieve the same while being actually good. Firstly, Swift must be named here. It is exactly as memory safe as rust, but about a gazillion times nicer to work with while not sacrificing performance. Secondly, Dlang exists. I don't quite know why Dlang is so slept on. It's older than both swift and rust, and does basically everything that is nice about rust. It is starting to show its age though... The fact that this video did not really address any real criticism of rust beyond either "no that's not a problem, you're wrong" or "that's just a skill-issue" is a prime example of why I dislike the rust community,
@@edwin5145 it's "bad" because @porkfatrules is sch1zophrenically engaged in the culture wars and thus is constantly looking for a weaker scapegoat to blame his problems on
@@edwin5145 Not bad. Totally cool if you're into it. But I feel too humiliated when I'm getting talk down to by someone's fursona for not fully understanding the intricacies of the borrow checker.
"Why rust is bad: There is at least a dozen of reasons, but let's iterate the same bs from the main page of rustlang for hundredth time!" Jesus save me from this madness
"hate" because this language is pushed and promoited like u must learn it... or u have no job in the future or smt.. and so many junior or self-learners think they can learn Rust... meanwhile they should actually go to universdity for 4 years and learn Computer Science , Learning rust when you dont understand how CPU works, how to read and write binary and how lower level stuff works and computers and OS in general... is pretty dumb to me. What the hell arte you doing with ur baasic rust knowledge? No company would hire you, Rust is not used for trivial things like web, crud api one problem with rust and learning is also t hey want to sound different for the sake of being different, they rename concepts they call data structures compound types? why? languagesa should stop renaming things, it just confuses people Rust Foundation drama itself showed what thy are... Rust will have same fate as Haskell... obscurity because of elitism and snobism "my program is bettter than yours,becvause im using rtust" , if rust would be so good as they claim, every single company would be using it im neutral about rust, it looks nice @ hello world level... but when look some larger codebases, its very terse and unreadable I'd rather use Crystal , if it would be more mature language "most loved language" is a myth , taking stackoverflow survey seriously is illogical it's very small demographic, mostly americans and old guard... and certain type of toxic people dont people know how toxic stackoverflow is? all the countries in the world actually have different languages wich are most used and loved for example in Estonia python is almost not used at all , but Kotlin, Php, JS , C# gets heavy use. Now some Elixir as well and Go Literally have seen ZERO Rust jobs in this country. Basicly all the large companies use Kotlin/Elixir or C,C++
@@JorgetePanete and that works just fine until you have to define 1000 trait bounds to T just to get it working the way you want. Imagine you have 100 different types that need those trait bounds and you have a boilerplate nightmare
As someone who's listened to plenty of Javascript hatred over time, I'm less interested in RUclips and Reddit comments about a language and much more about what the language can do, and Rust feels very powerful from my limited use of it.
Using an ai tool with rust makes picking up the language a lot easier. The biggest issues i have found is with code samples and tutorials that haven't been updated to reflect changes to the crate.
@@catto-from-heaven That's not nice. People have their own methods of helping them learn. No reason to believe they don't read documentation because of that.
@@vitulus_ "The biggest issues i have found is with code samples and tutorials that haven't been updated to reflect changes to the crate." That leaves it clear
Ofc you have to study prop computer science, that goes for C also, a lot of people doesn't get how to use pointers correctly, let alone understand rust. I've worked with people who attended the "learn typescript in 3 months course" no previous or after knowledge of programming, the nightmares I have reading their code!
I'll tell you the only reason I ever feel "hate" towards Rust, and it's people propagandizing it and acting so sanctimonious about how immature and inferior every other languages supposedly is.
@@RustIsWinning Really ain't though, I ain't gonna deny rust is a good language, but the juice-exuding orgasmic glazing some people give it is just cringeworthy. Facts are fine, but the picture painted by the mention of the likes of "rich algebraic type system" and the illusory promise of never writing another bug again are but a pipe dream. I just want everyone to see reality and if possible, ease the propaganda. Thanks
I really don't agree with those weird rust fanboys, I just thought rust was a breath of fresh air to finally have some safety after all those years coding in C++, I believe every language has an use one way or the other. I am sorry if some immature idiots made you feel that way
I respect Rust, but I have truly despised the time I've spent (not wasted, I will grant) coding in it. It is the only language that made me feel like an idiot. Oh and let us nto forget the explicit political biases of the Rust Foundation (virtue signaling anti-war messages on patch-notes was a memorable one for me), alienating everyone who isnt a progressive.
i can understand the compiler pointing out mistakes to be frustrating, but the complaint that rust is pro human rights is just nuts. those who are against human rights just simply don't have a place to exist in the future we are heading towards and it's time to stop catering towards those who are vehemently against human rights
I'm a C developer. I can't say I hate Rust but I tried it for one project and definitely it's far from being a productive language, at least for my standard. I can't care less about the borrow checker or the standard library. I have other ways of avoiding/diagnosing/fixing those rare memory leaks. I can just do much more with much less and in my case Rust just kept getting in the way. Like C++.To each their own. For sure, the drama around it makes it even less appealing. I like stability.
I dont hate rust. But i suck at it, I can write it, i can read it. But everytime i write rust, its not clean code and its always really ugly or hard to read or ugly to handle errors or map errors (even with anyhow/thiserror)
thats just like how rust is... nothing to love there, unreadable i like Crystal , C-native bindings if the language would be more mature, i wouldnt be afgraiud to use it ; ) in production Its basicly what typescript is to JS , Crystal syntax is almost identical to Ruby but has c speeds and statically typed
@@Microphunktv-jb3kj I came from a C++ world and rust is literally a godsent in that direction. or rather a better replacement for shit that needs to be secure / hard to crash. So, in that regard i still love rust. Never tried crystal, did try ruby; didn't like it. But tried Elixir and it was really fun to work with
A lot of Rust programmers are likely on the younger end. When you're over 60 and being asked to code in yet another language, I guarantee you'll behave as older programmers do now.
@@salvoilmios Double linked list has runtime invariants, that are not easily representable with the Rust's type system, that's why it feels so verbose. But in C you just completely ignore the invariants and pretend that the program you just have written actually works.
@@salvoilmios Just use a couple Rc's and you're done. In all seriousness, these things are only difficult in Rust because Rust developers try to make them better than they are in other programming languages. It doesn't take much to get JavaScript-level performance using Rc's or C++ levels of safety using raw pointers. The issue only starts when you want to surpass that.
Instead of studying rust, I'll dive into computer architecture and organization, operating system principles, then C/C++. In my opinion, rust is just a "tech bubble"
It'll stick around, but I don't think it'll be the final C or C++ killer. It'll probably always be in second or third place for low-level systems languages.
@@TheDragShot Rust will overtake C and C++ in popularity eventually. No other way around that. Most big corpos are pushing it also, for good reason. They are tired of mistakes costing them billions that can be caught by simply using a better language.
@@hagaiakif there's a language that'll overtake C it'll be Zig. You cannot get rid of a language that's so widely depended on with a radically different one that's so majorly incompatible. You take over by integrating and migrating the existing base to your team.
Just saying, go has been a much better experience for me but I’m trying to make a game. Rust and game dev don’t get along nearly as well as people claim for LEARNING game dev. Maybe it’s great if you already know everything you want to try to do
At 7:40, you mention about skill issue. IMHO, I think it's not the skill issue, It's more of -- Wasting more time learning a programming language than giving more time to write big software's. If a programming language itself is giving more headache that actually focusing on writing software, there seems to be an issue with the language and needs to update itself. I'm not a Go dev btw. I write programs in C++ and Python.
You nailed it. This is the reason why it will never become as widespread as C++. The language should just allow you to solve a problem, instead of becoming a problem to solve.
That's why I replace every looping method with a for loop (except for maybe the spread operator). It becomes especially good when you learn that a for loop can have multiple "header" declared variables, and more post-check actions (usually people just write i++).
I've been seeing a number of job opportunities for Rust. I haven't seen any for Zig or Go. But I might be looking for the jobs that wouldn't favor Zig or Go. Go was not made for 5-year-olds. But Scratch, on the other hand, was.
I did a brief stint writing Go. I hated it. Too overly simplistic and unexpressive language for my taste. Things I can write in a single line of Scala takes like 50 in Go. Anyways, just having that on my resume, I get contacted all the time about Go jobs.
@@DCameronMauchthat's my big problem with go, for something that sells itself as easy to understand. It's really frustrating having to read a novel to figure out one function. Yes, each of the lines are trivial, but there are a billion lines that in most other modern languages wouldn't need to be there.
@@ngin6917 go syntax can be verbose. however you can do stuff with go that you just can't do with any other major language. the concurency primitives and support in the runtime are revolutionary.
Honestly the reason I dislike Rust is simply because I hate the holier than thou attitude that radiates off the language and everything related to it. the idea that "the compiler knows best" when you need to practically be a language maintainer to implement CS 101 data structures just convinces me that the entire language is insufferable and will be utter torture to write.
Yeah that's stupid. When I already checked if the object is ok before use it, the last thing I want from the compiler is for it to tell me that I can do something with that object because "it's unsafe".
@@Leonhart_93 You just don't understand the basics of Rust. At least the commenter raised a valid point while you are just arrogantly repeating the same ignorant take under every comment.
@@Leonhart_93 Every single compiler and language has rules about how and what you can express. Rust sets out to disallow things that often lead to errors. You don't like it because you are arrogant and you didn't took the time to understand how rust works.
@@terryriley6410 The difference is that most compilers, especially the low level ones, only have the rules that are guaranteed logic errors, like missing memory location. Rust just has way too many restrictions even for cases where it won't necessarily happen. In the end it's a new paradigm created by a few people, I have no expectations from it.
More often I've witnessed the opposite, with people thinking that newer is better than older (e.g. the newest Electron-based framework is surely better than the older smaller faster thing...). People accept new things just fine when those new things fix the problems they had with the old things, rather than just solve old problems they didn't have to begin with while introducing new problems they didn't use to have.
If 20years experience with c++ equals 10years with rust and you have the c++ experience, then you might be 40-50 years old and retire before rust even squares
Compare map function with go, not js. Go provides type safety and is statically typed language, yet the map realization would be 100% easier to write or understand what was written
The fact that there are people complaining about the amount of compile time errors they encounter in Rust baffles me. Oh no, the language has saved me from dealing with all of those issues in production when its a gazillion times harder and more expensive to debug, has caused a lot of damage to my users and made headlines as the latest security breach. Amazing.
The memory safety argument is only partially valid. Memory leaks can still occur in Rust. It’s safer but not fail safe. You still need to know what you’re doing. Which brings me to the biggest problem I have with rust. If you know what you’re doing, chances are that you also know how to properly code with memory safety in mind. So what problem is Rust trying to solve? And more importantly: at what expense? The loops and hoops you have to go through to satisfy the compiler, is just a big no no for me. Rust certainly has some interesting concepts I wish were implemented in other languages as well. But for me writing code fast is enjoyable. Battling a compiler is not.
It's the little things. What people often fail to show is that it saves you from making very subtle mistakes, because those are difficult to condense into a single slide. Memory leaks are not unsafe. Unless you run out of memory, they're just annoying. Writing/Reading garbage from memory because you accidentally referenced something and then the buffer got reallocated by some code in a completely different part of the codebase, is. You can "properly manage memory" all you want, it's bound to happen at some point in very large projects. Microsoft, Google and others all have sensible and strict memory management guidelines, those kinds of problems still arise. As for battling the compiler, I've found that after getting used to how Rust expects things, **most of the time** I don't really have to do that anymore. Writing Rust in general is pretty straightforward once you got used to it. But yeah, when you start to mess with lifetimes, especially multiple ones, it does become really frustrating sometimes. But at the end of the day is either that or risking to introduce a very subtle memory vulnerability that will be exploited further down the line. I do agree that fast prototyping isn't its strong suit though.
@@maximumoverflow901 Those "little things" you speak of aren't reason enough to break your back trying to implement basic features in a very obscure language.
@@Leonhart_93That's an exageration. Unless you want to do some really performant zero-copy stuff, at which point lifetimes become important and sometimes hard to deal with, pretty much everything you could think of is just as trivial as in C++, or better. In terms of ergonomics and general use, Rust beats C++ hands down. I would never consider writing the equivalent of a quick Python script in C++, but I find myself just defaulting to Rust in times like that. Does it solve all my problems? Of course not, but the whole borrow checker and learning curve thing is extremely overblown. Like it or not, Rust is here to stay. ...with that said, the community is exhausting.
@@maximumoverflow901 No really, I tried to implement some relatively easy structures like a global multi dimensional hashmap stored in a singleton that stores and dispatches functions. I always implemented this structure in PHP, JS, even C++, and all do it fast, seamless and without complaining or extra boilerplate code. Just some assignments and calls. No so in Rust, the experience was beyond infuriating. Had to fight the borrow checker and lifetimes at every step. If me who has 10y of experience feels like that, then a newbie has no chance.
@@Leonhart_93That sounds fairly easily achievable in Rust as well... It's a different paradigm. If you go in with the expectation of doing things *exactly* as you do with those other languages, then yes, you'll have a bad time, but oftentimes just a slight tweak to the way you approach the problem makes most issues go away. Once that clicks, honestly it's not as daunting. Now you got me curious though... Do you have a concrete example of what you wanted to do?
Honestly it's not about the language itself, but more about the community that developed fanaticism (at least it used to be like that maybe it changed)
I guess most people who have problems with Rust's syntax don't have a proper formal background in Computer Science or Computer Engineering and just code in languages like JS or Python
@@riccardosagramoni8016 No, I have all of that, I just hate that it tells me what to do even when I took all the right precautions to make sure there is no way I created a memory issue.
@@Leonhart_93 Are you really sure about "taking all the right precautions" in 30, 50, 100... thousands of lines project? I don't think so. We have computers to think about "taking right precautions". I feel just safer when I know that I possibly can't create a memory unsafe code. We are people, and we make these kinds of mistakes. And I don't want for sure my code to fuck up in production because I was too confident in my rightness.
@@rastr__9042 Safe, safe, safe. I never felt unsafe, if I made a mistake then it was my fault and then I strived to make it better. That's how people wrote code for like 80y now and it doesn't seem like it slowed down our progress in any way. But forced restrictions at every step, even when they are not required, is not the way to go.
📝Get your *FREE Rust cheat sheet* :
letsgetrusty.com/cheatsheet
Богдан здаров, часом ща не приехал погостить на родину?:)
@@sergeydev8273 "too woke" - это он точно подметил
"Statically typed" doesn't implies "verbose".
Look at Haskell, for instance.
I don't know why language creators keep inventing weird bicycles while most of the good stuff has been already invented long time ago.
My opinion that Rust is an abomination, it has many good features that older language don't have, however it also accidentally got many ugly things that these language had (for instance, abbreviated keywords, subtyping. C-like syntax, or even worse).
Weird.
😅@@sergeydev8273
Wow, just looking at Rust's syntax, I'm convinced it's written by demonically possessed people. Who in their right mind wants to do the mental gymnastics for 100k lines of code written that way? Wow.
I think Rust's biggest mistake was not calling their objects "Buckets" Then they could appropriately be called "Rust Buckets".
but crate goes well with cargo
Missed opportunity indeed 😅
The hostname of my development machine is "Rusty-Bucket". Maybe I should put it in a bay?
Sounds like something a character from Monty Python could say
@@RenderingUserYou can always say "Rust cargo" or "Rust crate".
Who said that crates are not made of metal and cargo can't be of metal parts?
There are more jobs where you talk about Rust than there are jobs where you program in Rust.
Yeah, sadly when I write something in rust it just works and no one needs me to put out fires constantly. So I am just talking how great it is.
It's not that difficult to learn imo. It's just different. @jazzycoder
Sounds ideal
Sounds like a bubble.
And why is that? Self-fulfilling prophecy.
Rust makes it hard to write bad code by making it hard to write code in general
Finally someone said it
Hahaha true
lol
the gate keeping lang. only einsteins can do rust. even the linux kernel c devs aren't einsteins and kick out the rust leader
@@Henry-sv3wv Idk, I'm writing my scripting language's compiler and interpretter in Rust and it's kept things smooth operating while improving readability and consistency across the entire code base, since some things are inherently long-winded in a language parser. I could see myself easily messing up at some point or creating memory leaks if I were to use C or C++, Rust is preventing these issues inherently.
I also don't think I'd consider myself an Einstein, you're an Einstein if you wrote what I've been writing in C without errors the first time you write it. Rust is "holding my hand," so to speak. I have memory management training wheels on, while not sacrificing performance.
2. Comparing a weakly, dynamically typed language's syntax to a statically typed language is unfair. The latter will always be more verbose.
Counterpoint: Haskell. Haskell's declaration of map is literally
map _ [] = []
map f (x:xs) = f x : map f xs
(I wrote it off the top of my head, but then checked and the official implementation is 100% identical)
It can't be less verbose than than.
Recursion everywhere ❤
@@vytah True - but although Haskell is statically typed, it's also strongly typed, not weakly.
@@tobiasvl Haskell is strongly statically typed.
@@vytahReal programs in Haskell have type signatures for all top level functions and often inside functions for the sake of documentation and correctness. All the user defined data types often consist of smaller type helpers and other types too (e. g. newtype definitions). All this is usually not present in the programs on dynamic typed languages.
By learning Rust. I've started to think more about error checking and results in my C# code. It is making my programming better overall.
True for me as well
Me too. By learning Rust, my C++ code is much better.
@@yubing0625 yes, me too bro
The more I'm growing up as a professional dev, the more I think the sentence "choose the right tool for the job" isn't actually that relevant an advice.
To me, a language should be chosen to be in adequation not only with the task at hand, but also with the team at hand. I belive both are equally important. And to be clear, I'm not talking about the general skill level of the team, I'm talking about their mindset, how they approach software development in general, and how they are comfortable to work. In other words: their preferences.
Because we like to think of software dev like it's 100% some objective science, as in "for each problem there exists an optimal path to solve it", and we often dismiss the importance of "mere" personal tastes and the importance of subjectivity in what people consider painful or boring.
For instance, verbose type signatures and unmerciful type checkers are actually a selling point to me, not because I think they are The One Right Way (or because I'm masochistic), but because I just hate debugging, and I don't mind longer build times because it means the compiler is doing more stuff for me. Just like you say, I just love that fuzzy feeling when after spending hours on a code with only type checkers hints to help me, never even actually building my code (that's why long build times in Rust are actually not that much of an issue for a lot of projects), I build & run for the first time in hours and it just works.
But if such an approach makes a lot of sense in Rust or Haskell, it would be a _terrible_ thing to do in e.g. Python. However, what pains me is not what pains others. Other devs prefer to see results quickly, optimize for iteration speed and are okay with the longer debugging sessions it entails, because they know their tools, they are pretty fast to zero in on the source of the bug, and they may even enjoy the challenge it offers. And at the end of the day their dev process can even be faster than mine. They just don't have the same mindset than I do, but it's equally valid and they are not worse devs than I am for it. It just comes down to preferences and workflow. And I cannot imagine the world of pain they would endure were they to tackle a project in a language like Rust that is so antagonistic to their mindset.
True, this claim needs to be mitigated depending on the exact nature of the task at hand (you wouldn't make an OS in javascript, whatever the dev team), but for a lot of projects, there can be a lot of potential "right tools" for the job.
Another point, hinted at but not stated explicitly in the video, is that Rust's borrow checker forces a whole different set of programming patterns than a programmer may like. Yes, this is by design: these patterns are more obviously memory safe (i.e. verifiably safe at compile-time) than their alternatives, and it's generally a good idea to learn them so you can apply them to your favorite non-Rust programming language. But very often, the other patterns are just as memory-safe, possibly even more appropriate under the circumstances, and yet the borrow checker gets overzealous and prevents their use.
The problem with Rust is that they try to reinvent each term. Most of the time you try to rewire your brain to understand that a crate is a library, or what is an arm or a trait.
like, I'm sorry but I was hoping more of a genuine critique rather than a takedown of arguments. this feels a bit like a strawman.
(Haskell has also shown us that you can have complex function signatures without them looking this awful and cluttered)
For non-trivial applications language simplicity is more of a liability than an asset. I'd much rather have the compiler discover problems in my code at build time than have my users find them at runtime.
You and me both. Believe me, the worst kind of "magic" that can be on programming is the one that the developer has little control / information on how it works.
those two things have nothing in common. A language can be simple and have compile-time checks.
@@hwstar9416 Or complex and needs more of them aka C++.
@@hwstar9416 that's not quite true. With simplicity comes ambiguity, sure there can be compile time checks but there are still much more assumptions being made by the compiler. (Proper testing can mitigate this concern however)
@@boycefenn "With simplicity comes ambiguity" I'm sorry what? I think you're confusing different ideas with each other.
"there are still much more assumptions being made by the compiler" What do you even mean by this?
Long compile times in comparison to stuff like golang and typescript is the biggest surprise and cause of the hate. If you are coming from c++ to rust, you expect it...but from those languages to rust, its a shock
Compare to big js project linting time it's not to much difference
@@ІванБоровик-э8л nah..its not comparable. Compile times of a big rust project and the lint time for a big js project cannot be compared...rust still losses. The compilation time thing is a big issue and will always be a shock unless its fixed
Incremental builds during development are pretty good, imo. Often with Rust, people don't treat it as a systems programming language, and compare it to non-systems languages, like Go.
Its one long compile the first time you start a large Project. Every compile after that will be fast. If you dont spend all day changing your depndencys, you wont notice the compile times.
@@nsubugakasozi7101 you just haven't seen big js projects
I think another part of it is certain ecosystem problems. I write in rust for hobbies because I really like the rust environment, but I have so much trouble writing graphical apps or games or anything user facing, because all the graphical stuff in Rust is still in its infancy. It's gotten a lot better with things like Slint, Dioxus, Bevy and the unofficial godot-rust, but these all have bugs or limitations that prevent them from being used for major projects.
I do feel like we're on the right path, but I don't feel like there's a mature enough graphics ecosystem for most app developers to join Rust yet.
Huh? Why do you want to depend on some third party code for something as basic and fundamental as graphics? Build your own. Regardless of the language.
One only has one life 🙄
@@vitalyl1327 Yeah sure, graphics can be basic, just like an AI can be as simple as a goomba from mario that only walks left and right. you're definitely not writing your own graphics lib / gui toolkit that is cross platform across mac, linux, windows. doesn't even make sense.
@@dany5ful have you seen the Dear I'm Gui library? A perfect example how easily a cross-platform GUI can be written. Look at it, understand it, then write your own.
Have you tried Iced for the GUI? It's being used to create an entirely new desktop environment, Cosmic.
I went from C to Rust, and the main problem I had with it was the forced paradigms. It doesn't let you code the way you want to code. You can't write intuitively. It forces you to do things that feel gross and unintuitive, because it doesn't trust you. I just don't want to work like that.
muh freed pointers!
I agree. And when you use unsafe to try to tell the compiler you know what you’re doing, the compiler tells you “you might know what’s going on in c, but you don’t know my rules.” So you end up getting a situation where you write it exactly like you would c, but it’s truly undefined in rust. So annoying. As someone who’s using rust actively for a largish project now, I can say I just don’t love it
This is one of the key things that always bothered me with Rust, The fact that it will warn me if I don't use a certain case type while writing out variables or whatever is frustrating.
@@MasterBroNetwork I don't use Rust yet, but maybe rustfmt helps to format everything in one go
@@JorgetePanete That's just it, I have my style for variable casing or whatever and I do not want to conform to Rust's style so the fact that it complains for me not using a certain style is infuriating.
I've been learning Rust for a few months now (I'm a Ruby developer in my day job). On my hobby project, I fight the compiler a lot. On the other hand, when I'm done fighting with it, my code usually works.
Ruby is an elegant language. So it's good to ask you: As beginners, we run away from Rust because we hear about it's difficulty? What do you think beginners should do in the first 3 months to keep cracking this difficulty?
I see no real use case in the enterprise software area for a programming language that is hard to learn, hard to write and... hard to read. This is crazy! Who will pay for that? Because it's hard in every aspect it will required just more time for development. Java beats it and JVM is fast enough for handling quite high work-load. That's all what we need.
Yeah, that's how every good business decision will look like. Ultimately this will be why Rust will never see large adoption.
I really really wanted Rust to be my goto general purpose language... While it does have quite a bit of built in little things that let you ignore good practices and write dirty fast prototype code, it doesn't excel at it compared to some other languages. I don't tend to build programs that already exist, which means a good chunk of what I do is prototyping and testing and throwing away code as I come up with better approaches. The trouble I have is that takes longer in Rust. However, once you know exactly what you are doing and you know the thing you are building will live on and be useful for quite a long time, that seems to be when you want to involve Rust as that seems to be where it shines. Unfortunately for me... that's just not where I tend to sit professionally so I barely get a chance to use Rust.
That's basically the kind of code I mostly write for work as well, with also often having to provide a GUI of some sort from the get go, plus an integration with external formats and/or applications.
I normally used C++ and I know enough about it and the ecosystem to not be in pain all the time, but in reality writing C++ feels like walking in deep mud with slippers with no end in sight, a horrible unrewarding experience.
I tried Python for the prototyping stage, but it just doesnt make sense in most cases because I'll always have to rewrite in a serious language anyway for a plethora of reasons so might as well not waste my time and use it from the start.
I tried Zig, but it's way too unstable and unfinished at the moment, I can't afford having to deal with constant changes to the build system, standard library, etc. Also, it's not the most convenient language for shitting out code that you don't really care that much about. It's great for achieving very particular things in a very particular way. Great for when you want it, pain otherwise. Also, it's extremelly niche and has basically no documentation or resources for non turbonerds to learn, so good luck pitching it to your coworkers and boss.
Rust has so far been a hit. It has nice tooling, superb documentation with lots of examples, lots of crates for doing various things, and I find the iterator adapters and various other functional aspects in particular to be a huge convenience for the type of domain code I write. Sure, it is quite hard to learn fully, especially for a newbie, though not anywhere near C++ level of hard, not even close. The difference being that there is a sense of reason and intentional, consistent design all throughout, so lots of things fall into place when you come to understand certain key aspects of the language. Sure, some things tend to be more verbose and inconvenient to write than I'd like, but with all the other positives considered it's still come out on top for me.
To me the annoying part is that Rust programmers cannot admit that the language is complex/difficult, and want to gaslight you into thinking that it's easy if you just learn a few principles and read the error messages.
Does anybody actually say that? I've been programming in Rust for about 6 years, and I don't think I'm an expert yet. But to be fair, people certainly overestimate the difficulty. The classic "fighting the borrow checker" is weird, because you get the hang of it fairly quickly. All you need to know is who owns the data, and that you can only mutate in a single place.
@@tinrabI'm working with Rust for quite some time and I think it's freaking hard to learn. The borrow checker is only the first hurdle.
"The function exists on type X but the trait bounds are not satisfied" 😭 just one example.
Rust is praised for it's great error messages, but they only make sence once you understand why your code should be written differently.
I still love Rust and I'm productive, but it's a painful journey. I think the pain pays off, but it's pain nonetheless 😉
@@tinrab Borrow checker is the simplest to grasp imo. But there is also the type system, lifetimes, the way macros are...
@@gzoechi Oh, that would mean that the function exists, but only on a trait, so you need to implement it. But yeah, it's hard.
@@tinrab I know what it means, but not how to figure out what trait is not implemented. It's easy for my own types and traits, but hard to figure out if it's from dependencies.
My annoyance with Rust is due to the armies of Rust developers trying to push C++ out of existence. It was refreshing that you made a point of _not_ doing that.
@@isodoubIet as awful as C++ is, even (modern)C++ cannot push C++(98) out of existence
One of the biggest issues I have with Rust is that it's virtually impossible to "pick up and explore". A lot of "modern" languages are reasonably straightforward to the point where you need to learn very little syntax and can get started fairly well. For example, if you've never programmed Python in your life and come from Java, then picking up Python will be relatively easy.
But Rust requires you to learn so much before you can do anything, that a lot of developers will just say "screw it" and pick a different language.
Yeah, but that’s kinda by design
Rust has a lot of its own design features to force you to make safer code. Obviously, having concepts that basically no other programming language has and don’t directly translate into compiled code does make it a lot harder
@@palmberry5576 It doesn't help that a lot of times those features are enforced needlessly. If I already checked this object for safety, the last thing I want to see from the compiler is telling me I am not allowed to do it because it's "unsafe".
Have you noticed almost every, if not all, beginning Rust tutorials use the macro ‘println!()’ vs ´print!()’.
Because you can’t simply write:
print!(“What’s your name? “);
let mut name = String::new();
stdin().read_line(&mut name).expect(“Failed”);
You have to flush the buffer. 😮
print!(“What’s your name? “);
stdout().flush().unwrap();
let mut name = String::new();
stdin().read_line(&mut name).expect(“Failed”);
It depends where you are coming from - if you have experience with functional programming and C++ Rust will be also easy (it was for me at least).
@@GaryChike Well, that's standard in system programming. In C/C++ you have to do the same - stdin/stdout/stderr are buffered, doesn't matter if you use fprintf or C++ streams. You can also disable buffering if you need to.
You have Zig, a beautiful optimazation between human factors and machine factors.
Devs hate rust because people think it's something life changing and revolutionary but when you use it it's just more complicated for literally no reason.
You forgot one important thing: Rust Cargo crate system! Imagine someone opening a PR with 100s of crates. It will be impossible to review each one of them. The dislike for rust comes from there as some people speculate that cargo is going to be like npm.
yep. that is one qualm i have. the push for just using crates. while on its surface it seems fine, but when one needs to audit the dependencies for supply chain attacks and licensing, it does become harder with more dependencies. i am working on trying to get people to be less pushy about just using crates
The reason people hate rust most, is that developers don't want the restrictions and overhead which come with Rust's bullshit promise of safety. Borrow checker, being one of the big manifestations of that. The performance promises are a lie and the language performs much worse if used idiomatically, than other systems language choices.
7:42 "Don't blame a perfectly designed language on a skill issue" is certainly one of the statements of all time
(Edit: for context, he says "jokes aside" like 3 seconds later, of course Rust is not a perfectly designed language lmao)
a perfectly designed language🤡and then you try async Rust. Bro just can't keep Rust propaganda from spitting out of his mouth. I doubt he has any technical expertise aside from being a tech content creator to begin with
@@rw_panic0_0 I think async is pretty good. What does it look like in other systems programming languages? We'll see how Zig turns out. You have async/await, where `await` is a suffix call, which means you can have chaining. The hard part comes with pinning, but I almost never have to write that. Streams are also great. Recently I've been using `async-stream` create, which allows creating streams with imperative code and using `yield` keyword, just like "generators."
>perfectly designed language
Rust is many things but "perfectly designed"
It's *almost* perfect.
@@rw_panic0_0 Whats are your Problems with async Rust? Its very performant and easy to write once you have some experience.
I'm from java. 10+ years. I wrote a test in rust. I use testcontainers in it. I fill redis with some data, verify them. The test runs under 1 sec. The biggest relief in my life. No words to explain that. Now the tough part is to find a job.
40+ years in java, can confirm
Amateurs
@@Hello-fu5wdThat's impressive, given that Java 1.0 came out only 38 years ago. Was it even called Java at the time?
@@Hello-fu5wdyou were programming Java in 1984? Lol
@@SimonClarkstone1995. 29 years ago.
I'm a developer with autism. Rust is neat and the safety features are pretty cool but it doesn't satisfy my curiosity like C does. If anything, Rust doesn't even compete with C but complements it.
I think exactally like you
>developer with autism
found rust's target audience.
What are your thoughts about zig?
at 4:30 you mention that rust is being used in aerospace and automotive applications. This is demonstrably wrong, rust has no formal specification unlike ADA, C, or C++. Because of this it is impossible to get software written in rust approved by FAA and relevant bodies for use in mission critical systems aboard aircraft or car controls. The rest of your points for rust are reasonable, but lying so blatantly; and for such a key point is disappointing.
I've personally used rust in an automotive application. He's not wrong.
Rust looks to me like Swift done the hard way.
I'm actually wondering if it would be possible to create a language that starts out like Swift, easy and relatively safe, and which can get progressively safer if you opt into that.
For example, the reason Rust needs all that borrow checking, is because almost all variables in Rust are by default passed by reference, because of course that's faster than copying by default, which is what Swift does. But what if you'd start out with a copying-by-default model, because that's much simpler to work with, but you can opt into a passing-by-reference model whenever you want to make your code safer?
let str1 = "This string constant will be copied by default"
var str2 = "This string as well, but this variable is mutable"
let ref str3 = "This string constant will be passed by reference, ownership and borrowing rules apply"
var ref str4 = "Same for this mutable string"
Or something like that.
@@EvertvanBrusselyou can pass both by reference and by value in Swift.
@@EvertvanBrussel wdym rust is pass by value by default. To pass by reference, you need to use & or &mut (or unsafe)
@@SilisAlin Yes I know, but then Swift does not apply the ownership and borrowing rules of Rust in those scenarios. Swift relies on ARC, which works well enough in most situations, but is not as safe as Rust's rules for references. For example, in Swift it's still way too easy to create circular references that then never get deallocated.
@@yuitachibana8829 If I understand correctly, in Rust when you pass a variable, in most cases, you're either transferring ownership of the value or you're lending / borrowing a reference. Both of those I would say is "pass by reference", since "pass by value" usually means to copy the value. And as far as I know, copying is not the default behavior in Rust except maybe for super simple types like integers. In Swift, structs are passed by value, meaning that they are copied by default.
Whenever I see Rust mentioned, most of the time it's the toxic part of the community: bullying Rust devs for `unsafe` code, bullying devs for not using Rust, hostile rewrites, vandalising wikipedia. It seems like some portion of rustaceans are edgy teens from 4chan. Not the people I would like to hang out with.
Damn C++ has better syntax than Rust.
Well, if you have a base in C, C++ syntax is 'better'.
The C++ templating / meta programming though is *horrible*. Rust is not perfect but at least now I am proficient at metaprogramming and it helps when you build libraries.
Oh HELL nah. C++ boilerplate made me reconsider my life choices and one of the bigger factors that made me stick with Rust; Rust felt so clean.
@@tototitui Metaprogramming became significantly easier in C++ after concepts were introduced in C++20. They should have done that earlier to be honest. Rust was ahead in the game with its Traits and Generics.
@@tototitui that's what I hate the most about cpp too
Rust and C are both "hard" but in different ways: C is hard because you have to learn to avoid the dangerous parts of the language: stuff like buffer overflows and memory errors. Rust is hard because you have to learn to work with borrow checking and a more complicated syntax. People don't think of C as hard because it has a much shallower learning curve, but really it's just as hard to do *right* and when you screw up the consequences are far worse
Exactly.
Probably helps that people who learn C also love to learn about how computers work.
things that would be tiny changes in C/C++ so often require big rewrites of program sections in Rust because introducing new (mutable) references is often illegal.
Rust discourages fast development iterations, which is especially damadging when the product vision is not yet totally clear (which is why I can never see it take of for game development).
I guess if you want to have super stable, perfomant stuff you rarely need to change, its awesome. But then you are probably a bank and boring af
I don't have fuzzy feeling when my Rust program finally compiles. I have a feeling of wasted time that I spent 10x more time on coding in comparison to similar program in Go.
I love Rust but I have to admit that there's some Stockholm Syndrome involved
I'm still not convinced that Rust isn't a cult.
i get it, the language maybe isn't that bad. But the reason why i don't like rust- is not with the language (though that syntax gives me headaches) - but it is with it's programmer base.
And i don't want to sound like an asshole- but i probably will regardless. So here's my reason:
For some reason, whenever i encountered a rust developer- be it in university, in the field, through social media whatever platform suits you best- it's always so difficult to have a normal human being conversation with them. Like a normally developed adult. And before you all come slinging words like "we're autistic!" or "you're a boomer" - i get it, but i'm a damned embedded engineer.
If there's anyone that's going to be the most autistic out of us all- it's probably going to be me.
Yet, I still put my best leg forward, i still take a shower before work- and my classrooms weren't some cult trying to rustify anything (or c-ify anything in my case i guess)
We just had our use case, we had a language that's been in this field for litteral decades. And it's our goto language for our complicated engineering needs.
But then come the rust evangelists shouting about memory safety and "ackshually xyz" or "you know rust can do that too?" and i just wish they would shut the hell up for a minute.
Nobody asked, Nobody cares, and i hardly know any engineering office enviorment that likes people that cannot shut up, just make it work and most imporantly - work together.
For real, why does it attracts only those types of people?
@@Leonhart_93 It goes both ways. I seriously saw like 50 of your comments here were you can't stop hating on Rust, despite clearly having no experience in it. The "Rust hater" crowds is just as obnoxious as the evangelists.
True, the community is insufferable. I don't even hate the language, and use it for some of my side projects.
@@Giga4ever something something action-reaction
while there are some problems like the push to use a bunch of crates, but overall the language and community is fine. using a lot of crates becomes an issue when you need to validate licensing and supply chain attacks
I hate about rust that rust fans will take a video about how and why people hate rust and make it propaganda for rust. You can't just enumerate things people don't like, you want to still enumerate why Rust is so good. I have seen this in fans of other languages, but with rust is taken to another level. This video is "why do developers hate Rust?" and less than 1/3 of the video is about why people don't like rust.
So here's the thing I think happens with things like Rust, and say... Linux (probably other things too?) ... Godot - They are complicated and don't work the way you expect out the box, so people spend a bunch of sunken time trying to make them work, trying all sorts of different things, reading docs, trying to understand from the mindset of the creators ... that you can eventually develop a sort of stockholm syndrom or sunken cost fallicy, where people just start to obsess over the thing and get into arguments over minutia with others in the community, forms a sort of cult, where these videos are the cult leaders.
There are definitely other REALLY GOOD tools out there, that get the job done, are not surprising, are even pleasing to use, but since they aren't complicated and confusing, don't get nearly as much air time because there's not nearly as much to talk about - "It does the thing without issue" is not as interesting or mind snaring
@tomasbanzas2431 : I would have written this myself if my english had been better 🙂
it's a mentallity thing. i don't feel like going in to politics - but have you ever looked at their profiles? hell- their github's even, there's a reason why there's 15 different "problems" that nobody else ever heard about.
There's a reason why so many have 20 different flags in their bio's.
It's not cause it makes them better team-players, and it's not cause it makes them office compatible.
I thought being an embedded engineer made me the worst sack of ass on the office floor. But i'm starting to doupt that title should go to the mentally distraught smelly there in the corner.
The language won't be mature until people are allowed to complain without waffling.
I agree: I only searched about Rust on Android, not about dislikes; it’s YT that recommended that to me (I should have known better).
The 1st video on the dislike topic was a parody, so actually meant to praise Rust. And now this one; second red flag IMO.
The last time I experimented, Rust was still developed in OCaml.
I've seen a lot of neat arguments in support of Rust, but the paradiym shift is just a little too much for me - it forces me to think long and hard about every single line of code I write, which makes prototyping just impractical time wise. I want to write something fast and have it work (to get my ideas out), then after have a linter tell me how I can make it correct. During development, code is constantly changing and shifting - constantly putting in the extra effort beforehand unnecessarily spikes development time.
It does sound like Rust is a poor match for the type of development you need to do.
sounds like you just need some python in your life
Where is "slow compile times" on that list?
Surprisingly, not there
Well, actually, C++ has a similar problem. There is a cppcon talk of Chandler Charruth about the cost of C++ abstractions here on YT, and one of the currencies you are paying for using them is "compile time". Which in C++ is mostly due to all that template stuff, in Rust it is mostly due to delivering libraries as source code. There is big room for improvement here on the Rust side. The other weak point of Rust is C/C++-interoperability. There's cbindgen to get access to C functions and data structures and use them in Rust code or exporting Rust code to C, but there is nothing allowing for the usage of C++ code in Rust. That's why Rust isn't the best candidate for a successor to C++.
Be careful when you guys say "it's easier to refactor and maintain" etc. Unless you are a professional Rust dev in a team, you probably have no idea if it's true in real scenarios. That's why people call for propaganda sometimes. Every tech is amazing when you only use it alone, on a side project i guess
It is true, but it's also the case for the opposite, people cannot say it will be harder to maintain without having done it in bigger projects with a team.
Only lang-specialized professional devs can refactor and maintain code so I don't know why you're thinking he's wrong
@reiniermoreno1653 so you don't maintain and update your own side projects?
One day Rust will be as perfect as Dreamberd.
And then we'll wake up
Even using brainfuck as a joke programming language is funnier than dreambird
dreamberd is a bad joke language because it has features that are genuinely cool like using ? to print debugging messages
Personally, I’ve put rust on a shelf and chosen golang because of job opportunities. Like in a common joke “there are no junior rust developers”. Rust is mostly used in cases when other tools are not sufficient to accomplish a task, that is, by experienced developers, not newbies like me.
Still looking for the Rust success stories that aren't just hype and talk.
After being a Python dev for many years, trying to wrap one's mind around the Rust syntax is like getting hit in the head with a shovel.
No pun intended, but if you look into Rust as a Python dev, you are looking into your car's engine as a car's owner - you will have no clue, what is going on there. As C is, what makes Python going (i.e. the interpreting engine of Python is build with), and Rust is a more demanding (but also more reliable and more powerful) version of C.
Now, I've been around in the programmer scene since the early 80s. My first programming language was BASIC, and when Pascal and C came around, my first stumble was "wait, what, no line numbers to GOTO or GOSUB?". It was a culture shock. Python and Javascript are the BASIC languages of the 21th century, the journey toward writing programs can only start there. If you can get your job done by writing Python scripts only, be happy and do not worry about not understanding Rust.
Yeah, I believe, Nim is a better alternative, especially for Python devs - you get very safe and fast language without the borrow checker restrains and a Python-esque syntax as a bonus.
@olafschluter706 The more accurate analogy is that you are looking at a niche product's engine, while every other engine in the world has a different design.
@@dolorsitametblue I'd take Julia over Nim, but that's because I dislike Python's syntax. I can prototype in Julia as quickly as in Python but end up with fast compiled code.
@@offensivearch fair. I wanted to try Julia, but it really put me off how bloated it is: it depends on a huge runtime, hello world is around 150mb! That almost makes it non-option if you want share executables with someone.
It's really hard to justify Julia's runtime size when in Nim, small utilities I write - are all 100-200kb, and can be statically linked (2-3 Mb exe), cross-compiled for linux/windows/macos in one command (with a little help of Zig compiler).
With 5+ years of experience in BE Web Dev with Java/Kotlin/Scala and currently 2 years with Rust, I would never go back. It's so addictive language. Everything has its place, and once you compile it, you can be sure it will work perfectly. So much so that having 3 micro services written in Rust, working for more than 1 year, none of them had any runtime error.
More or less direct comparison is with Ada
Yeah I remember when I programmed trading bots as a hobby in JS and the bots would crash randomly every 1 or 2 months.
And when I joined a new job, I noticed their JS microservices would crash due to running out of memory and the team's solution was to increase the server memory every time.
Those experiences got me in interested in learning Rust.
In Java and Typescript you don't Need to compile to know everything works.
@@OCTAGRAM the government developing ADA then (somewhat) abandoning it to go back to C/C++ (with restrictions) only to start releasing a bunch of guidance saying stop using C... what a mess.
Virgin Rust dev: Pleeease, I need you to compile my pwogwam 😭
Rust compiler: Noooooo !!!! You didn't respect the owner ship !!!!
Meanwhile:
Chad c++ dev: Trust me bro, this float is now a pointer to a function.
Chad C++ compiler: Yes, Master. _Segfault_
I like the C++ way, just give me complete control, and it will be my responsibility. At most I will allow it to warn me about it and then shut up.
@@Leonhart_93 The more experience you get, the more you will understand that you are not as skilled as you think you are.
@@Giga4ever The more experience you get, the more you get annoyed when a compiler says "you can't do things your way, you have to do it my way".
When I tried Rust I was always like "you don't get to decide, just shut up and let me do what I want". It was seriously annoying. Those that life Rust are into being told what to do at every step.
@@Leonhart_93 And when you get even more experienced you appreciate the compiler being your best friend and just trust that it's probably anyway a dumb thing you are trying to do.
Helps also a lot with any real world project where you have more than one developer.
@@artxiom It's the other way around, those that don't know what to do appreciate that. I have 11y of experience and my patience with annoying compilers only went down as time went on, especially these days some languages have take it upon themselves to even tell you how to write the code. A very fast way to make me drop the language, not like these days you need to use a specific one.
I've tried Rust briefly. I can program in assembly easier than I can in Rust, and get the job done faster by far. Second, I have yet to figure out how to handle data encapsulation in a way that makes sense. Third, the borrow checker drove me freaking nuts.
The biggest red flag is when you can do something faster in assembly than in a supposedly higher level abstractisation. The whole point of not doing assembly is that it's slower.
No rust takes time to learn because it makes choices of api for memory safety. It takes time to learn new things, and a borrow checker is a complex thing to wrap your head around. Usually lifetimes are needed when the borrow checker is upset, e.g. data requires other data to live, and thats where things get hairy. Once you've figured it out though its a pleasure to work with @Leonhart_93
I'm a beginner and I prefer rust more, i guess rust isn't for you 🤷♂️
@@Leonhart_93 Ehh, I just doubt this is true. I'm sure you can do simple things faster in assembly. I seriously doubt you can write anything of even moderate complexity (ie requiring dynamic size or numbers of allocations) easily in assembly compared to rust.
@@offensivearch But if it were true for the original poster as he claims, then Rust doesn't have a value proposition that stands for him.
I've programmed 15+ years in C++ and then moved away for JavaScript/TypeScript for the last 6+ years because of the amount of web development jobs out there compared to C++ (yes, job safety is an issue if you're not careful enough).
Now I'm slowly learning Rust (bought the Rust book) and I think Rust cannot be more complicated than C++ (which has become a monster language over the years).
Also, Rust has solved a big issue with memory safety which would perfectly place the language in the domain of mission-critical applications.
Also, the integrated package/build system makes development with Rust so much easier than with C++. You don't have to deal with make files (those are horror stories!), you don't have to figure out how each library must be linked in order to work). You have the whole build toolchain at your fingertips. You don't need a different build/toolchain under different platforms, your development experience is the same under Linux/Mac/Windows.
And with big corporations backing the language I think job opportunities will definitely grow in the very near future.
Rust is the new C++ for the next 10-15 years.
As rust continues growing, a lot of experienced devs see how stupid is rust community so it's not an argument
I was debating whether or not I should write my server in Rust or Elixir. Even though Rust has much better performance, Elixir has a ton of features that make concurrency much easier to build than Rust and its very stable. I'm also a lot more productive in Elixir than I am in Rust. I've settled on using Elixir for most of my server logic and implementing Rust for things like using database drivers, and anything else that requires high performance like training machine learning models. I'd rather deal with Rust when speed is my top priority. Id rather deal with other languages when productivity and language features take a higher priority. I would love to build everything in one language only but I've begrudgingly settled on "use the right tool for the job".
Elixir for most of your codebase and Rust for performance critical components is definitely the best option
Why even bring up Zig, when it didn't even hit version 1 yet?
Bun and tigerbeetle are written by zig, and Uber is using zig already. So, it's not wonder that people bring up zig
@@unknown-user001 they use it as a build system for c/++, no company will use a language that is not yet released.
@@unknown-user001 don't forget Ghostty (that originally should be in Go: Go's TTY)
Node.js wasn't 1.0 when the whole tech industry pivoted to it.
If a five-year-old can learn and program in golang, it is a strength rather than a weakness.
the problem with rust ecosystem is that only people who don’t know the language well or use it for big enough projects say it is a great language. Real experts hate it in my opinion. i don’t think it will replace C or C++ ever. Also it is nonesense to compare it with Golang or such languages, though it will also never replace Golang.
What's a big enough project and a real expert?
@@LibreGlider big enough to maintain with a team of engineers and real expert means someone with years of experience on the system level design.
@@LibreGlider A real expert is someone who can use pointers without a compiler taking them by the hand
dang one time i tried rust. the next morning i had a headache
I have been involved in computing since 1971. My first language was Algol 60, then Fortran, Algol 68, Cobol, Snobol, MIX, PDP-11 assembler. That was my first year at UK University. Since then there has been a new language sprung upon the poor programming masses by the purveyors of novelty.
After so much practice I can learn a new language, but now in my '70s I am getting rather fed up with the quest for novelty. Most programming is not from afresh, but modifying and adapting code that already exists, and if it is in an unfamiliar language it is often a matter of guessing, or cutting and pasting - techniques that meaning-in-white-space languages like make and Python conspire to make this difficult.
I want to spend my time programming, not learning to program.
I think the lack of jobs is a real issue. I have played with learning it a little bit. But my motivation is not very high, because it seems like the likelihood of getting a job, after significant effort, is not great. Doesn't seem like a great investment of time.
Those who seek a job as a "programmer in a language X" are either very junior, or simply delusional.
@@vitalyl1327 I may be delusional. Definitely not junior. 30+ years at this. I get satisfaction from writing very high performance and high quality code. I can't do that with just any random language. You sound like the kind of programmer that is much more concerned about the problem to be solved. I am concerned about it being solved well. FYI - I currently write code in FP focused Scala.
I'm liking it more because of its strict typing. I came from TypeScript and I'm fairly a newbie in programming as a whole. I don't know much about how its async operations work unlike in JavaScript though. What I don't like about it is that they use tokio, a library, for async.
@@DCameronMauch there is no such a thing as a general purpose language. If you're a "programmer in X language", you're limited by definition. If you're a generalist engineer, you will use whatever language is the best for this particular problem. Or you'll build a domain-specific language for this problem.
Just imagine saying that you're a rice cook, or a screwdriver engineer.
@@vitalyl1327 Rust seems like a general purpose language to me. I am sure I can solve like > 90% of the problems out there using it.
My biggest problem with Rust syntax is the ergonomics. I start to feel physical discomfort typing Rust far sooner than any other language I use. The double colon is probably the worst offender.
Do you use `use` statements enough?
You aren’t a C++ developer, I take it?
I swapped my ; with : a long time ago unrelated to Rust and it it made writing code much easier. Luckily Rust has fairly few semicolons if you don't mutate and use combinators when possible so this remapping is a good fit.
As a Rust & Zig developer, i think the example of the use-after-free is a bit... unfair.
It's not common to just clean up memory without using defer in any shape way for form.
You have the power to do so, but it more than likely is *always* an error and it *will* stand out as "fishy" code.
When rust is better it's serious, but when it's criticised it's "oh skill issue, whatever, your lang unsafe"
What's so hard about simply writing a linter or, you know, actually debugging your code. "If it compiles, it runs" is such a con phrase.
@@rusi6219 Show us a linter that can detect UAF. If you have to debug your code then it is already too late.
@@RustIsWinning debugging is where the fun is at. Also stop stalking me.
I have no previous experience with any "low level" programming language, but I have a bunch of people around me who do. One of them in particular sort of lives in his own professional bubble (mostly a branch of embedded, but where you also design the hardware from scratch), so he didn't even know rust existed, but he has the sort of foundation that makes choice of language "all but irrelevant" to the task... so I introduced him to Rust as an attempt of getting some useful tips. After some coersion, he even read The Book!
He isn't impressed, to say the least. He said that 80% of problems Rust solves with its ownership and lifetime models are a question of setting a couple of compiler flags nowadays, and the rest is mitigated by having a general idea of hardware processes you invoke when running an application.
I can't check that without spending like 40+ years in the industry like he did, so I just sort of present it like I received it. He showed me a bunch of stuff of his where he just implements ring buffers without even knowing beforehand what they will hold or any real way to check really or sets up a UDP without ANY abstraction just by raw-dogging some magical numbers that he just knows should be present on a struct... (I might be butchering terminology here, but you get the point, I hope)
He says he HAS to do it because "that's how ALL hardware works under the hood" and Rust doesn't seem to give you the power to. All of his code would be inherently "unsafe" in Rust...
I'm still giving it a shot, though. I'm not aiming for his particular domain and it feels like there's a bunch of bias going on, so I'd like to check things out before forming my own opinion.
He probably is failing to take advantage of what could be done at compile time to improve reliability and productivity. But real engineers are used to not having their hands held, without people dying. They distrust abstractions they have not traced to the roots. A convenient abstraction is an extra burden when you accept that responsibility. And they hate modern products made by non-engineers who can't be bothered.
@@sciptick Aren't compiler flags "compile time"? I'm confused...
Barring that, I think you've got a point. I did notice a strong through-line with him... about how "you should know how things work" and that "if you do - you won't need all this obscurantist fluff to make them work".
The more I think about it, the more I tend to agree. But I also acknowledge that most domains have their quirks some of which make knowing what's actually going on almost superfluous to the task at hand... :|
Not everything is a spaceship, a high-speed train torque control system, or a military communication encryption unit... some things are just non-critical software someone uses to draw funny pictures...
Yeah, I don't have the same experience as he does, but I came to the same conclusion. It doesn't seem like Rust is capable of resolving an actual existing problem without creating many others and multiple roadblocks for you.
@@Leonhart_93 My follow-up after a bunch of fooling around and finishing a test project is "It depends", but I think I'm starting to get where he's coming from.
@@arcuscerebellumus8797: "It depends" is probably the right stance. After the few times I've poked at Rust, my opinion was that it should be considered for things like avionics, and Linux, and maybe nuclear power plants, but I also started poking at writing my own language because I just couldn't agree that the language was actually good. It almost seems bad in a less severe form of how C++ is bad... or maybe not even less bad, but instead slightly differently bad. It's like the designers thought of a few nice _pieces,_ but didn't consider the larger language surrounding them.
And for the life of me, I have no idea why they haven't made compilation a two-stage process so that precompiled libraries and object files can exist. It should be fully possible to output borrow-checking and similar info so that language guarantees can be completed at link time.
issues with rust that i find from c++ background are absence of variadic template, private inheritance as composition, overuse of macros (which are hard to debug). Its best things are sane defaults, cargo and traits
Curious what you mean by "private inheritance as composition" as an issue? Also, yeah, lack of variadic generics is a nightmare atm (have to do annoying macro stuff). Another problem with Rust atm is that constructors return the value. Compare this to C++ which constructs using a pointer to the class. This makes in-place construction (almost) impossible in Rust.
@@vitulus_ C++ frequently uses a composition pattern like, struct person {string name;}; struct student : private person { grade gpa; }; this is not a polymorphism, but it allows easy auto implementation of traits, serialisation, CRTP etc possible.
Macros are pretty much the only really good thing in Rust.
@@vitalyl1327: Not a fan of Rust macros. The ability to add arbitrary syntax is something that languages should usually avoid, not support.
@@absalomdraconis if you think so, you do not understand programming at all. Meta-languages are infinitely (literally, no exaggerations here) more powerful than the fixed languages.
I don't hate Rust but it baffles me why language with such a complicated syntax is so popular.
it's nothing about the language - it's about the programmer base. Rediculous, problematic and socially inept (even for engineering standards)
It is for programmers that want that low level control. The "complicated syntax" is just more knobs to adjust, to turn runtime into compile time errors.
Maybe you can compare c++ with rust.
In term of compiling as shared object file rather than statically
compile all functions into one binary file.
I’ve spent a year learning Rust for a couple of hours a day. I’m not sure that it difficult to learn. It certainly is if you get into the weirder bits of Rust but for a lot of coding it seems comparably difficult to C# or Java and easier the C++.
Missed my top 2: (1) Rust does not have safe defaults. For example, panics don't have to be declared, and all the built-in integer types can overflow. Memory safety without GC is excellent, but expected behavior can break without warning in other insecure ways. (2) Glacial compilation speed.
Very good points. Another bugbear is that global_asm is arbitrarily not regarded as unsafe, just because the unsafe keyword has no meaning at global level.
I don't think Rust is overly complicated. Sure, it is more complicated than Python. Let me explain.
I am an embedded developer, and my employer isn't ready for Rust yet, so we do things the classic way in C and C++. But since Rust has the potential to be a serious competitor in that segment, I am learning the language now.
Comparing to other languages I have looked into, Rust is certainly different, but I wouldn't call it a lot more complicated than others. Yes, getting "something" done in Javascript or PHP is easier, but getting it right and safe certainly not. And then there are languages where getting anything done is hard, like Perl or all those purely functional languages where I wouldn't even know why anyone would want to use them.
this x1000
If Nim had a little hype around it, it would steal Rust's shine away.
true and real
You wish.
Is Nim implementing 'Ownership and Borrowing' constructs? I know D is implementing it. I do like both Nim and D.
@@GaryChike not a borrow checker, but look at the move semantics in the docs (=sink, =copy, =WasMoved) which accomplish similar things, but a borrow checker with their memory management model would be redundant
@@sp.n7401 Excellent to hear!
I don't hate. Programming Languages are tools, not our girlfriends. I simply don't use rust often because other programming languages have more tools and libraries that do a good job. I don't have time, or efforts to spare to reinvent the wheel, I just want to get things done.
Of course you would say this, you have rust in your channel name and therefore must be an official part of the rust foundation because there's no way anyone else can have rust in their name, ownership of the word rust was moved so you get a compile error if you try to use the word rust in a sentence now.
You mean he has &rust in his name
I tried it. The vast array of files and directories formed to compile a hello world program was frankly stupid. What's wrong with a single file compiled by a program to a single executable file? Also the super slow compile time. It took minutes to compile it. The syntax doesn't scare me, but the experience of programming with the rust compiler is not good.
Vast array of files and directories? It's literally just `Cargo.toml` (Rust's equivalent to `Makefile`), and a `src` directory containing a `main.rs` containing your `main()`. Sure, it also initializes a Git repository for you by default, but you can opt out of that with `--vcs none`.
Maybe just use rustc is you just want to compile a single file? You are doing the equivalent of creating an entire CMake project, with a src dir, setting up vspkg, etc and then whine that is is not the same as just calling gcc.
@@Giga4ever All the dependencies you're likely to want (especially with Rust's non-batteries-included standard library) assume use of Cargo. That's why rust-script exists and there's experimental RFC 3424 to explore the design space for supporting something similar directly. Invoking `rustc` directly is meant for implementing Rust support in build systems like Bazel. It's what Git calls a plumbing command, as opposed to a porcelain command.
@@Giga4everThat didn't work when I tried it. It was a long time ago, so things may have got better. I don't have lots of free time to keep plugging at it until it gets better. Zig was nice, easy and quick right out of the box and so I was able to be productive with it in a few days of practice and getting fluency in the language. However 35 years of writing C and almost as much writing python, I don't really need to be nannied with new languages. I can get my work done.
@@davidjohnston4240 skill issues like literally.
As a full time C++ developer, I want to migrate to Rust. And unfortunately in our country there are no much opportunities to do that shift.
I think the main issue with Rust in the domain C++ is applied is its poor C++ interoperability. If you are working in a C++ eco-system, then you want something that can seamlessly use what is already there. And C++ struggles really hard to find a successor language and - since the recent Cybersecurity Report to the US government discouraging the use of C and C++ - is in dire need to have one. AFAIK the first new programming language with C++ interoperability in production quality is Swift (and only since recently, C++ interoperability has been introduced with Swift 5.9).
Don't do it, you will be shooting yourself in the foot when Rust fails to get the right adoption. Just become even better at C++, learn some advanced applications for it, like drivers for low level hardware.
@@Leonhart_93 In my experience if we're talking about drivers it's C++11 tops in production and more often C++03 or plain old C.
Newer C++ standards adoption is also pretty low. I personally faced C++17 (C++20 at best for some open source development like envoy proxy).
And even with all goods of C++17 it's the gun pointed to your leg in the first place and programming language only after.
@@LiveseyMD Slow adoption of newer features is indeed an issue for mature projects, but due to the nature of the language it's not that limiting. Hell, people still build and maintain performant systems using C, which barely changed at all over the years.
But I think that is exactly why C/C++ will always find purchase, while Rust does far far too many abstractions and forces too many liming factors to be universally useful. For example game dev, some required things are just unwieldy in Rust.
My main reason for hating rust is honestly its community. The language itself is mediocre. It has some nice ideas, but is nothing beyond something you play around for an afternoon with. The community, however, hypes it up to be the "next big thing", which it is absolutely not cut out to be. It is needlessly complicated, and it feels like showing a broken sword through your chest fighting the borrow checker just because rust is cannot for the life of me statically analyze at all. Rustaceans might chop this up to skill-issue, but that's a complete joke. You cannot claim skill-issue when rust's core goal (guaranteeing memory safety) is 100% a skill-issue, and it doesn't even deliver on that (rust leaks memory and considers that "memory safe"). The false promises don't stop there. As a big fan of functional languages (Haskell, Roc, OCaml, etc.), I was promised a functional experience with the performance of C. That is miles from what rust is. It is at most a C++ clone that masquerades as a functional language. Most parts of functional programming (brevity, declarativeness, affinity for recursion, ability to reason about code abstractly, statelessness, "turtles all the way down", etc.) almost completely get thrown out the window. Most of them, while possible, completely ruin your performance, because rustc does barely any static analysis and code transformations beyond the borrow checker and expects LLVM to do the heavy lifting.
Considering how mediocre and sold and false promises rust is, I find it a shame, that rust is forced into the position of "the next big language", while there are languages that achieve the same while being actually good.
Firstly, Swift must be named here. It is exactly as memory safe as rust, but about a gazillion times nicer to work with while not sacrificing performance.
Secondly, Dlang exists. I don't quite know why Dlang is so slept on. It's older than both swift and rust, and does basically everything that is nice about rust. It is starting to show its age though...
The fact that this video did not really address any real criticism of rust beyond either "no that's not a problem, you're wrong" or "that's just a skill-issue" is a prime example of why I dislike the rust community,
Worst part about writing rust is you constantly have to interact with people that have bright unnatural hair colors and furry github profile pictures.
Finally someone says what I was thinking lmao. The community for Rust is garbage.
Why is this like, bad?
@@edwin5145 it's "bad" because @porkfatrules is sch1zophrenically engaged in the culture wars and thus is constantly looking for a weaker scapegoat to blame his problems on
@@edwin5145 Not bad. Totally cool if you're into it. But I feel too humiliated when I'm getting talk down to by someone's fursona for not fully understanding the intricacies of the borrow checker.
@@porkfatrules yeah but that's shitty behaviour in general for sure. Sorry you experience that.
"Why rust is bad: There is at least a dozen of reasons,
but let's iterate the same bs from the main page of rustlang for hundredth time!"
Jesus save me from this madness
For the start, I just think you are taking generic haters so much seriously, and this is dangerous.
But good video nonetheless
Hater
"hate" because this language is pushed and promoited like u must learn it... or u have no job in the future or smt..
and so many junior or self-learners think they can learn Rust... meanwhile they should actually go to universdity for 4 years and learn Computer Science ,
Learning rust when you dont understand how CPU works, how to read and write binary and how lower level stuff works and computers and OS in general... is pretty dumb to me.
What the hell arte you doing with ur baasic rust knowledge? No company would hire you, Rust is not used for trivial things like web, crud api
one problem with rust and learning is also t hey want to sound different for the sake of being different, they rename concepts
they call data structures compound types? why?
languagesa should stop renaming things, it just confuses people
Rust Foundation drama itself showed what thy are... Rust will have same fate as Haskell... obscurity because of elitism and snobism
"my program is bettter than yours,becvause im using rtust" ,
if rust would be so good as they claim, every single company would be using it
im neutral about rust, it looks nice @ hello world level...
but when look some larger codebases, its very terse and unreadable
I'd rather use Crystal , if it would be more mature language
"most loved language" is a myth , taking stackoverflow survey seriously is illogical
it's very small demographic, mostly americans and old guard... and certain type of toxic people
dont people know how toxic stackoverflow is?
all the countries in the world actually have different languages wich are most used and loved
for example in Estonia python is almost not used at all , but Kotlin, Php, JS , C# gets heavy use. Now some Elixir as well and Go
Literally have seen ZERO Rust jobs in this country.
Basicly all the large companies use Kotlin/Elixir or C,C++
@@JorgetePanete and that works just fine until you have to define 1000 trait bounds to T just to get it working the way you want. Imagine you have 100 different types that need those trait bounds and you have a boilerplate nightmare
@@Microphunktv-jb3kj Sir, this is Wendy's.
As someone who's listened to plenty of Javascript hatred over time, I'm less interested in RUclips and Reddit comments about a language and much more about what the language can do, and Rust feels very powerful from my limited use of it.
Yup, yet another self-absorbed JS frameworker defending rust. Just what we need.
@@rusi6219 well bless your heart 😂
Using an ai tool with rust makes picking up the language a lot easier.
The biggest issues i have found is with code samples and tutorials that haven't been updated to reflect changes to the crate.
Tell me you never read documentation without telling me you never read documentation
@@catto-from-heaven That's not nice. People have their own methods of helping them learn. No reason to believe they don't read documentation because of that.
@@vitulus_ "The biggest issues i have found is with code samples and tutorials that haven't been updated to reflect changes to the crate." That leaves it clear
Ofc you have to study prop computer science, that goes for C also, a lot of people doesn't get how to use pointers correctly, let alone understand rust. I've worked with people who attended the "learn typescript in 3 months course" no previous or after knowledge of programming, the nightmares I have reading their code!
I'll tell you the only reason I ever feel "hate" towards Rust, and it's people propagandizing it and acting so sanctimonious about how immature and inferior every other languages supposedly is.
It makes everything hard and not enough support.
@@RustIsWinning Really ain't though, I ain't gonna deny rust is a good language, but the juice-exuding orgasmic glazing some people give it is just cringeworthy. Facts are fine, but the picture painted by the mention of the likes of "rich algebraic type system" and the illusory promise of never writing another bug again are but a pipe dream. I just want everyone to see reality and if possible, ease the propaganda. Thanks
I really don't agree with those weird rust fanboys, I just thought rust was a breath of fresh air to finally have some safety after all those years coding in C++, I believe every language has an use one way or the other. I am sorry if some immature idiots made you feel that way
I respect Rust, but I have truly despised the time I've spent (not wasted, I will grant) coding in it. It is the only language that made me feel like an idiot.
Oh and let us nto forget the explicit political biases of the Rust Foundation (virtue signaling anti-war messages on patch-notes was a memorable one for me), alienating everyone who isnt a progressive.
i can understand the compiler pointing out mistakes to be frustrating, but the complaint that rust is pro human rights is just nuts. those who are against human rights just simply don't have a place to exist in the future we are heading towards and it's time to stop catering towards those who are vehemently against human rights
1:22 This is really a non issue with a TypeScript extension for JS files, but it should be part of the language and accessible in V8.
I'm a C developer. I can't say I hate Rust but I tried it for one project and definitely it's far from being a productive language, at least for my standard. I can't care less about the borrow checker or the standard library. I have other ways of avoiding/diagnosing/fixing those rare memory leaks. I can just do much more with much less and in my case Rust just kept getting in the way. Like C++.To each their own. For sure, the drama around it makes it even less appealing. I like stability.
I dont hate rust.
But i suck at it, I can write it, i can read it.
But everytime i write rust, its not clean code and its always really ugly or hard to read or ugly to handle errors or map errors (even with anyhow/thiserror)
thats just like how rust is...
nothing to love there, unreadable
i like Crystal , C-native bindings
if the language would be more mature, i wouldnt be afgraiud to use it ; ) in production
Its basicly what typescript is to JS , Crystal syntax is almost identical to Ruby but has c speeds and statically typed
@@Microphunktv-jb3kj I came from a C++ world and rust is literally a godsent in that direction.
or rather a better replacement for shit that needs to be secure / hard to crash.
So, in that regard i still love rust.
Never tried crystal, did try ruby; didn't like it.
But tried Elixir and it was really fun to work with
Read more Rust code. Read lots of other people's code. You can also request a code review on r/rust.
You're not writing unreadable code, that's just rust code
Just drop rust. Drop the "clean code" nonsense too, while you're at it.
A lot of Rust programmers are likely on the younger end. When you're over 60 and being asked to code in yet another language, I guarantee you'll behave as older programmers do now.
"you can't even write a linked list without having a mental breakdown"
pub struct Node {
value: T,
next: Option,
}
Great now make it doubly linked
@@salvoilmios Double linked list has runtime invariants, that are not easily representable with the Rust's type system, that's why it feels so verbose.
But in C you just completely ignore the invariants and pretend that the program you just have written actually works.
@@salvoilmios
Just use a couple Rc's and you're done.
In all seriousness, these things are only difficult in Rust because Rust developers try to make them better than they are in other programming languages. It doesn't take much to get JavaScript-level performance using Rc's or C++ levels of safety using raw pointers. The issue only starts when you want to surpass that.
No Box for the value?
@@bryandata6658 No need to box T here, Node completely owns it and will be allocated in heap, since the previous Node boxes it.
Instead of studying rust, I'll dive into computer architecture and organization, operating system principles, then C/C++. In my opinion, rust is just a "tech bubble"
Agree
It'll stick around, but I don't think it'll be the final C or C++ killer. It'll probably always be in second or third place for low-level systems languages.
@@absalomdraconis I think it will do fine as a niche language with a community that hallucinates with not being a minority.
@@TheDragShot Rust will overtake C and C++ in popularity eventually. No other way around that. Most big corpos are pushing it also, for good reason. They are tired of mistakes costing them billions that can be caught by simply using a better language.
@@hagaiakif there's a language that'll overtake C it'll be Zig. You cannot get rid of a language that's so widely depended on with a radically different one that's so majorly incompatible. You take over by integrating and migrating the existing base to your team.
Sorry, but I'm not trans..
Just saying, go has been a much better experience for me but I’m trying to make a game. Rust and game dev don’t get along nearly as well as people claim for LEARNING game dev. Maybe it’s great if you already know everything you want to try to do
At 7:40, you mention about skill issue. IMHO, I think it's not the skill issue, It's more of -- Wasting more time learning a programming language than giving more time to write big software's.
If a programming language itself is giving more headache that actually focusing on writing software, there seems to be an issue with the language and needs to update itself. I'm not a Go dev btw. I write programs in C++ and Python.
You nailed it. This is the reason why it will never become as widespread as C++. The language should just allow you to solve a problem, instead of becoming a problem to solve.
That's why I replace every looping method with a for loop (except for maybe the spread operator).
It becomes especially good when you learn that a for loop can have multiple "header" declared variables, and more post-check actions (usually people just write i++).
I've been seeing a number of job opportunities for Rust. I haven't seen any for Zig or Go. But I might be looking for the jobs that wouldn't favor Zig or Go.
Go was not made for 5-year-olds. But Scratch, on the other hand, was.
I did a brief stint writing Go. I hated it. Too overly simplistic and unexpressive language for my taste. Things I can write in a single line of Scala takes like 50 in Go. Anyways, just having that on my resume, I get contacted all the time about Go jobs.
Zig isn't even at 1.0 so there aren't going to be serious jobs for a long time. It is a fun language though.
I think you will see jobs for Go in web development.
@@DCameronMauchthat's my big problem with go, for something that sells itself as easy to understand. It's really frustrating having to read a novel to figure out one function. Yes, each of the lines are trivial, but there are a billion lines that in most other modern languages wouldn't need to be there.
@@ngin6917 go syntax can be verbose. however you can do stuff with go that you just can't do with any other major language. the concurency primitives and support in the runtime are revolutionary.
Honestly the reason I dislike Rust is simply because I hate the holier than thou attitude that radiates off the language and everything related to it. the idea that "the compiler knows best" when you need to practically be a language maintainer to implement CS 101 data structures just convinces me that the entire language is insufferable and will be utter torture to write.
Yeah that's stupid. When I already checked if the object is ok before use it, the last thing I want from the compiler is for it to tell me that I can do something with that object because "it's unsafe".
@@Leonhart_93 You just don't understand the basics of Rust. At least the commenter raised a valid point while you are just arrogantly repeating the same ignorant take under every comment.
@@terryriley6410 No, I understand perfectly how annoying it is in demanding things to do only as the Rust compiler wants it and that way only.
@@Leonhart_93 Every single compiler and language has rules about how and what you can express. Rust sets out to disallow things that often lead to errors. You don't like it because you are arrogant and you didn't took the time to understand how rust works.
@@terryriley6410 The difference is that most compilers, especially the low level ones, only have the rules that are guaranteed logic errors, like missing memory location.
Rust just has way too many restrictions even for cases where it won't necessarily happen. In the end it's a new paradigm created by a few people, I have no expectations from it.
Sometimes people can not acknowledge that something newer is better when they have worked with something older for longer.
More often I've witnessed the opposite, with people thinking that newer is better than older (e.g. the newest Electron-based framework is surely better than the older smaller faster thing...). People accept new things just fine when those new things fix the problems they had with the old things, rather than just solve old problems they didn't have to begin with while introducing new problems they didn't use to have.
If 20years experience with c++ equals 10years with rust and you have the c++ experience, then you might be 40-50 years old and retire before rust even squares
7:16 - C++ also has a lot of string and string like types.
The syntax is hideous. It looks like a corrupted C file.
Compare map function with go, not js. Go provides type safety and is statically typed language, yet the map realization would be 100% easier to write or understand what was written
When evangelists do not understand why they are not the biggest...
The fact that there are people complaining about the amount of compile time errors they encounter in Rust baffles me. Oh no, the language has saved me from dealing with all of those issues in production when its a gazillion times harder and more expensive to debug, has caused a lot of damage to my users and made headlines as the latest security breach. Amazing.
The memory safety argument is only partially valid. Memory leaks can still occur in Rust. It’s safer but not fail safe. You still need to know what you’re doing. Which brings me to the biggest problem I have with rust. If you know what you’re doing, chances are that you also know how to properly code with memory safety in mind. So what problem is Rust trying to solve? And more importantly: at what expense? The loops and hoops you have to go through to satisfy the compiler, is just a big no no for me. Rust certainly has some interesting concepts I wish were implemented in other languages as well. But for me writing code fast is enjoyable. Battling a compiler is not.
It's the little things. What people often fail to show is that it saves you from making very subtle mistakes, because those are difficult to condense into a single slide. Memory leaks are not unsafe. Unless you run out of memory, they're just annoying. Writing/Reading garbage from memory because you accidentally referenced something and then the buffer got reallocated by some code in a completely different part of the codebase, is. You can "properly manage memory" all you want, it's bound to happen at some point in very large projects. Microsoft, Google and others all have sensible and strict memory management guidelines, those kinds of problems still arise.
As for battling the compiler, I've found that after getting used to how Rust expects things, **most of the time** I don't really have to do that anymore. Writing Rust in general is pretty straightforward once you got used to it. But yeah, when you start to mess with lifetimes, especially multiple ones, it does become really frustrating sometimes. But at the end of the day is either that or risking to introduce a very subtle memory vulnerability that will be exploited further down the line.
I do agree that fast prototyping isn't its strong suit though.
@@maximumoverflow901 Those "little things" you speak of aren't reason enough to break your back trying to implement basic features in a very obscure language.
@@Leonhart_93That's an exageration. Unless you want to do some really performant zero-copy stuff, at which point lifetimes become important and sometimes hard to deal with, pretty much everything you could think of is just as trivial as in C++, or better. In terms of ergonomics and general use, Rust beats C++ hands down. I would never consider writing the equivalent of a quick Python script in C++, but I find myself just defaulting to Rust in times like that. Does it solve all my problems? Of course not, but the whole borrow checker and learning curve thing is extremely overblown. Like it or not, Rust is here to stay.
...with that said, the community is exhausting.
@@maximumoverflow901 No really, I tried to implement some relatively easy structures like a global multi dimensional hashmap stored in a singleton that stores and dispatches functions.
I always implemented this structure in PHP, JS, even C++, and all do it fast, seamless and without complaining or extra boilerplate code. Just some assignments and calls.
No so in Rust, the experience was beyond infuriating. Had to fight the borrow checker and lifetimes at every step. If me who has 10y of experience feels like that, then a newbie has no chance.
@@Leonhart_93That sounds fairly easily achievable in Rust as well...
It's a different paradigm. If you go in with the expectation of doing things *exactly* as you do with those other languages, then yes, you'll have a bad time, but oftentimes just a slight tweak to the way you approach the problem makes most issues go away. Once that clicks, honestly it's not as daunting.
Now you got me curious though... Do you have a concrete example of what you wanted to do?
Honestly it's not about the language itself, but more about the community that developed fanaticism (at least it used to be like that maybe it changed)
Coming from a Java background I find the syntax reasonable, except for lifetimes of course
I guess most people who have problems with Rust's syntax don't have a proper formal background in Computer Science or Computer Engineering and just code in languages like JS or Python
@@riccardosagramoni8016 No, I have all of that, I just hate that it tells me what to do even when I took all the right precautions to make sure there is no way I created a memory issue.
@@Leonhart_93 Are you really sure about "taking all the right precautions" in 30, 50, 100... thousands of lines project? I don't think so. We have computers to think about "taking right precautions". I feel just safer when I know that I possibly can't create a memory unsafe code. We are people, and we make these kinds of mistakes. And I don't want for sure my code to fuck up in production because I was too confident in my rightness.
@@rastr__9042 Safe, safe, safe. I never felt unsafe, if I made a mistake then it was my fault and then I strived to make it better. That's how people wrote code for like 80y now and it doesn't seem like it slowed down our progress in any way.
But forced restrictions at every step, even when they are not required, is not the way to go.