Rust (the language) hate thread

[Creative Username]

imagine being so goon brained that you need to erp with your compiler toolchain

 

[jorkingmyshi]

Rust is fast.
Rust is life.

Profile picture checks out.

 

[;_;7]

90% of Rust hate would go away if its proponents stopped pretending it was a revolution and instead treated it as what it is: a better C++. Not going on about gender for hours would also help.

 

[Creative Username]

90% of Rust hate would go away if its proponents stopped pretending it was a revolution and instead treated it as what it is: a better C++. Not going on about gender for hours would also help.

also delete cargo
if cargo wasn't a thing and rust didn't try to take over the responsibilities of the system package manager i would be a hardcore rust shill

 

[;_;7]

also delete cargo
if cargo wasn't a thing and rust didn't try to take over the responsibilities of the system package manager i would be a hardcore rust shill

Do people use it to install packages system-wide? I only use it to build and install project dependencies. It's sure better than CMake.

 

[Creative Username]

Do people use it to install packages system-wide? I only use it to build and install project dependencies. It's sure better than CMake.

installing libraries is what the system package manager is supposed to do and cargo's bullshit creates hell for packagers who want to split things up effectively

 

[;_;7]

installing libraries is what the system package manager is supposed to do and cargo's bullshit creates hell for packagers who want to split things up effectively

In practice, relying on the system package manager to install libraries creates hell for software maintainers. It's very difficult to make sure your users across Windows, Mac, and all the different Linux distros you want to support can get the same version of a specific library. I usually give up when trying to do that in C++ and just vendor everything.

 

[Creative Username]

In practice, relying on the system package manager to install libraries creates hell for software maintainers. It's very difficult to make sure your users across Windows, Mac, and all the different Linux distros you want to support can get the same version of a specific library. I usually give up when trying to do that in C++ and just vendor everything.

here's the idea: you make a static version for windows and mac since those operating systems suck and can't have nice things
and you also make a static version for people who use linux who probably shouldn't be (or are just feeling like being sloppy)
for white people you just throw your source tarball (no vendoring) into the wind and they will make their own packages or install it in /usr/local or do whatever the fuck they want with it
eventually debian and derivates package your software and you can rest easy knowing your software can be installed in a compatible manner without the niggerlicious retarded bullshit you endorse

in an ideal world you would never even make the builds yourself because people can do the ./configure make make install by themselves, can't they?

 

[;_;7]

here's the idea: you make a static version for windows and mac since those operating systems suck and can't have nice things
and you also make a static version for people who use linux who probably shouldn't be (or are just feeling like being sloppy)
for white people you just throw your source tarball (no vendoring) into the wind and they will make their own packages or install it in /usr/local or do whatever the fuck they want with it
eventually debian and derivates package your software and you can rest easy knowing your software can be installed in a compatible manner without the niggerlicious retarded bullshit you endorse

in an ideal world you would never even make the builds yourself because people can do the ./configure make make install by themselves, can't they?

I wish I had the privilege of doing this. Unfortunately, the real world makes all-in-one solutions like Cargo very appealing.

 

[TooManyKittens]

I wish I had the privilege of doing this. Unfortunately, the real world makes all-in-one solutions like Cargo very appealing.

This sort of thinking is how you get bullshit like docker in docker with a hellatious AWS install (and Bill) because some fucker said it was all in one and appealing.

Cargo isn't the only sin these days but it's in my fucking 10 commandments list (ok. Maybe 20. Google has a fucklot to answer for)

 

[Creative Username]

This sort of thinking is how you get bullshit like docker in docker with a hellatious AWS install (and Bill) because some fucker said it was all in one and appealing.

this is way too polite for talking to a language package manager nigger. i'll do it properly, take notes:

I wish I had the privilege of doing this. Unfortunately, the real world makes all-in-one solutions like Cargo very appealing.

want to know why computers are so completely fucked, and they just keep getting worse? niggers like you are in the top 5. please stop using computers now, and maybe kill yourself too, so you can immediately start making the world a marginally better place by not shitting up computing with your niggerlicious bullshit

 

[Coolio55]

Just use nix.

 

[Creative Username]

Just use nix.

or guix if you really love parentheses

 

[;_;7]

this is way too polite for talking to a language package manager nigger. i'll do it properly, take notes:

want to know why computers are so completely fucked, and they just keep getting worse? niggers like you are in the top 5. please stop using computers now, and maybe kill yourself too, so you can immediately start making the world a marginally better place by not shitting up computing with your niggerlicious bullshit

Saar we love diversity of operating system, it is our strength.. we just need accept tools as smal price to pay for our diversity of OS saar

 

[;_;7]

Saar we love diversity of operating system, it is our strength.. we just need accept tools as smal price to pay for our diversity of OS saar

On a more serious note, there would be a lot of features I would take away from languages if I had a team of randoms using it and had a way to prevent retards from making worse alternatives. There are a lot of instances of developers choosing not to make first party tools and worse tools popping up as a result. My favorite example is Java, which I dealt with a lot early in my career. Ant, Maven, Gradle, all terrible, all splintered and incompatible. The fact that the language isn't even platform dependent and still has such massive build problems shows exactly why I prefer a common solution.

Many projects I build in C++ and Rust have no or almost no external dependencies and I usually vendor the ones I do. My goal is for the code to compile in 10 years. These projects are either solo, or a small team where we can all come to an agreement. Package managers matter much less in these scenarios, but the price for entry is having experienced devs who understand that code is a liability and longevity is important (so, developers with 10+ years experience who aren't primarily web developers). We usually only rely on the OS to provide large packages that are more closely tied to the system itself, such as OpenGL.

When it comes to dealing with random people who have varying levels of experience, a package manager becomes much more useful, and having a standardized one for the language becomes even more important. What I wish existed was built-in checks for maximum external dependencies and external dependency sizes. You should be yelling at people and telling them about all their external dependencies all the time. They should also always provide a self-hostable package proxy implementation so everyone can easily cache every package used in every project. That would prevent scary situations like upstream package registries going down or packages being removed. Basing package managers on centralized registries is insane and only Go seems to get it right out of the modern languages with package managers.

 

[Creative Username]

Many projects I build in C++ and Rust have no or almost no external dependencies and I usually vendor the ones I do. My goal is for the code to compile in 10 years. These projects are either solo, or a small team where we can all come to an agreement. Package managers matter much less in these scenarios, but the price for entry is having experienced devs who understand that code is a liability and longevity is important (so, developers with 10+ years experience who aren't primarily web developers). We usually only rely on the OS to provide large packages that are more closely tied to the system itself, such as OpenGL.

good! make sure to not vendor things like libpng, zlib, and openssl, though, as they are libraries so hallowed they basically count as part of the standard library and to vendor them would be disrespectful to the gods of dynamic linking

When it comes to dealing with random people who have varying levels of experience, a package manager becomes much more useful, and having a standardized one for the language becomes even more important. What I wish existed was built-in checks for maximum external dependencies and external dependency sizes. You should be yelling at people and telling them about all their external dependencies all the time.

maybe, or a tool that provides things like venv and all that for every language (see aforementioned nix) (actually really see it, it's very powerful and interesting)

They should also always provide a self-hostable package proxy implementation so everyone can easily cache every package used in every project.

this is called "thoroughly separate the language from its package manager so you can just tell the compiler to use random vendored dependencies"
since this just sounds like vendoring with extra steps

vendoring is the nuclear approach to dependency management, but it has some downsides and puts the responsibility on you for maintenance
a good library has very stable interfaces and simple linking so it never has to be vendored

 

[;_;7]

make sure to not vendor things like libpng, zlib, and openssl, though, as they are libraries so hallowed they basically count as part of the standard library and to vendor them would be disrespectful to the gods of dynamic linking

Never vendor OpenSSL unless you're also baking in your own CAs and have full control over what your application is talking to. Otherwise, you'll get fucked when a new CA is made or a new TLS version is released. Awful. Never vendor OpenSSL unless you know exactly what you're doing. The others I'll usually dynamically link, but they're less important.

this is called "thoroughly separate the language from its package manager so you can just tell the compiler to use random vendored dependencies"
since this just sounds like vendoring with extra steps

The difference is who's responsible for it, and versioning. Vendoring and external packages are very similar, but vendoring is explicitly taking responsibility, and external packages are outsourcing. You need to be very careful with both, however. Go does this pretty well by having built-in support for vendoring and its package registry system is just Git with a package proxy for better efficiency and availability. Rust seems to do OK on it, but the whole centralized crates registry is just learning the wrong lessons from NPM.

I forgot to mention, but package manager hell would be reduced significantly if these new languages would actually come up with ABIs and stick with them. Not even C++ did that. Now we just have to deal with all our libraries being source instead of linkable binaries. It makes build times unnecessarily long and binary sizes fat. We've learned so much as an industry about ABIs since the invention of the C ABI, but seemingly no one has bothered to put any of it to use. I'm sure we could even make generics work in a binary setting if we had clever header file formats, but apparently this is too much to ask.

 

[Creative Username]

Never vendor OpenSSL unless you're also baking in your own CAs and have full control over what your application is talking to. Otherwise, you'll get fucked when a new CA is made or a new TLS version is released. Awful. Never vendor OpenSSL unless you know exactly what you're doing. The others I'll usually dynamically link, but they're less important.

i think on many systems the CA certificates are a different package than openssl but yes

The difference is who's responsible for it, and versioning. Vendoring and external packages are very similar, but vendoring is explicitly taking responsibility, and external packages are outsourcing. You need to be very careful with both, however. Go does this pretty well by having built-in support for vendoring and its package registry system is just Git with a package proxy for better efficiency and availability. Rust seems to do OK on it, but the whole centralized crates registry is just learning the wrong lessons from NPM.

in all cases the language itself should be very permissive and not assume the programmer is using the package manager (i'm looking at you, subject of the thread)

I forgot to mention, but package manager hell would be reduced significantly if these new languages would actually come up with ABIs and stick with them. Not even C++ did that. Now we just have to deal with all our libraries being source instead of linkable binaries. It makes build times unnecessarily long and binary sizes fat. We've learned so much as an industry about ABIs since the invention of the C ABI, but seemingly no one has bothered to put any of it to use. I'm sure we could even make generics work in a binary setting if we had clever header file formats, but apparently this is too much to ask.

generics in stuff like c++ are so retarded and prevent good things from happening so much
they basically have the semantics of "ok duplicate this class 18 times but wait no fold it back into a void* thing"
things like generic containers would be nice if they were just void*s but safer or something
a full solution would not just be an abi, and i'm pretty sure it would need 2/3rds of the stuff java does for really advanced generics that aren't just things like container types

note: c++ compilers actually do follow standard name mangling abi conventions so you can do stuff like link a g++ library from clang and it will Just Work
certain dynamic languages can do ffi to c++ too
extra note: the "c abi" doesn't actually really exist, the standard for c doesn't say anything at all about calling conventions or symbol tables or the like

many nice c++ libraries exist that are dynamically linked, rust should learn from them

 

[;_;7]

i think on many systems the CA certificates are a different package than openssl but yes

You wouldn't believe the shit I've seen people do on accident because a library bundled OpenSSL and related CA code.

generics in stuff like c++ are so retarded and prevent good things from happening so much
they basically have the semantics of "ok duplicate this class 18 times but wait no fold it back into a void* thing"
things like generic containers would be nice if they were just void*s but safer or something
a full solution would not just be an abi, and i'm pretty sure it would need 2/3rds of the stuff java does for really advanced generics that aren't just things like container types

Java generics are just void* but with type checking. C++ templates are templates. Generics in Rust are C++ templates but properly typechecked. I prefer Rust generics to Java generics because I don't need to make everything a pointer. In Java, if you want to do a generic with a primitive type parameter, you have to box it in Integer, Boolean, etc. You chew through the heap because everything needs to be a pointer all the time. In C++ and Rust, copying makes sense. You can't really compile a template though, so you would need to either have it in the header or provide an interface for the Java-style void* generics, which I wouldn't mind.

note: c++ compilers actually do follow standard name mangling abi conventions so you can do stuff like link a g++ library from clang and it will Just Work
certain dynamic languages can do ffi to c++ too

Unfortunately, it doesn't always work out right and you end up with different versions for different compilers, like Boost does. It's still better than nothing, though.

extra note: the "c abi" doesn't actually really exist, the standard for c doesn't say anything at all about calling conventions or symbol tables or the like

Eh, we figured it out enough for it to be useful at least. I know there's some fuckery with int types and what have you, but at least it works fine in 99% of cases.

 

[Rusty Metal Skull Gun]

note: c++ compilers actually do follow standard name mangling abi conventions so you can do stuff like link a g++ library from clang and it will Just Work

A.k.a. the one good thing that Itanium brought to the world.

You can't really compile a template though, so you would need to either have it in the header or provide an interface for the Java-style void* generics, which I wouldn't mind.

C++ modules make it so you sort of can.