Ez, feature bloat the project so all those dependancies are actively used
At least there’s tree shaking. Not everything is getting in the final build
My only dependency is libstdc++
Fight me
stdc is just bloat, i implement the methods and do the syscalls myself if i need them
C is bloat, thats why everyone should use Asm
Pff, I prefer good ol’ flip switches, like on my trusty Altair.
Noob. I prefer to use a screwdriver to poke around the CPU and memory lanes
I use butterflies
I find it especially weird that it’s almost always labeled like something special if it’s written in Rust, even though as the end user the only thing I know will be different is the compile time, as it usually takes around 10-20 times longer than if it would be written in c, with 500 dependencies being pulled and recompiled every time. Which means if tests fail, even though the app works fine, and I had that happen twice in Rust, it will take three tries or so until I manage to fully remove the test section from the pkgbuild, resulting in an hour loss for just installing something that could’ve taken 5 minutes.
> Decide to create a very basic GUI app in Rust, as everyone is saying it’s a great language for it
> First compilation takes over 15 minutes to download and compile 100 libraries
> Debug files take up 2GB of storage
> Output binary file comes out massive for no reason
> “Yeah you’re supposed to write a few lines to optimize for size in your release profile”
> Compiling now takes 30 minutes instead
Reimplements in C
Compiles in 5 Minutes (you accidentally did it on the RPi Zero W, on a PC it’s done in 30 secs)
Reimplements in C
Segmentation fault (core dumped)
Reimplements in C
Segmentation fault (core dumped)
change code so it no longer segfaults
still is UB, has arbitrary code execution vulnerability
everybody dies
You seem to be a rather specific user, if the compile time is something you notice, let alone the only thing…
It’s just weirdly noticeable when one rust program with ~150 lines of code, designed to connect to a specific device and send commands according to the intensity of music, takes longer to compile than updating a typical Arch testing setup after a month without maintenance, including the (non Rust) AUR packages.
Well, I’m not here to claim that Rust’s compile times aren’t comparatively long, especially for non-incremental builds. It’s a trade-off that was chosen to not need a runtime environment, nor be as simplistic/footgun as C.
What I’m saying is that this trade-off was chosen and continues to be popular, because the vast majority of users will never notice (nor will programmers really, as they have incremental builds).
Maybe you can download the fully built package from somewhere? Maybe Arch can package it in the proper repos?
Yeah, I’ve given up trying to know all the libraries in my projects. I feel like the added development speed and code quality is just so good that not taking the risk of a supply chain attack is basically not an option.
I do try to primarily use libraries from the Rust team or from more widely known devs (and hope that they also do that), but most projects worth doing will need one or two specialty libraries where all bets and bus factors are off…
You think your code is higher quality with more dependencies? All you’re doing is offloading complexity to a separate project.
If you make a program that does “something worth doing”, but you need some specialty library to actually do it (which you didn’t implement yourself), than sorry, but it wasn’t you who did it.
Yes, offloading complexity to a separate project which has already invested more time into code quality than I could possibly justify.
As for your second point, I don’t care who solved the problem. If you care, I hope you’re smelting your own sand to build your own CPU and assembly language. But I’m obviously also not solving the exact same problem as the library already solved.
Why are you looking for conflict?
My problem was with the first line of your comment:
Yeah, I’ve given up trying to know all the libraries in my projects.
This leads me to assume that you don’t actually know that those dependencies are as well maintained as you claim.
Obviously dependencies are important and make sense to use in many cases, but using trivial dependencies to speed up development isn’t good.
As for your second point, I don’t care who solved the problem. If you care, I hope you’re smelting your own sand to build your own CPU and assembly language. But I’m obviously also not solving the exact same problem as the library already solved.
I was just saying it isn’t you who solved the problem in that case, really, as the hard work was done for you. Honestly though, it was pointless and rude so I apologise.
Apology taken.
This leads me to assume that you don’t actually know that those dependencies are as well maintained as you claim.
Well, I can’t guarantee that none of them are buggy, unmaintained etc… But that’s why I prefixed that sentence with “I feel”.
On average, it seems to me like the code quality is a good bit higher than I’m able to produce under money/time constraints.In particular, even the worst libraries tend to be not as bad as they may be in many other languages, because Rust’s strict type system + compiler enforces quite a bit of correctness on its own.
Well, and the good libraries are just obsessed with correctness and performance, so they drag code quality upwards, even if they introduce a mild risk of a transitive dependency being a dud…
