Why I Hate Rust (the programming language)
Вставка
- Опубліковано 8 січ 2023
- Code of conduct blog post: swindlesmccoop.xyz/blog/condu...
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Website: swindlesmccoop.xyz
Contact: swindlesmccoop.xyz/contact/
GitHub: github.com/swindlesmccoop
Odysee: odysee.com/@SwindlesMcCoop:1 - Наука та технологія
weeb cringe
Even if the video is bad you shouldn't fill the comment section with insults, actual criticism could be here
@toast i want people to talk about the mistakes in the video, not to yell cringe and vanish
@@toast2325 yeah I agree but actual arguments are kinda nice to see sometimes
Not an argument
you got the pin of shame
I used to have a similar stance to yours, thinking that the memory safety guards rust provides are not necessary and are for people that don't understand the true nature of computers and how to harness their power. However, I've come to realize that we are only human. NO MATTER WHAT you do to try to prevent memory management bugs from creeping into your codebase, they will always be lurking in the shadows when using languages like C and C++. And sometimes, thats okay. But, when you take a step back and look the broader spectrum, it's very evident that the unsafety of C and C++ has cost the industry unimaginable amounts. Rust is built with rigor. Where C and C++ can let small things slip straight through your fingers, rust is there to catch them. Don't quote me on this, but I read somewhere that Microsoft has openly stated that memory unsafety can be held accountable for over 70 percent of all security issues across all of their platforms. Just imagine a world with 70 percent less security bugs.
Maybe so but Microsoft probably just looking for a scape goat. Bad or lazy programmers will find a way to mess up any code base. The only good thing is that rust makes it harder for bad devs to screw things up. I am a fan of C and C++ but I am not going to fanboy any of them. These languanges are tools.
@@computernerd8157 agree 100%, nice to hear someone that knows what they are talking about and not just a fanboy
@@computernerd8157
"The only good thing is that rust makes it harder for bad devs to screw things up."
And sadly, I saw a lot of those same devs just defaulting to unsafe without reading properly about the invariants they need to uphold (they were breaking the contract). Even OpenAI had such code, which I reported, and the authors response was akin to "I know this is bad and not secure as you've clearly shown me and linked to the materials, but it should be ok I think?"
Seems they will just do it anyways *shrugs. But at least we have the "unsafe" keyword to make it easier to find the potential source of the problem I guess..
@@aqua3418 Well I guess you cant fix stupid then. I don't know what to say except for its not the language its the programmer.
-Just learn to code PROPERLY in C with security and simplicity in mind.
-Learn to use GDB properly.
-Learn to use Valgrind and Helgrind.
If you do these, your C program will be safe enough.
"I guess, maybe, like a toolchain?"
Yep.
You really sounds clueless when talking about this stuff. Cargo is a frontend to the rust developer experience. It's easily the best one I've used across dozens of languages. It mostly just works. It's not a compiler, rustc is a compiler, but cargo acts as a frontend to that. It also acts as a frontend to linkers and is the package manager. When you said, "it's not doing any of them very well," I'm super curious what other languages you're working in that you find excel in this space. Maybe python does a decent job here, bundler is OK, composer is OK, everything in C++ is a nightmare, but Cargo just works.
1. Cargo is a toolkit. It handles 'crates' that are either stand-alone programs or libraries for other programs. You can use it to initialiaze projects, add dependensies and use the 'Cargo.toml' files to compile your project. (much like 'make' files but much simpler. holy **** make files are a mess of a design.)
You 'can' use it to install software too but not sure if that is the way people actually use it. You can also extend the cargo toolkit yourself.
What is the compiler for rust then? it's 'rustc'. You say "it shouldn't be so complicated that I have no idea what it is" when you didn't even read the manual. RFM
2. While juvenile argument of level of intelligence is bit dull. How memory is used is very much still a thing with rust. Difference between C/C++ and rust memory management that with C you are allowed to do dumb things with memory. In rust you use memory with scopes or annotate it with lifetimes. Complaining rust programmers don't have to allocate memory is like complaining you don't say grace before eating... silly or ignorant AF
3. 'cargo install' has settings and environment variables for your preferred install location.
4. Filesize! If filesize is important for your use case, rust can optimize a lot. You can optimize rust release builds for filesize, performance speed etc.. just like most optimizations, it comes with trade offs. pick your poison.
5. Yes. crates.io index is big. but if you don't want to use it, you can also configure your cargo toolkit to go offline mode. or use alternative sources for your packages like git or direct URLs etc.
Also since we are talking about 'developer' usecases... most of the libraries you download are things that other developers use to build their macros or language features that they found useful but are not part of standard rust yet. You don't need to re-download or build everything if you already have it downloaded or built on your development environment. It's not like you download 'boost library' every time you want to compile new project...
6. people who are stuck in their C land or does hardware / baremetal programming are using unsafe. latter for a good reason. 'unsafe' just allows you to do few things that if you don't know what you are doing might cause undefined behaviour. Usually this never becomes an issue if you are not trying to imitate the conventions you might have stuck with you when learning the C language. "So many people end up wrapping their code in the 'unsafe' function", no they don't. 'unsafe' doesn't turn off borrow checker, new rust developers have issues with borrow checkers, not the unsafe/safe thing. Only people with 'unsafe' issues are former C programmers who can be bit silly.
7. Easier syntax does not equal higher level language. Assembly, or better yet, literal machine instructions are extremely simple syntax. Higher level language is number of abstraction in between it and machine instructions. To be honest, C/C++ and Rust have pretty much the same syntax with different language features. I guess the biggest difference is that rust has more short hands when compiler can infer things like types from your already existing code. rust-analyser is great tool if you want to have insight into what compile issues your code currently has in almost real time and what types it can infer, and what requires you to be more specific. When compiler does it's magic it expands the code into the inferred types and that syntax can be bit overwhelmingly specific.
8. "rust programs end up using more memory" again, optimization option. Defaults to cpu performance. Modern hardware has extensively more block storage and memory than we use. If we can trade that for faster execution then why not? If your use case needs to optimize for other things, that is your choice to compile it with those options and optimizations.
9. There are many reasons to re-write program. 1-to-1 rewrites for benchmarking compiler. feature-to-feature rewrites for language feature benchmarks. Novelty...
Actually important reasons for rewriting with rust though? We have now about 50 years of technical debt running on our unix based servers. new attack vectors found every other day. most come from exploiting software memory access to write things in memory locations the running software was not supposed to access to and doing things like arbitrary code execution or privilege escalation. within last few years we have had to patch even the simplest standard programs because someone found new exploit.
10. "C is harder", eating soup with chopsticks is hard. I still don't think higher of people who do it.
I've learned many languages. JavaScript, Lua, Python, PHP, C, C++, C#, Java, Go.
JavaScript is just hotpot of things done 'just because'. Lua is weird AF because every stack that implements it does things slightly differently. Python is 'ok' but relies on so many things not-python to do things that it's more of a tool to experiment or to create proof of concepts with. C/C++, when working with only standard library, they are fine. When messing with application solutions that require bunch of dependencies, it can become pain in the ass. C#, only really used it with Unity but it was pretty cool, in it's isolated environment, .ASP/.NET stuff is just weird Microsoft software chain bullshit. Java, is just C# but with Oracle. Go is pretty cool. Their libraries are always out of date that you have to fix yourself.
Rust, while I am still not confident with it, has been most fun to learn. I've never seen compiler tell me in almost plain English what I am doing wrong or suggest how to fix it.
In conclusion, I think you made this video mostly just to bait people to interact with the video. Good hustle. But I don't think you can give honest opinion on language you have not given actual attempt with. Yes! You learned C, congratz! Someone invented new language that *might* be better for things C was originally used for? We call it progress. Rust keeps much of C/C++'s syntax because it worked and is familiar. The things that hindered the language was discarded. I am much happier with Rust, writing it is fun. Knowing my programs wont have memory access errors or page corruptions (**** you PostgreSQL) makes me very happy.
If you haven't yet, spare a day to go through the rust book. it's fairly short but the final exercise is to build simple multithreaded http server using standard library. You learn every concept you need to understand for the task in the book. doc.rust-lang.org/book/
After I got done with the exercise, when I first started to learn rust, I had fun expanding on it with a config file reading and serving files based on extension using different pre-processors.
This is the kind of comment I'm talking about. Thank you for leaving a response that goes in-depth about the topic and is moderately sophisticated without personal attacks. I will respond to each of your points.
1. Makefiles are great, people just don't know how to use them properly/minimaly and they become a mess. Also, if I am programming in C, I install a compiler, and the thing that I installed is the compiler. I do not want to install a toolkit, I simply want to compile. Except I *need* the toolkit because otherwise I can't pull the dependencies, since it likes to use its own package manager instead of having dependencies through the OS/distribution package manager.
2. I'll admit that saying Rust programmers are less intelligent was a little bit of a bait, I still maintain the position, I just tried to word it in an inflammatory way. The problem with these memory safe languages is that they *boast* about not needing to really manage memory much, if it all, but then have horrible garbage collectors.
3. It wasn't really included how to actually set it up in the man page. I attempted to make it send the compiled binaries to /usr/local/bin/ but it complained about permissions, and when I attempted to run it using doas, more things ended up breaking.
4. Even with release level optimizations, the binaries of Rust rewrites of C programs are still multiple times larger than the original C binaries.
5. How else am I supposed to get dependencies if not from the crates.io index? Whether or not I need to redownload libraries doesn't seem to matter, because that is what it ends up doing. Maybe something was broken with the cache? It grabbed every single dependency over again on every compile.
6. This is probably a hard metric to measure, however I have seen many projects where "unsafe()" is riddled all over the place.
7. I wanted to make the point that the more abstractions there are, the higher level the language, but I felt as though most viewers wouldn't understand what I was trying to say, so I kind of just went with a generalized statement.
8. It's less about how much and more about the fact that no matter what you do, it's using more. Sure, you can lessen the memory impact, but it's still going to be more in Rust than C.
9. Rust has less vulnerabilities because it has been in use for a shorter amount of time, as well as less researched and documented. Meanwhile C has been around for over 4 decades now, of course there are going to be plenty of exploits. It comes with the nature of using things that are old.
10. Your analogy of eating soup with chopsticks doesn't really apply here because it's practically impossible. You're not giving C enough credit. I think a more apt comparison would be C is like lifting up the bowl and drinking the soup in one go, while Rust is just using a spoon. One is obviously harder but is fastaer, and one is much more convenient albeit slower.
@@swindlesmccoop First point is moot. You can just download rust dependencies and link with the rustc compiler. Makefiles... Which of the several different types of make actively used are you talking about? GMake? CMake? Make? Oh, don't worry, they are all slightly incompatible.
Second point is also stupid. I started in C and I sucked at it, tbf. After learning rust I'm pretty comfortable in C despite not programming on it, because guess what, i understand the memory models and i developed habits that reduce memory issues. And to make YOU look stupid, rust doesn't have a garbage collector. Come on, you could AT LEAST not make yourself look like an idiot... It's all statically determined by the borrow checker.
@@swindlesmccoop If it wasn't in the man page, how about you go check out other resources? If you had, you'd know that rust actually has it's whole standard Library available with one single command.
Also, what's the deal with putting binaries on the root folder when absolutely unnecessary? If things are breaking it's most likely because you don't have the standard Library installed for the root user.
Rust binaries are usually larger because they aren't usually stripped. But while bigger than C, they aren't actually all that huge. They just start big, because yes, debug symbols. Also, might I add, rust programs have quite a lot more of static strings because, you know, the user is actually important and proper error messages are fundamental...
Dependencies? Again? Git links to the project. Also, RTFM. It's the most widespread C advice and you won't do it for rust, seems a bit dishonest dude :/.
I'd like you to show that unsafe use... And i mean, in projects that don't depend on interacting with a different language. Like, idk, if you came with an OpenGL wrapper to make your argument that would be very silly.
Rust can be very abstracted, yes, but those abstractions are eliminated for the most part. We all know LLVM is slightly slower than the GCC backend, and even so rust approaches the speed of GCC C. It may be more comfy for the programmer but it doesn't discard speed.
@@swindlesmccoop Rust does use more memory, yes. Ever heard of caching, though? That might be why that is. And yes, C over all has more fine control over memory and can abuse some stuff that isn't really all that safe but not harmful (usually) that rust tries to avoid, so yeah, memory usage is slightly higher with Rust.
Rust itself is not the thing that should be looked at for vulnerabilities.
Look at web browsers and the Android operating system. Most vulnerabilities were memory. Now, the number of vulnerabilities has been radically decreasing due to the introduction of rust. If it isn't a strong indication that it is better, I don't know what is.
Also, eating with a spoon is much harder than just drinking up soup from the bowl. You kinda destroyed yourself with that one :/
@@swindlesmccoop 1. Makefiles have a much larger barrier to entry in comparison to how cargo handles their dependencies. Cargo is not necessary to install the Rust compiler. That is usually done via rustup(The actual toolchain). But cargo is a toolkit that is more about ease of access, and will do the work for you if you've not installed the compiler specified in your toml file or in your build command. You can also totally do something similar to C and C++ in regards to installing compilers by yourself. It's just more work and why would you want to do that if rustup handles this for you? And handles it correctly? Sure, if there is a compiler that isn't available for you from the list of targets. Then you should opt to do it in a similar fashion to C and C++. But that is rarely the case.
2. Rust isn't a garbage collected language though? It follows C and C++ conventions with it's data. The only thing is that they have more tightly bound the usage of smart allocators. Like how C++ makes use of smart pointers that will make use of RAII to allocate and deallocate heap memory via the stack. In essence memory management in Rust is just RAII.
4. Amazon has a dev blog titled sustainability with rust. I suggest you check it out. They give you great metrics about it compared to other languages. And I would certainly argue that it taking up 500kb more while being comparable to C in energy and time, and being much more robust memory-wise, is a small price to pay for a good language.
5. You can specify in the toml file, as well as through the command line, whether or not you want to pull dependencies from a local file, git, or crates.io. I would suggest you look at "the cargo book" - section 3.1. Specifying Dependencies, to see how to do this.
6. Many languages don't have a feature to opt out of safe code? You realise that every piece of code that C, and partially C++, is considered unsafe by Rust standards. Right? The language often doesn't need you to opt out of safe code. That is only usually the case when you require working with memory in ways that may be unsafe or with FFI. There are plenty of libraries in the Rust that intelligent people have already gone through the headache of this for you though. And so you only have to access their safe wrapper around the unsafe code. There are libraries like bindgen, cbindgen, and cxx for interop between C and C++ code that generates the unsafe communication layers for you to use.
8. Yes, it will be more. But you also get robustness and memory safety at a very low cost. I would rather have a exe be slightly bigger and experience a problem practically never than hope a C programmer thought about all the edge cases and avoided an issue. Especially so in critical systems. I don't want to be having a x-ray in a hospital and be bombarded by 800x the dose of radiation I should have (This sort of thing has happened to people, Kyle Hill did a great documentary on this).
9. Saying this ignores that the language has many built-in features to protect programmers from making mistakes that you would find in other languages. You do realise that the borrow checker by itself will prevent many new programmers from falling into pitfalls other new programmers would in other languages, right? Even if we're just talking about new programmers the amount of mistakes you will see out in the wild will be smaller. Even over 4 decades. I don't think your argument here is good at all.
10. Well actually, you could eat soup with chopsticks. It would be incredibly difficult but not impossible. Some soup would sick to the chopsticks due to the surface tension. Unless the chopsticks were hydrophobic there is going to be come trying to cling to the surface. But ignoring that, your analogy is fine I would think. Because you're probably more likely to lose soup in the C scenario then you are in the Rust scenario.
Rustaceans can come after me here all day, I hope that this is understood, I. hate. Rust.
I tried to learn it with Bevy ECS and I hated the workflow, I hated not being able to pass parameters into functions like every other programming language, I used to truly despise JS/TS and it was my most hated language until Rust.
Examples: Having to make more than one "system" to even access parameters on objects in my project, Constant confusion with iter_mut, Vec etc AND Ridiculously verbose syntax.
I am 100% certain that the Rustaceans/Rust Fanboys will come after me, Go ahead, I have nothing against you using Rust, Cargo, Rustup or anything in that ecosystem but don't try and shove it into *EVERYTHING* and don't hound others for not using it.
Bevy probably just sucks (& isn't it still very heavily indev / not 1.0?). Rust replaces learning C for me, and I love it for being usable on windows easily, great compiler messages, and not having god damn C strings. Additionally, you can basically use it as Python but with strong typing (where C has one of the most confusing type systems I've known, and in Python everything is just ambiguous).
@@gg1k It isn't just Bevy for me, Rust has some honestly unusual syntax choices in my personal opinion, I literally ended up with code wrote like this: "egui::Window::new("Mouse Data").show(egui_context.get_mut(), |ui| {", Not to mention that you have types such as Some or With which make it somewhat confusing to see at a glance, At least for me, It just isn't for me.
@@MasterBroNetwork Some is just nicer nullability, it's the case that the value is something: `enum Option { Some(value), None }`.
What is `With`?
@@gg1k "let mut egui_context = world
.query_filtered::()
.single(world)
.clone();
", With is used in queries if I remember correctly, But Rust has weird syntax choices for me and the compiler is much slower than CMake from what I've used, CMake also uses much less of my CPU and doesn't make it heat up as much which is great for fast iteration and I found Some to be quite weird since it kind of abstracted the result so looking at it from a glance was kind of weird, I don't know what to say other than that I don't like Rust at all, Not for me.
EDIT: I have attempted to use Rust at least 2 - 3 times now and each time there is always something that lingers at the back of my mind that makes it feel weird to work with for some reason, Not too sure why.
@@MasterBroNetwork Aye, my compile times are rarely more than like a second (because I generally avoid dependencies like the plague)
At 5:08 the binary size is important not for disk space, but because it improves cache locality (look it up if you don't know what it means)
What's the most powerful way to improve code locality? Re-using code between binaries, which is what shared libraries is about. When you use shared libraries, your code is smaller because it calls shared code whose addresses are present in all processes (the CPU doesn't care of the virtual address, it tags the physical address so that virtual address randomization for example doesn't affect caching).
But Rust doesn't share anything, it crams the code for the libraries within every binary, and that's bad for locality, especially considering the size of a binary relatively to the size of CPU caches.
what do you think of zig?
Do you prefer glibc or musl, and GCC or LLVM? Not trying to debate, just curious.
Clang is a frontend for LLVM right? I use clang for compiling because its errors are way better than GCC. Otherwise it doesn't really make a difference to me.
Ref: your complaint about binary size.
Newbie here, but are you using -release with your build command? From the documentation I understand that tells Rustc to optimize your binary.
what do you mean cargo does a lot of things but none of them well, are you compiling with the ---release flag enabled, many dependencies have dependecies themselves which are compiled separately while a c library might include the libraries outright instead, i personally dont use unsafe blocks unless i am sure no enduser will encouter this code in a unsafe way or i know it is memory safe
just a stupid talking stupid with no sense.
I agree with the statement, "If you can code in Assembly language then the title of Elite is warranted." The only thing (so far) I do not like about rust is that it takes a long time to compile. I use Gentoo Linux as my primary computer (because of hardware & Steam mainly) and I was a bit horrified that all this Rust code was suddenly in many applications as if Linux said, "Hey, a new programming language. Let's all use it and see what happens, wheeee!"
I experimented with Cargo using "exa" which is supposed to replace "ls". In scripts it may be better but on the command line it is one extra letter to type unless you create an alias. I suppose with the new features it may be superior to "ls" but I seem able to do everything with "ls" that I can do with "exa" so I'll keep using "ls".
One disturbing aspect of Rust is how integrated it is with git repositories. I suppose this centralization aids in efficiency but from a security perspective I have concerns about software integrity. Maybe I'm just paranoid due to my OpenBSD usage and my agreement with its philosophy.
I also use OpenBSD primarily, so I get where you're coming from, not wanting to always pull a bunch of random code. I have also used exa, and I must say that it is pretty good, for a Rust program. But it falls into the trap of what I talked about, rewriting something that was already good. Exa just takes up more space with little benefit. I don't find it to be any faster in normal usage. The only thing I liked about it was its syntax highlighting, which I will commend it for as it is consistently pretty good.
Few nice things with exa - git integration, icons and output arrangement. All of which don't exist in ls and all are very nice to have when actively developing software.
Also the recursive list output is way prettier than the alternatives. Exa is just better.
Sure, ls _works_ so one could argue: "why reinvent the wheel" but the counterpoint is... Why not? When have incremental improvements ever been a bad thing?
vi worked .. but then vim came along. Vim was a massive step forward and is still very much used today, but vim grew to be bloated, now we have nvim. It's virtually the same to the end user, except you can configure it in Lua ) which is an objectively better language than viml. See my point?
Just because something works doesn't mean it can't work better. That's why Rust matters so much. That's why it's bleeding into the Linux ecosystem. No matter what your competency level is, you will write memory related bugs. It's a fact. With Rust, it's an extra layer of padding to stop you from blowing your foot off. You still can. Of course you can, but now you have to mark areas of the code where you're tinkering with black magic as unsafe... Specifically making you take a step and think about wtf you're actually doing.
@@bursthooverbag10 I liked your comment: "Rust matters because it is an evolutionary improvement of ls, similar as vim was an improvement of vi." You have made your case; I cannot disagree with you.
As I am not a software developer but a "general user", exa seemed like overkill but it is certainly more human-readable. If I were a programmer or software developer, I am sure I would welcome the new features and would reach a point where it would be unthinkable to use ls anymore.
Like SystemD, exa is here to stay and will one day, I am sure, become the default when old stick-in-the-muds like me fade away.
@@bufordghoons9981 if you're working in a resource constrained environment where even core utils are a push, exa is definitely overkill I can agree there. For every other use case though, I've never had any issues with it :)
Systemd is a divisive one. I personally like it but I can 100% see the counterpoint. One of the two times I successfully installed Gentoo was none systemd and its footprint was ridiculously small. I just didn't like the constant maintenance on the system though, and I was always terrified to touch anything because it took me so long to get it working. Good job security though 😂
@@bursthooverbag10
"but now you have to mark areas of the code where you're tinkering with black magic as unsafe... Specifically making you take a step and think about wtf you're actually doing."
Just want to add to this. The "unsafe" keyword also has another purpose than making you think twice. You can, with 1 simple search, find all the areas in your code where UB could possible be coming from. "unsafe" limits the scope of looking through your code to find UB problems (thus it's recommended to keep them as small as possible). This is a really excellent thing, cause you don't have to look through your entire codebase to find the problem.
In C/C++, it will be very hard to find the area where it may be coming from since anywhere in the program could be unsafe.
The main reason is the C cheat on its binary size by pre-distribute its standard library. Rust cannot assume it so it statically link its stdlib within the binary. In my environment uncheated C binary compiled with gcc -static main.c takes 872 kB.
To force Rust to dynamically link programs, use the command-line arguments -C prefer-dynamic; this will result in a much smaller file size but will also require the Rust libraries (including its runtime) to be available to your program at runtime.
Fun fact: Rust’s binaries with size optimization and only libc used, without standard library, are far smaller than similar programs in C with size optimizations and use of libc. On my Windows, for example, a simple hello world with puts with GCC gave me 48 kb, while with rustc it was 11 kb
/usr is not for "universal shared resources", just read wikipedia's page for UNIX Filesystem: "/usr: the 'user file system': originally the directory holding user home directories [...]"
There is an argument that making good Rust programs is easier than making good Python programs. I can't confirm it since I have not tried making anything serious in Rust, but the argument seems reasonable: rather than writing unit tests, you model the valid states of your program using structs and the transitions between them using impls, then if there is any runtime problem, the compiler spits out an error so it can be corrected.
Yea well, Rust is probably way better than python. I think the main issue is the rust community is very vocal about changing everything to rust including linux kernel. If python users would start pushing python code into linux kernel and be vocal about it and rewrite code into python and claim it is superior simply for being python then I bet this video would be about python instead.
@@Mario1vsSonic1 I'll choose cult of the serpent over cult of the tree fungus any day of the week btw. And when program performance matters enough to justify using something other than snake lang, I reach for Go.
@@k98killer I have no idea what cult of tree fungus is.
I personally only use python (yea well this is excluding shell) and trying to learn C.
I have nothing against any language/tool. It's how you use it. Or in rusts case, how you try to push it as well.
The only exception is OpenBSD, it works for routers, servers, laptops, desktops, everything. I run it on an old iMac G3 which is my desktop. It just works, but linux has no support for that due to hard dependencies in kernel for stuff not compatible with old hardware anymore.
What is the tree fungus?
@@Mario1vsSonic1 Rust is the name of a tree fungus. Though the users of the Rust language predominantly believe it is named after oxidized iron, it is actually named after the tree fungus.
what's the name of the game in the bg footage?
Initial D Arcade Stage Zero. I emulated it on my PC.
Zig anyone?
Calling someone unintelligent for their choice in programming language is like calling someone weak for their choice in hammer weight.
How much work are you really getting done if this bothers you?
le blowup clown hammer.
le 100 pound hammer.
i mean yeah if it works sure, but think about how much resource it takes to swing the big hammer let alone the disturbance you make when you slam it down.
@@quitting_the_internet wrong interpretation.
Programming Language 1 = C
Programing Language 2 = Rust
Hammer 1 = Heavy Hammer
Hammer 2 = Light Hammer
Programming Language 1 == Hammer 1
Programming Language 2 == Hammer 2
If JOB == "Hang Picture Frame"; then
Use(Hammer 2)
Elif JOB == "Build shed"; then
Use(Hammer 1)
Fi
If you're writing a server or anything that has to do with needing security then you're better off using Rust.
If you need to write drivers, a kernel, or interact with hardware and a very low level then you're better off using C.
It's overkill and hassle to use the heavy hammer to hang a picture frame.
@@wheezybackports6444 > If you need to write drivers, a kernel, or interact with hardware and a very low level then you're better off using C.
not entirely true anymore. check out the work on M1 mac GPU drivers (in rust) for asahi linux
c is still useful in some instances though, e.g. it implements all the latest CPU instructions, like float16 on ARM
How much are you wasting time commenting.
Not being snide just seriously asking since ya point of work getting done.
Use the correct tool for the right job.
Rust is perfect for learning and getting into low level programming without worrying about memory stuff. Some applications are perfectly fine to write in rust.
No one is complaining about python users unless they would start saying python should replace C and try to push python into linux kernel. The deeper understanding of how coding and computers work the better the code and more reliable. And C forces you to learn a lot about how a computer works while rust doesn't to the same extent. Obviously there are gonna be differences. I rather have ppl that understand computers properly write my kernel and userspace and all whatnot needed for an OS. I don't trust myself to write code for an OS.
But I would trust people that use a hammer instead of a screwdriver?
Rust community are very vocal about how rust is superior for being a higher level language than C (all the argument boils down to that, such as memory handling and the safe functions etc.) and you can use all those arguments to argue why one should use python to write kernel code. Just compile the python.
As mentioned, if python community did that then I bet this video would be about python language and not rust.
My first experience with rust was trying to compile this one terminal text editor called helix it took way too long
I used to strongly dislike rust. Spent years using Haskell/Python/C etc. When I finally tried it, all the small design decisions made so much sense! Not to mention the extremely clean official guide. I mostly use Rust now, with python as a convenience language to get prototyping done quickly. I'd suggest you give it a serious try, you might end up loving it :)
But he's not a programmer. His critiques all stem from issues he has when building all his PC applications from source when they are written in Rust.
@@nomadtrails Yeah keep coping, in the meanwhile Rust is dying, and soon you will remain without job... oh no wait, you never had one.
@@DS-nv2ni Lol I do the hiring at my company, since I'm the owner...
But we don't use Rust at my company. I use it for a couple personal projects.
But I don't think you even get the point of my comment. The OP isn't even programming in Rust, he's just mad that he needs dev tools to build his applications from source in user space.
I expect you'll not understand this comment and make some sort of nonsensical reply. Be my guest.
@@nomadtrails I actually started writing things in Rust and I hated it. Ugly syntax, horrible type system, horrible compile times, huge binary sizes, the touted memory safety half the time is unironically panic!("out of memory") - must I continue?
@@nomadtrails I understand what he said, good for you that you don't use Rust for your business.
I understand your comment too, you think I can't by my initial message because to you looks like something stupid, because you are the one that can't understand how bad is to support languages like Rust, probably you are naive, one of these tech fanatics that love "everything science".
I'm a tech skeptic with decades of research and engineering experience, I know the difference between building an existing app and trying to make a new one from scratch.
I'm not here to convince anyone, just to insult, because I spent my time trying reasoning with people, at my age I'm way more satisfied to insult people that are braindead like you, I bet you also believe AI is about to change the world isn't? GPT4 can reason, right? We will get to Mars soon? Self-driving vehicles behind the corner?
We gonna fix climate change? Santa will come also this year?
What do u think about zig language?
It's interesting, but if I want to learn an alt language, I'll probably learn V first
@@swindlesmccoop but you can lightly observe the language like a C coder that not require to learn zig. Just fast view on documentation and main language purposes. Its just a wish not a requirement. It would be interesting to hear your opinion
I'll check it out
I just started falling for the hype
Why do I like rust? Because it's fun.
It is really cool, if you have fun. I like c and c# for it)
how do you learn so much stuff??????
"Memory safety is for dummies that can't hack it in C" (paraphrasing). I think this is an argument for the young and foolish. It is based purely on ego rather than engineering wisdom.
Firstly, before I start, I'd just like to say that I wish you did more research on this. The Rust docs, and the Rust book explain easily in detail most of what these tools do, and many of your points could be made more clear if you'd known this.
Now to make it clearer:
- Cargo is a package manager. That is it. It's neither a compiler, nor build tool.
- rustc is the compiler, and cargo uses it to compile code
- The many other commands cargo supports (i.e. cargo fmt, cargo clippy) are all **optional** and are separate tools (rust-fmt, and clippy)
For your extra memory safety thing, I'd rather put it's both ways. Memory leaks take up a large majority of the bugs on projects like Linux, Windows, and many more. Having a tool be able to manage memory for you to prevent leakage is, in my opinion, logically smarter (hence why Linux uses Rust for some things now).
One thing I'd like to say as well is that you bring up cargo a lot of times. To me, it feels weird bringing up what is essentially an optional module (there are a lot of other Rust package managers) in a discussion about a language. It's like bringing up npm in a discussion on why node sucks.
As for the bit about why cargo doesn't put build outputs in the bin, it's quite simple and I don't know why you don't get it. Let's say, someone wants to build a simple library, why should it be put in the bin?
For the binary bit, are you sure you built with `--release` enabled? If not, then you're probably running an unoptimized build which perse is much larger. And, in my opinion, the many things Rust does to simplify your development and propel your skills further are well worth the mildly bigger binary sizes.
I think now, for your index part, it's more of a personal thing. In my own experience, at max, the index only takes about 1 minute with the same speed (about 10mb/s).
The point about most people grabbing code into the unsafe function, in my experience, is false. I've only seen around 3 Rust crates use unsafe code and that's mostly because they are either using C code (the language your vetting for), or because they are doing some extremely low-level things.
As for the reason I like Rust better than C is a myriad of reasons. Those being of course:
- Better Memory Safety
- Generally Better Syntax
- Near Zero-cost Abstractions
- The Amazing Type System
- The awesome toolchain and ecosystem around Rust
- The great community support
- In most practical cases in faster in terms of literal speed, and development speed
and much more which, in my opinion, makes the language well worth it. I do get though, as I have been doing myself, Rust is not for everything.
You probably shouldn't be using Rust for web development yet (it's under developed really,) and many other things.
Deep down though, Rust can do all the low level things C can do, which does make it on the same level as C, just with many optional abstractions. But also, in my opinion, C is most likely not the best comparison to Rust. Rust was, some time before and still now really, made more as a modern C++, and in many ways and in my opinion it has achieved that goal and has even transcended that. I doubt it'd ever be as fast as C, but it can always be close to it, and in the end will always be easier than C.
Rust is modern C++, and Rust is C for the 21st century.
Yea cargo should only be used on Macos, Windows and for rust developers. Normal Linux and bsd users should use their native package manager or build it themselves, especially when the GNU rust compiler becomes stable
Rust will never replace a so well designed and simple language like C.
It just can't.
Totally agree,that rust is last candidate to 21 century c by flexibility. In 21 century we going to dark. Almost all good things stay in 20 centure.
crab language
Elitism shouldn't be justified by saying the people in the Rust community are elitist, so I should be an elitist calling a person who uses Rust less intelligent. If someone or a group of people does something wrong, you should do it as well? Also saying that people who use Rust to write programs are less intelligent says more about you than Rust as a programming language.
The video is more a commentary on the implementation of the language rather than the language itself, but its hard to iterate that when the average UA-cam viewer is trying to click and consume content that gives them instant entertainment.
@@swindlesmccoop This has nothing to do with my main point and that's because you still think people who use Rust are less intelligent, "I'll admit that saying Rust programmers are less intelligent was a little bit of a bait, I still maintain the position..." It's not bait if you have that exact same position. Commentary on the implementation of Rust has nothing to do with saying Rust Programmers are less intelligent because they like programming in that language.
In a different comment I explained it was because people will attempt to solve problems that should be done in C, but instead use Rust and refuse to learn C because it's "easier" to use Rust or whatever.
@@swindlesmccoop That's just an opinion, if a programmer thinks it's easier to do something in Rust than C, then let them use Rust. Stop trying to make your opinions look like facts. It's no justification for you to say people who use Rust are less intelligent.
Edit: I just realized that you refuse to learn rust, so your argument is hypocritical.
I also want to express why your hatred towards code of conducts is ridiculous. These things hardly affect anyone and they usually just say to be nice to others. To be offended by something so little is ridiculous, all your arguments seem like you're assuming something that the code of conduct isn't even saying. "What? Why should I demonstrate empathy for people?" Are you seriously offended by something saying you should empathize with others? "'What do I do if it says 'permission denied' I'm most likely going to make fun of them and tell them that Google is their friend." Maybe just answer the question, it's as easy as saying use sudo (or doas if it's what they use or they're using openbsd). All I'm really asking of you is to be a decent person.
@@fellowproghead7708 I still think Rust has some stuff they should improve. Like to get a user input is very easy in C, someone who never programmed will understand it at once. But in Rust, to get a user input you use more words than you should be using to just be getting a simple user input. I tried to learn Rust, but there are some stuffs that suddenly happens without a brief explanation, like when you want to print a variable and uses {} in your println macro may suddenly give a error even tho it wanst supposed to, or even some functionalities giving errors when you put a semicolon at the end because it doesnt want a semicolon at the end for whenever reason. Rust is not that all, and actually, Go is a way more better language in my opinion with a lot of usefull and features that just makes your development far better. Rust just seems too overrated when you have better options. The only good thing about Rust is the borrow checker, but i still dont see Rust as an C successor and to be honest, i believe Carbon will be far better than Rust in a lot of terms
I legit don t know of it s a troll, and that s what makes it a good troll
Schrödinger's Troll: without asking the creator to verify whether or not it is a troll, it is impossible to know which state it is in and thus simultaneously could be a troll or serious
@@swindlesmccoop Or in superposition (troll AND serious)
I agree , great points , nice video
"Obviously you are better at programming because you know a harder programming language"
🤦♂🤦♂I hope that was sarcasm, but I suspect it was not
I think all group have elitist. I rather just be language agnostic but C++ , C are my favorite languages. I do program in Python foe fun as well. The only one I do not like is C#. Do not get me wrong C# is an awesome language, I just don't like it because it was made so Microsoft could gain a monopoly on web programming. If C# work as well as Java on Linux, then I would not hate it because coding in it is fun.
Hehe, i love c and c#)
Having done a lot of embedded programming in C and C++, I can understand where Rust is coming from. But having been in the programming professionally forever now I can see the problems of forcing you to do things in a "certain way". The correct way seems to change every so often and soon the establishment will be telling you Rust is doing it wrong. C and C++ has survived for so long because they don't strictly impose a programming paradigm on you. AI is also a game changer in terms of generating code and tests. Memory Safety thing that Rust is all about becomes less of an issue if AI can now generate thousands of test cases for you so you can catch UB edge cases.
Don't get me wrong I don't hate Rust at all. But I also don't easy buy into the kool aid. I am old enough to remember when people said C++ is dead and Java is taking over. Then there was the Binary -> XML->JSON->Binary (GRPC) we came full circle lol.
Using libraries where possible is a good thing as it reduces code duplication and reduces the chance that you mess up in your implementation of something
Dude just install the damn binstall crate, if you're pissed that much with the compile times.
Compiler can't move binary into /usr/* without root privileges.
Most people don't do daily driving/programming as root.
C syntax requires discipline to look decent.
1. Even if I do it by myself it fails and complains about libraries and stuff
2. Who programs as root, that's what sudo is for
3. At least C syntax can look good, Rust looks horrible even if it's written by the book, but most people don't do the cooking by the book
@@swindlesmccoop 1. I never had such issue ¯\_( ͡° ͜ʖ ͡°)_/¯
2. Who programs using sudo?
3. Yes Rust syntax can look very ugly. Especially once you throw traits, generics and lifetimes onto one big pile.
Both can look very ugly / confusing.
@@universalserialbusman
2. In "sudo make install"
3. C has the potential to look clean and pretty, Rust always just looks like slop
@@swindlesmccoop 2. I wouldn't call that programming. Usually that is just referred to as "deploying" or "installing".
The actual software development doesn't and shouldn't require any root privileges.
If cargo would move every built binary into /usr/* the programmer would need to run cargo as root every time, which is just unnecessary.
Also, i just compiled a program myself and cargo doesn't even put my binary into "~/.local/share/cargo/" it is in my source code directory under "target/debug/".
3. Every language (even C++) has the **potential** to look good... except VBA
>REEEEEEEEEEEEEEEEEEEEEEEEEEE YOU CANT BASH MY HECKIN RUUUUUUUUUUUUUUUUUUUUUUUUUST
Never could understand any other language than C (and MS Basic)
C is the pinnacle of human accomplishment anyways
Out of curiosity I compiled paru on a 5 yo laptop. It took 3m 45s xD
I use a ThinkPad from 12 years ago, so your setup is probably going to be quite a bit faster.
i tried on a raspberry pi 4. tried
Rust compilation is a bit slower than, say, straight C (especially with dynamic linking against pre-compiled system libraries), but it does do incremental compilation, which means that for real world work, your second compilation will be 10-20s, if that.
I'm curious, you compared the number of dependencies between Rust and C and said when you compile your C projects they have much less dependencies and those dependences download quickly -- what are you using to install C project dependencies?
I think it's important to remember that if you're on Linux, your OS _is_ the C package manager. You've just already downloaded them all.
Rust is for those who aren't smart enough to manage memory at 2:59
Maybe, but I can see the appeal of memory safety *by design* . Programmers are humans and humans make mistakes. All sorts of tests methodologies have been designed to catch those human mistakes.
I'm not saying Rust is great (I don't like Rust much), but if a language can guarantee *by design* the absence of a whole class of bugs, it is a really good upside that appeals to a fringe of programmers whose intellect does not have to do with the choice of the language.
C isn't harder but is hard to do things correctly.
Let's imagine that the quality scale is 10.
Rust prevents you from producing applications with quality less than 5
It also makes it very difficult to produce 10 or 9 quality programs
C|C++: Makes it easy to produce 0.0 quality applications.
It's also easy to produce 10-quality apps.
What do I mean by quality?
clean from memory errors, data race, (logical errors)
@@baxiry. that is why you learn engineering at college. doing c/c++ is like chemistry, if you are not aware what you are doing you will end with a disaster.
Hello world in rust is like 5mb (static). The equivalent binary in zig is 2kb! A http client in rust is around 9mb and in zig it's 100kb. I tried to switch to paru aur helper because that's what the yay dev is working on now, but paru download and compiling takes way too time, so I ended up going back to yay even though yay is a go program with too many dependencies too.
Rust and Go have both made this tradeoff of having a fuller featured static binary. I think for most end user software it's the right tradeoff, however it does limit the ability for it to "replace the system", e.g. if every binary on Linux were ported to rust without serious changes to linkage we'd be in for a lot of disk usage.
But, for most of the stuff most of us work on, a 5mb binary isn't that important. A basic .tar.gz drops it to 900kb.
If you're sick of the garbage, bloated AUR helpers, go ahead and check out the one that I wrote in C ua-cam.com/video/lamPvoJxTsM/v-deo.html
like a conflict of interest, a low level language that can be high level? a high level language that is also low level? languages are separated based on need, doing it all at once becomes like python (i love python btw), there isn't really a *line* though.. right? i prefer something suckless, even if it means more work..
also has rust _redefined_ 'safe' ?
that being said, i love me some ripgrep, there is some rust power for sure, but it requires the _wise_
Everyone should read this dude's "blog post" about codes of conduct. Amazing.
Gonna be honest, it was pretty cringe
My guy knows jack shit how compiler optimization levels work 💀💀
I know about compiler optimization when it comes to C, but not Rust. This video was critiquing Rust as an end user, not as a programmer. I can make a video on the latter if you would like.
@@swindlesmccoop You might just want to do some research on the side rather than making another video this month. If your goal is to Ben Shapiro this and get a bunch of rage-engagement: congrats. But that's a tough way to live.
@@KirinDave While rage engagement is an effective content strateggy, it certainly is not mine. If my opinions are controvesial, then so be it. There will be a small amount of people that agree, and a large amount of people that disagree. I do not have a lot of time to devote to responding to UA-cam comments (the reason there are so many well thought-through comments I have yet to respond to) but regardless of the way people feel about my content, I will continue to speak my mind. I have done a decent amount of research (much more after posting the video so I could understand the perspective of some of the comments) and though I am not an expert, I feel as though I can at least engage in some discourse about the subject matter. I honestly do not plan on making another Rust video because I do not particularly find joy in ranting about anything, but this video was something I felt I needed to make because my opinion had gone unarticulated for far too long, and I have been given a platform to be able to share it.
I agree overall. I can't wait for the video on Golang bc it's much more of a hot take and the video on Wayland, without it I'd switch to Wayland for sure like everyone will.
All that i understand from comments, thet one thing: for every tool exist user,that love this tool)so cool,why people didn'see that simple thing? I don't like rust, and i don't think that this language already can be used for os dev. I love c and c#,i don't like python. But i saw how that people thinking,how they optimizing code,and for this, this developers got my respect. With no toxic no agression. In rust i don't like pr. This is only my opinion and my experience. And i think, that many good and clever people wich programming in rust. It's just not my language. Maybe for now
As a hobbyist programmer, I really hate Rust. While coding in Rust, I always have to think about ownership and have to wrap many variables with Rc or Arc even when I know I don't need them at all.
However, I understand why people use it. As codebase glows, people can't just comprehend all of it, then end up shooting themselves in the foot. So, Rust is not something people should love, but people need.
I really don't mind if a program is written in Rust or not, as long it works as intended, it's fine. Talking about Rust community it's like talking about any community on the internet, just avoid it and it will be fine. Also, about the "safe memory" stuff, i read a article some time ago, can't remember now, saying how the addition of Rust to Android development made some improvements on it's security. I think the cargo problem can be applied to most of the tools of any modern programming language, so this could be more of an issue on how modern computer works, idk. Anyways, nice video.
Usually the problem with things working as intended is the fact that what is intended is what I'm frustrated with. Cargo is intended to pull the package index on every operation. Do I agree with that? No, it frustrates me, but it's still working as intended.
I think that Rust, if used properly, could actually be good, but the problem is the standards around it and the way it's actually implemented in many cases.
@@swindlesmccoop Cargo is actually solving this "download the whole index" problem, for what it's worth. It's enabled via a flag in 1.68.0.
You really shouldn't have to use rust as an "end user" generally. That would be like using C as an end user.
its zero cost abstractions
Why is it slower then?
There are no "zero cost abstractions".
Based
Lo trans es tranza
I'm not sure how familiar you are with programming larger scale programs that require real-time performance and/or security. A lot of your complaints about Rust are less about the language and more about tooling and some of them just apply to the modern software world.
> UNIX philosophy
First, UNIX is dead. Second, the UNIX philosophy does have a point in avoiding programs to be tightly coupled, however, a program having multiple functionalities is not a bad thing either as long they are coherent to the purpose of the program and not tightly coupled. The Rust (and Go) tools support testing, compiling, dependency management and profiling. All of those functions are mostly orthogonal and they are coherent, these are things programmers of all levels do, separating those into binaries makes the system arguably more "bloated" and complex.
> Cargo
I agree cargo isn't very good, in fact, most "language package managers" are horrible, but they exist for 2 reasons:
1. Your OS package manager is also horrible if not worst (also it isn't portable)
2. These languages have a complex ecosystem for a variety of reasons, and unfortunately they define a "package" to be something way more complex than it should be, making these big tools a *requirement* not an option for managing software.
Also, not installing to /usr/local/bin makes sense, as it would require root privileges, npm can install to /usr/local if you pass the -g flag.
> Dependencies
The tendency to have hundreds of deps for a trivial program is an unfortunate reality of modern computing, it doesn't have to be this way, but most developers (and especially their customers) don't care.
> Rust
Rust's big binaries are (mainly) a result of rust preferring to make binaries mostly static, so no dynamic linking(except when it does), by default the binary's symbols are not "stripped" which is a bad default for release builds but you can fix that on the TOML file pretty easily.
I'm not sure what you mean by bigger memory usage, I have no metrics on that one.
Rust has horribly slow compile times, its syntax is *not* simple, but that's the price for a very good static analysis tool being built-in.
The usage of 'unsafe' does not in any way defeat the point of the language, A program that is 99% guaranteed to be "safe" *is* better then one that is only 10% guaranteed. At least with unsafe it becomes explicit where possible memory issues could be coming from, where in C/C++ they can literally be anywhere.
> Rust ""Community""
It's trash. Just like most online "communities", they somehow are more insufferable than the modern C++ crowd. I agree COCs have no place, but this isn't a issue for most users and even developers.
In conclusion, I'm not a rust fanboy, I really don't like the language but it makes sense in its original niche. One language you might enjoy is Odin, it is simple and made for modern systems, it fixes most of C's glaring mistakes and has been very nice to use.
"UNIX is dead"
It's always something that I like to debate. It's dead in the sense it has been used and reimplemented so many times (and poorly) that it shows all its anachronisms and flaws.
It makes me think that we're still talking about things like "TTY" and "PTYs", "GECOS field", "root user", "ioctl" and all the crusty stuff related to minicomputers (PDP-11, VAX, Interdata 8/32) that nowadays we don't have.
Many things like network (Berkeley Sockets), graphics (SunView, NeWS, X11) and consoles were implemented on modern UNIXes in crusty ways, assuming that a graphic workstation still had TTYs. And the consequence is that the C API becomes crustier.
Plan 9 fixed many things in this sense, providing a powerful abstraction (9P), getting rid of old stuff (providing emulation if needed) and implementing networks and graphics easily.
BeOS was another interesting OS since it exploited more the hardware for multimedia application. The only thing I criticize is the fact that they used C++.
Maybe nit-picky but there’s good reason to differentiate what the rust compiler does to a ”built-in static analysis tool”. It checks an axiomatically mem safe paradigm as opposed to trying to spot bugs, which is the whole appeal as opposed to C/C++ static analysis tooling. (This is where someone always points out RefCell and race conditions, but the difference here as well is it’s explicitly opted in to interior mutability)
Not arguing with above but making a distinction for those unfamiliar with Rust.
any tool in the hands of a wrong person can be a disaster.... programming languages are just tools!
Sepples chads represent
ill stick to C and C++ 😄
I remember trying rust. my experiences was one of the worst programming languages ever
Edit: Didn't know that rust fanboys are attacking this video and the comments section. ill never move to a language like rust. it goes in the trash can for me. if someone loves something and someone else doesn't like something that you don't like then it should be okay what are you going to do force them to learn rust? like it's the end of the world? so lets say if it was something else you disliked against another language then suppose a different community came and attacked you. how would you feel? yeah. just like us angry and commenting while crying cope tears because someone hated a language on the internet yes yes. and just because rust claims to be safe doesn't mean its safe or always safe at all. any low level language is safe depending on the user and if you make your code unsafe then of course!!! **the more you know**
You probably just weren't open minded about it. Have fun writing unsafe code with a bad developer experience then.
@@Cookiekeks No need for the last comment. I love Rust too, but everyone is entitled to their opinion, and may freely use what they want.
But yes, you might want to be a little more open minded. Rust ranks #1 most loved 7 years running on stack overflow. It is true it takes some time to get started on it, but once you do, it's strangely real fun to use. But even if you still don't like it after that, you're entitled to that. :) But I would also say there are reasons for this, and it's less of "it prevents people who don't know anything from making mistakes", and more, "we are human, it is not about IF you will make a mistake, but more so of WHEN. this is true especially on a team of people. even 70% of microsoft CVE's were caused by memory unsafety, so this is a very real problem. if there's anything we've learned over the decades, it's that we need something better. more security is better for you, for your company.. even for your government"
@@Cookiekeks Nice, a rust fanboy! ill continue writing in C and C++ like i said. your opinion doesn't matter in my case because im having fun with programming. i don't need someone like you to program me into a different opinion about rust. if i said i disliked it then i disliked it. there is no need to be angry because you might understand and love one programming language and another person had a bad experience with it. 🥱 not all heroes wear capes and not all swords are sharp until they reach the battlefield.
@@Cookiekeks Have fun being sued for using the language name
@@gr4tisfaction They took that back
Absolutely based. Elitism is always justified, especially in technical domains.
Yes it is, and Rust is an elite language.
Cope
i think rust is good, and its better than go. but of course im talking only about syntax and expressiveness of language only. the cargo tool and dependency problem i think is valid criticism, but the pros beat the cons of the language overall.
i understand how you dislike the politics around rust, i dont like it either, i just think that theres no way they can enforce such principles into people using the language, if they keep acting cringe, i might switch sides and join the rust hate train
Are they really a community of LGBT/communist antifa?
Nice comment,man
I've noticed throughout your video you have hipster views on software. A computer is a machine, a machine is a tool. A machine may have various functions it can do. A programming language is a tool to extend the machine. Each language has a niche and purpose. Do not look at any language as worse than another. You must understand it's niche.
The UNIX philosophy is used incorrectly now days. The abstract idea of the philosophy is that every program is useful, fits it's niche well, does not replicate another program on the system, and everything is a file that can be easily manipulated.
This philosophy is quite outdated now days though. Plan 9 has modernized these ideas and it's philosophy should be followed.
The tools you use mean nothing about your intelligence. The tools you use don't make you cool or a loser. A tool is a tool and must be recognized as such. This goes for software, operating systems, and programming languages as well.
I've noticed over time the truly intelligent and knowledgeable people in computer science, programming and development do not care about how using a piece of software makes them or other people look. They know it does not matter. These same people are also the same people that do actual work. They don't spend their time ricing their window manager, or using certain software to look cool.
Based.
although the "everything is file" isnt really part of the UNIX philosophy and more of a design choice of UNIX (a bad* one).
*being able to interact with the kernel through files is fine, but when that comes at cost to other handlers and APIs (like it unfortunately still happens on linux and bsd) then I choose a good system API instead.
@@marcs9451 you would like Plan 9 and it's 9p protocol. Plan 9 communicates through one universal protocol which is 9p. All system services talk to each other through 9p. 9p is basically a file server protocol. You have your server which serves API endpoints as files and you have your client which can read and write to those files.
Yeah, also because hardware changed but operating systems didn't reflect those changes: Windows is stuck in the IBM PC world, carrying crusty stuff from the DOS era and 8088. UNIX is the reflection of a long gone world, made of teletypes, minicomputers and serial modems, and it got retrofitted on the workstations.
If I had the time to develop a new OS, I would like to have these features:
- a microkernel that is small, fast and lets you expand the system writing servers and userland drivers
- a good IPC and file system (9P?)
- multimedia capabilities (like in AmigaOS, BeOS and IRIX)
- a good window systen that is extensible (a clone of NeWS perhaps?)
- being portable, getting rid of hardware assumptions (like the x86 ones or the TTY), and be able to run on machines ranging from embedded platforms/late 90s computers to modern multicore machines
There are many unique operating systems that are obscure yet interesting, I could also mention ETH Oberon and Symbolics Genera.
@@DVRC I think doing work on 9front would be a good start. I'm thinking about daily driving 9front and just living with it. If I need something I'll write the code for it.
Rust does great at what it's meant to do. However, people are trying to use Rust to replace C as a whole, which is not its purpose, as it is good at different things compared to C. I recognize that programming languages are tools. However, people are trying to perform tasks that are basically meant to be written in C by nature using Rust because it's "easier" - that's where I take issue with it.
On Plan9 as a whole - seems like a good concept. I don't really have the time to really take a serious look at everything but maybe when I do I will switch to using it.
I don't "rice" my window manager or use software to look cool. I haven't changed my DWM repository in over three months and my dotfiles in over two. I have everything working the way I want it to. I use whatever tool is the most efficient for the job. I like DWM because it tiles the way that I feel is natural and I have a lot of freedom with how I want my keybinds. I like Vim simply because I think the movement and commands for editing text are very efficient. I don't use them to look cool, I use them to get work done.
Sigh, your argument is not contraversial, it's just stupid. Because you don't understand something doesn't make it bad. And then the argument about how intelligence somehow correlates to which programming language someone is using... I don't even have words for that. I could write all my code in notepad and itneoukd be objectively more difficult than writing code in vscode or emacs, but that doesn't make me more intelligent. Most of your arguments are not attacking the language but rather the tool chains around the language. Cargo is a command line interface alias; it's not that complicated. Many modern languages consolidate their toolchains into a single binary because it's more organized that way. The compiler is rustc, you can invoke it directly, there's also rustfmt for formatting and a bunch of other independent binaries that are invoked via cargo. With c you have to learn make, cmake, bazel, and many other crazy tools to accomplish half of what you can do with the rust toolchain. Java has gradel, ant, maven etc. Newer languages such as dart, elixir, clojure, elm, rust, Julia, and go have these tools included to streamline the process of building your programs. Many older languages have moved towards this convention as well because it's not effecient to have to learn an entirely separate domain just to link libraries, pulldown dependencies and build your apps for 99% of use cases. You only need something like make or bazel if you're doing something very specialized. Also, given that many people build stuff in docker and other containers these days, it's just easier to define how you want your code built in the code itself rather than having to change to some complex config file with its own DSL. For example, say I want to wrap libsodium into a rust program, I can just grab the library locally and write a build file to link it to my wrappers (or use one of the well maintained wrappers that already exist).
I also like this hilarious misconception that people use one single language and that they congregate into these small fiefdoms to gate keep their languages (some people do, but they are generally junior devs). I've been in the industry for almost 25 years and I can handily write code in at least 20-25 different languages (more if you count different flavors and dsls). I've worked in many different domains: cloud, crypto (cryptocurrency and cryptography), machine learning, databases, government, web, compilers, and video games etc. I have languages that I like for specific domains. If I need a highly available web server with built in resiliency, I am going to reach for Erlang, elixir or maybe go. I wouldn't try to write such a thing in c or c++ because it would be inefficient. Each language is just another tool in your tool belt and while I could understand if you don't like the idioms of the rust language, writing off the entire ecosystem based off of anecdotal nonsense is just not constructive at all.
"Everyone uses unsafe all the time", I'm sorry but that's just wrong. The unsafe keyword is specifically for cases where you can't handle the problem at hand without dropping into potentially undefined behavior. This is primarily in cases where you need to write your own garbage collector (manage memory directly) or wrap something from a c language etc. In most examples where I or someone else has used unsafe in my experience, it's been done in a way that adresses these potentially undefined issues because rust also has tools for that (the compiler will also tell you if something undefined happened). The primary reason why this is a constrant to begin with is because 99% of use cases don't need to use unsafe. On the other hand, I've seen so called c/c++ experts bake undefined behavior into very simple apps because the language is designed in a way that makes it very easy to do so. Most of the bugs that are in the unix codebase which lead to hacks are related to memory safety and exploitation. Rust at least tries to encourage you to not write things in that manner by gating the use of undefined behavior under a keyword.
All this talk about elitists too... You should probably take a long hard look at yourself... It's ok to like the things you like and to have valid criticisms about the things you don't, but frankly most of your criticisms are not very valid or logically sound. You probably would be better off just saying you don't like rust and then not further justifying yourself. I don't like JavaScript and I have many valid reasons as to why that is, but I don't have to justify my opinion. And instead of complaining about how JavaScript is taking over so many domains, I've gone out of my way to help some of these domains do things in a way that mitigates some of the cons of JavaScript (I contribute to various open source projects that address this specific issue). If you feel that rust is objectively bad and harmful then go ahead and try to rectify things by creating PRs or writing your own language. Just because there is a popular alternative to c and c++ for many domains now, doesn't means it's automatically the wrong way to do things. I still have usecases and projects that maintain c/c++ code. Hell, I've got a pretty integral project that uses common lisp. I weighed the pros and cons of other tools before I made the choice to write these projects in their respective languages because I don't like wasting time needlessly. Maybe you think that everyone should use languages like c and asm always but objectively, if the larger community did this, there would be so much technical debt that it would be insane.
Rust community is super toxic. I've just read coments on video criticizing "implicit return" as being hard to read in the mids of if else statements (which it really is), the rustsheep we're totally toxic and throwing tantrums that the person who created the video doesn't understand Rust, that writing random number inside of if is totally readable.
if(x)
{
0
}
1. The reason a Rust binary uses dozens of libraries is because those tend to do one thing... and do it well.
2. I started Rust 9 months ago from scratch (I haven't even seen the syntax) and it edged out C++ - my previous favorite language. I thought it could be D but no one uses that. My main problem is it's very green: no spec (gccrs might help with that as at some point they'll need a common denominator) and missing features still in development (most often I miss some higher-kinded type stuff).
3. To understand Rust fully requires a bit of theory so I'm not surprised that fanboys are insufferable. Haskell is the only language that I've heard to have it worse. Luckily I've barely interacted with them.
4. Writing code the harder way (in C) just 'cause is fine. Whatever rocks your socks off. It has no place in engineering though.
5. Half of the people using unsafe is likely an exaggeration. Or you hung out with the wrong kind of rustacean. The unsafe (like most of the code) is more for the maintainer so you can verify your code 1000 lines at a time (a typical module) instead of all at once.
6. I don't care for CoCs. My eyes roll every time I try to read one. I've never been affected by them but they make bigots miserable and that sparks joy.
based
i hate rust too.....but....you could do something about the visuals.....it is better to backup your theory with some facts.....
Ironically this video has pretty good viewer retention. They see the car and their eyes are engaged so they do not get bored.
Finally someone that knows what their talking about and isn't a front end React / bootcamp "developer" that read somewhere they have to be a Rust fanboy... I agree with 100% of your opinions in this video... Love C and love Zig!
Nim is the best programming language ! 👑
I really don’t understand all the hype about Rust, it’s just low level JavaScript
Did you mention a single point about the language itself?
Also "x language is better than y language because x is harder therefore more intelligent people use it" missed the point entirely. The goal of a language is to be easy to use. Not hard. Easier is better. We use programming languages to build things of actual value, not just to show off to others how intelligent we are.
The video was more my critique on Rust as an end-user, not a programmer. But I can make a video critiquing methods and syntax and whatnot if you would like, I just didn't think it would be entertaining.
Good take, luckily Rust is dying, so it will not be an issue for the future, just like most of these new programming languages, unfortunately python seems to survive and even prosper (thanks to all the "data scientists" that can't program but get paid like engineers to do "something" in python), my bet is that once AI will fully transfer to C++, python will slowly decline.
I'm a C programmer of multiple decades, and not a huge fan of Rust (syntax, community, political BS). But your arguments kinda suck. I think @otos648 covered most of it already. Mainly your arguments are in fact elitest, while simultaneously getting everything wrong. Firstly, the tooling is in fact the best part about the Rust, having a build tool and package manager builtin is killer. Secondly Rust is *incredibly* more complex than C. The entire C spec can be explained in a tiny book like K&R C. In terms of complexity, Rust is more comparable to C++. And thirdly we've got years of data of the smartest people writing C and still screwing it up, so the git gud argument just doesn't hold up.
I do respect you for keeping negative comments up though. It's hard to say anything about any language without the nerds of the internet descending on you like locusts.
I value simplicity over complexity. After all, "simplicity is the ultimate sophistication" as some may say (which I agree with).
@@swindlesmccoop a gun without safety, is def simpler... but its not for no reason there on guns..
It sounded more like "C is harder than Rust" which for any industrial size project is true... but also not an argument against Rust.
"You have to be a little bit smarter to use C and understand it"
As someone with a heavy C/C++ background, who now fully transitioned to Rust for all new native projects, I can tell you that you need to be a little bit smarter to understand that you will never win against segfaults in C and C++ and choosing Rust to avoid those problems is a wise humility, and assuming you will one day be that good in C or C++ to never make a segfault is an arrogant stupidity.
Today I dealt with a segfault and manually debugged it. Turns out var size that I was using was a bit off. Redid the math needed to set it. That allowed me to finish writing my AUR helper written in C that is faster than Paru which is written in Rust. Problem is that Rust users are too lazy to optimize and use memory safety as a cope/crutch.
@@swindlesmccoop so you manually debugged it. I used too when I used C/C++. I no longer do in Rust. What happens if this error is in production and brings down thousands of servers to a standstill? You'll just insist "let me manually debug those" on the client site? You obviously lack professional experience to have decent insights into the problem.
I said in the video that by no means am I a professional programmer and that the critique comes from the perspective of a hobbyist
@@swindlesmccoop Yeah, I get it, well in professional space you'd realise why people prefer Rust real quick.
If you look at the thumbnail of the video and expect me to be a professional, I would question your thought process.
I honestly don't care about what language is used to make a program. I'm not a programmer, and most languages are not that much slower than c (except python).
Well this is just not true. It is true that a lot of other languages are ”fast enough” for the tasks a large portion of programmera perform, but a whole lot of popular languages are not on par with c. TS/JS/Java/Go to name a few other popular ones. The point is using the right tool for the task. If you’re writing cloud services Rust is probably a good choice. If you’re writing a web app its probably a bad choice.
id give em like 3 more momths before they start farming in a field somewhere and shilling cryptocurrency
I've been farming for a while, and I am starting to get into Monero...
Thanks for saving me the time. Sounds like just another bloatfest.
C it is.
You are my favorite meme channel.
Cringe rust fanboy
@@r2com641 I personally prefer C because it is easier.
You hate rust tools, not the language
I hate the implementation more than the language itself. I've gotten enough comments about it, so I'll make a video about the language itself.
Reasons I hate Rust:
1. Their SJW Code of Conduct
2. It's constantly shoved into my face and propagandized. The more they do it, the more I double down on refusing to use Rust.
3. No support for dynamic linking libraries. (I hate this about Go too)
4. It's not C++. Seriously, if you intend to compile your code into native binary, C and C++ (and maybe Assembly) are all you need. All attempts to replace those two are utterly fruitless. It's never gonna happen.
5. The whole memory-safety thing is not as big as Rust-lovers think it is. Modern C++ has smart pointers - if you use those instead of regular raw pointers, you won't be leaking any memory.
*panic!("Out of memory!");*
Here's your memory safety bro
It's the same people who refuse to use Odysee because the views of the creators don't perfectly align with theirs
@@SomeRandomPiggo The thing is tho, I don't really need Rust, when I already have C++.
Plus, the last thing I need is to have people disallow me from using their code just because I believe there are only two genders, or something like that.
@@StephanusTavilrond Exactly, it's filling a void Go should have. Also like you said the community surrounding it is very politically biased
@@SomeRandomPiggo Eh, only kind of. I mirror my stuff to Odysee, though I'm sure most people are content with UA-cam. I don't like either companies' policies, however, UA-cam is and will always be the best platform for uploading videos and gaining an audience. A year ago, I never could have expected having nearly 1,000 subscribers, but we're at like 870-something and I'm really happy to see people enjoy my content, even if it's on a platform I disagree with.
the rust community will end up turning cargo into a new npm lol.
Go should be more popular for what most people want to do, but rust has this appeal to people that have no need for it and I think C/C++ devs are the only ones that can have valid criticisms of rust since they actually deal with memory issues.
>will end up
In all honestly, what's the difference? They perform all the same functions and they are both required for the installation of many programs.
@swindlesmccoop npm has a lot of abandoned projects that weren't taken seriously besides being a resume builder. So I guess the difference would be quality. This can happen with any modern language, but rust's difficulty and lack of job positions keep it moderated
I like it
Liked your video. Let somebody comment on my comment because I liked your video.
The argument for my sophisticated point starts with "your mom", quickly moves to "not bussin", and ends with "no cap". I look forward to your retort.
So, Rust is a bad language, because it's easier to use than C? How does that make any sense? As long as ease of use doesn't come at the cost of performance it a good thing. The fact that you like a language like C more simply because it's harder to use says a lot about your elitism.
The binary doesn't have to be big, there are settings that make it smaller
Even though there are settings to make the binary smaller, they still cannot be optimized to the level of C
@@swindlesmccoop Why not? Have you tested that? In principle, there is nothing in rust stopping it from being just as small as C, since there is no garbage collector. If it is actually true that Rust doesn't get as small as C, then that's an issue that can be improved upon, not a language limitation.
These are not critiques of the programming language, but critiques of what its like to build all of your pc applications from source.
Excellent parody of an ignoramus critiquing a programming language. Pretty much every point made here is exaggerated or down right wrong.
Large binaries - nope. I run Rust programs on tiny micro-controllers with only Kb of memory-
Slow - nope. Rust programs can easily mach the speed of C and C++.
Downloading crates slow - nope. Heck out in the forrest here in Finland my internet connection hardly ever hits 5MB per second. Downloading dependencies has not been a hold up.
Reliance on dependencies - nope. Use them if you like. Write everything yourself if you like. Just like C and C++.
Rust "community" - Actually I also don't like the word "community" being used to identify people who just happen to be users of the same thing. But I have found those users to be very skilled and very helpful. No problem there.
Most Rust code ends up being wrapped in "unsafe" there fore Rust's memory safety checks are useless - nope. Not true. Application code need never have "unsafe" in it. Lower level code that does I/O or FFI or really needs some sneaky optimisations that are impossible for the compiler to check, sure that gets wrapped un "unsafe" blocks. A very small fraction of the source code. A very good indicator of where programmers need to take extra care. Unlike C or C++ where everything is unsafe all the time.
Rewriting everything in Rust - nope. pretty much all the serious Rust users I interact with would never say that. They are not stupid. They know full well that rewriting stuff because "Ooo, look new language" is ridiculous.
I could go on but it's tiring...
I love the C language for its simplicity. I loath C++ for its ever growing complexity that never fixes the serious problems it inherits from C. I love Rust for its cleaned up C style syntax and vastly improved type system. It's provision of better high-level language features whilst retaining the ability to do anything that C can and avoiding the chaos that its C++. Ensuring safety on memory use is a huge bonus.
weeb rants about how the new femboy langauge is too fancy for him
I would pin this, but I think "Weeb cringe" sums it up more succinctly
i see, rust is very good.
Nim lang is better. CMM
Nim should be the language of noobs instead of Python but languages for production should be way less bloat
@@charlubermensch2395 I think that people that wish to learn programming should learn with Lua or Go instead. They're both pretty portable and easy to learn, but the first one is more suited for games (and modding) and small stuff, the second one for system programming (not kernel/metal level tho).
Then going into other territories (C, LISP, Forth, PostScript, Oberon, ecc) might be a good choice.
Still, learning many languages is useless if you don't know what to do with 'em, what to write or which problem to solve.
- significant spaces
- no tabs
- case insensitive
- exceptions that unlike in C++ cannot be disabled
- garbage collection
- slow (needs special danger mode to even be comparble to C)
I'm gonna pass this one.
@@patryk_49 Apart from garbage collection (which is not a bad thing per se), I didn't know that Nim was this cursed.
@@patryk_49 > case insensitive
lmfao wtf
Go ftw.
No! Get into why you don't like Go! Go is trash and it's uncritical praise have been going for too long!
That is a stupid take, sorry, calling Rust devs dumber. It is obvious that you are young. I think it is quite the opposite. You have to have some wisdom and experience to admit that even the best C devs in the world make stupid mistakes that only later get recognized, because Compiler. And I guess it is probably a very fair bet that John Carmack is a way better programmer than you. C is OVER-used. Clear so far? And as long the standard commitee does not get up their butts and define a well-practical implementation-defined behavior for every undefined behavior C will stay the hell it is right now. Speaking of cargo: Hey, instead of one bad package manager you can have 10 or more using C/ C++ that are even more worse. What an approach! Conan anyone? I have never seen a single repository that is buildable from scratch using that crap. Let' s not have TOML alone, lets add Perl, make (the language), CMake (which version?) to the mix. Do you really believe this is better? Hell no! Back to your take: As one has said in a movie it seems to be true about young men : "Young men are a disappointment. When they turn 35 they start to get bearable."
I can respect that you like to have your whole system crash when less than 3 lines of C code haven't been written by someone with 20+ years of experience, but don't promote your religion, you're welcome.
Is there a reason for the trans flag in the thumbnail?
I wanted to show my support for the community
@@anon8510True but I am not a frogposter
c is like walking. do it for leisure, but if you want to be productive, drive a car (rust). a good example of this is TOR. they were practically stunted from adding new features like allowing UDP connections, bc it was written in c, so they built a new version entirely in rust and they're loving how productive it has made them
btw this guy has never ran `cargo new`. He has never written rust a single line of Rust, not even a hello world example. He watched Rust somewhere and made this video. I genuinely thought this was a bait video, but it's too bad to be one. If you're reading this and haven't finished the video, step back, you're taking opinions from someone who hasn't even installed Rust.
Lmfao cope and seethe. You literally cannot offer any counterpoints because you know what I'm saying is 100% true. I actually have written multiple programs in Rust, and guess what? It sucked. The type system was complete cringe, the syntax is ugly, compile times took way longer than C, lackluster standard library - I can go on.
"I believe that you're way out of your depth in this matter. So, the next time that you want to come in here and tell me what I'm doing wrong, you are welcome to keep it to yourself. Because I don't care.
sir you are just making a bunch of shell script and some arduino. stop browsing /g/ too much.
I've got to say, from what you said, you love C and you hate using libraries, that I'm not surprised you don't like Rust. Heck, I don't think with that view on code that you would like pretty much any other language.
I can say though, if you really do like C that much and prefer to code mostly everything yourself whole using minimal libraries, you can't be coding a hack of a lot. You would have to build a lot to make up for not wanting to use libraries and then your code would be fairly hardware specific, which means tonnes of extra coding if your software is going to work on multiple platforms.
C has been great, but it was designed in a different era, the the limitations of that era is indelibly stamped on the language. By far, a huge portion of security flaws most major software's, including OSs, have are due to memory mismanagement. To be completely honest, I've always disliked C I'mmensley. To me, it was the language you used when a gun was put against your head. This is because it demanded so much wasted effort. It was horrid with repetitiveness and exacting specifics. Good lord, header files. Ya, I know other languages have them, but what a waste they are. My opinion I know.
No, the thing I really couldn't stand about C is how it feels like your taking care of a baby the whole time. Every step of the way, you are exerting far more effort baby proofing the code, putting up barriers and passing to make sure your program can't hurt itself, than you do kn the actually functionality of the code. If you don't, well, again, a vast amount of security flaws come out of a lack of proper baby proofing. So, the concept of a safety first before extreme control doesn't sound so bad.
Also, I just have to say. For someone who claims to not like to use libraries cause they like to code so much themselves, you complained a lot about libraries.
Also, package managers, especially open source ones, tend to have multiple of everything. So, ya, maybe the library you used was bloated. So, did you check others? Probably there is one out there that is tighter and leaner.
To add to all this, some of what you said doesn't add up. You made claims about the code using more memory and such. What are the specifics of the claim? More memory that C? I don't think they've claimed to be leaner or faster than C in general, just close to it.
I have a hard time believing it's as far off C as you make is sound like. I mean, if you can get Rust working in embedded environments like Arduinos and ESP32, it would have to run pretty lean. Heck, they're working on bare metal versions for various embedded hardware.
I have to admit, I managed to load some on one of mine. Yes, the libraries I needed took a while to download, but I can assure you that they weren't all loaded into that tiny space.
So, ya, no hate from here. If you like C, go for it. Again, I don't see you liking much else, as liking C usually only happens to those who want to be very close to the machine. Still, it's probably best to just admit you prefer C because you like it more that to mainly make excuses for why you think another language is bad. Come on, what does your view of the community of programmer using a language have to do with the language itself? That's not criticism, it's an excuse.
My gripes with importing lots of unnecessary libraries extends to languages such as JavaScript, Go, and Python as well, so you're right about that point. But the biggest culprit of this seems to be Rust users.
When it comes to making code cross-platform, it's not really that important to me because I'm not often trying to use hardware-specific functions (I would write in Assembly if so) but moreso things that are specific to the operating system. So my code is usually able to be compiled natively on both OpenBSD and Linux with minimal to no patching necessary.
Eventually you stop needing to worry about "baby-proofing" in C because when you think of the code you are writing, you naturally write it to be safe.
I complained about libraries because the Rust users seem to like them a lot. I wrote a few things in Rust and didn't use any libraries or anything and the whole process was okay. The problem more lies in programs I would download from the internet that would do what I described, not me feeling as though I need to.
I've communicated with Rust users that have claimed to have faster and leaner code than C. Maybe my sample size caused bias in the response, but out of all of the people I've talked to that use Rust, most of them made this claim. I'm not saying it *can't* be lean because I know that you can write good software in Rust - the problem is that people really just don't seem to care about optimizations or anything like that. So even in the "rewrites," the binaries are larger and there is a larger memory footprint.
The Rust community being cringe was only one of my points, and it would be inaccurate to say that was the point of my argument. It was only one part and I'm pretty sure I even said in the video that it doesn't really have much to do with the language. But I will stand by that point, I don't really enjoy talking to Rust programmers. C programmers sometimes are a bit toxic online, but not in the same way. A lot of time it's that Rust programmers want you to think the same way as the way that they are thinking, meanwhile C programmers are frustrated that you aren't coming up with the solution on your own and reading every word of every man page.
@@swindlesmccoop I get it. I've seen code squeeze out every ounce of efficiency by using bit shifting to simulate math functions because it save hundreds of clock cycles per vector calculation in a 3d engine before the days of accelerated video cards. I had a friend who was an insanely good programmer make a 30 second video file fit in a very small amount or space. Of course, I also saw the garbage results it displayed when run in 16bit graphics instead of the 15 bit graphics he and our school used.
Suffice to say, efficiency can be made or lost anywhere and there are tradeoffs.
I was merely pointing out your comparison of Rust to C was unbalanced. You were comparing Rusts worst aspects to C/C++'s best aspects. It's an unfair comparison.
C and C++ files can be extremely small for a number of reasons which likely have to do with compuler options. Facebook famously made a 1.5GB executable in C++. Can I point at that and say JavaScript is better because I could make a Facebook clone using far less space?
C executables change size based on how libraries are linked. Also, C code on linux, or other operating systems, can be small because they can take advantage of shell scripts and other executables to handle a lot of functionality for them. So, if another language is doing a similar task but handling all the functionality itself rather than outsourcing functionality to other programs, it's not a fair comparison.
Now, you may argue that not taking advantage of other executables is not an excuse, because they shouldn't duplicate functionality. Except, Rust isn't just targeting Operating systems. There are bare metal versions of itself for embedded environments where there is no operating system. There are also WebAssemblies, where certain functionality doesn't exist.
When you used the library to build a CLI programs was it just a program that interacted with the CLI that already exists, or was it one that made its own CLI and then interacted with that?
I've seen a video on a rust experiment to build a functioning CLI in a web browser as what was displayed as the web page.
So, air guess what I'm saying is, is that your comparison came across as fairly shallow and imbalanced. The executable was bigger. Did you explore compiler options that could reduce the size? Were you using a library that replaced the functionality that your code outsourced to other programs? How many libraries with similar functionality did you explore? Did you find the best one?
Linux has many shells to choose from. Linux has a packaging system full of programs that duplicate functionality. The library systems of coding today were born from the linux packaging systems. There could be several libraries doing the same thing, did you explore them much to find one that met your needs more?
C has had decades to have its libraries refined, some parts actually mathematically proven to be the most efficient it can be.
So, no, I found your language to language comparison not to be to a standard I would find useful. It comes across that you really didn't spend that much time with Rust and had preconceived notions about it. That you explored until you found enough things that met your preconceived notions to satisfy your position and you stopped there. Then you basically made a video comparing the best C has to offer against the worst of what Rust has to offer that one can find in a short period of time.
I won't bother getting back into the community issue. It's so entirely rediculous to use a community against a language that it's almost hilarious. Every programming community has a whole assortment of various types of people. From the very detail orientated highly efficient to the more free and less efficient. I'm sure if you just spent a little time looking, you would find some messaging board or discord server full of programmers squeezing every ounce of efficiency out of Rust.
Heck, go look at the embedded side of things where they are hard at work building baremetal Rust code for embedded hardware like Arduinos and ESP32.
Language you use when a gun is put against your head: to me that's Python and Javascript :D
Rust is going into the Linux Kernel. Just sayin
I haven't used Linux for some 8 months now. Not an issue for me. But maybe more people will be motivated to make the switch now.
@@swindlesmccoop Majority of companies use Linux. They’re putting it into their CLIs.
as an experiment
@@jameskingcodes google is implementing it as well. Multiple large companies paying for such an experiment. Not really something to just dismiss . Google has been wanting to replace C. Look at Cobalt.
@@martinvera4720 companies do experiments all the time. Rust shows promise but it isnt a C++ killer (yet)
the idea of bloat is cringe
It doesnt do garbage collection... it just leaves the garbage all over the place. 😛
dude. You're literally the only one with these problems. I think its just a skill issue with you.
Embarrassing pfp. Only to be expected of a rust user.
Rust is python with 1000X the ego. and python ego is over sized.
If you don't like bloat you like rust !
Else you don't know what you are talking about
No, I don't think *you* know what you're talking about.
@@swindlesmccoop
Proves you don't even know 1single feature of rust.
It marks unused code as warning (by default) what is more anti-bloat ? JS 🤣 ?
Just check out a few rust developers and know who hates bloat most !
@@khanra17 It has nothing to do with unused code. So many Rust developers either:
A. Use way too many libraries to accomplish single tasks
or B. Add so many features to their programs that the codebase becomes huge and it violates the philosophy of "Do one thing, and do it well:
@@swindlesmccoop using libraries in rust isn't as bloated as other languages because even if the library does multiple things, the library has feature flags so you simply turn on only the features you use, and thus only that code gets included when you compile. in big projects it can in fact end up less bloated than c bc in c you would write overly verbose unoptimized functions, while in rust you get highly optimized implementations. this also means when you write c, you are not really "doing one thing and doing it well" because your hashset implementation is already one thing more than the one thing you intended to write the program to do, and its also not doing the hashset well
@@swindlesmccoop
Because rust didn't put everything in one binary you are calling it bloat.
Learn the quote where it's used most_
FYI systemd is called bloat because it doesn't follow the philosophy and put everything in one binary!
You are contradicting your own opinion 🫥