>git clone
>change code
>cargo run
coming from c++ this doesn't feel real
 Thalidomide Vintage Ad Shirt $22.14 |
 UFOs Are A Psyop Shirt $21.68 |
Thalidomide Vintage Ad Shirt $22.14 |
>git clone. >change code. >cargo run
>git clone
>change code
>cargo run
coming from c++ this doesn't feel real
Thalidomide Vintage Ad Shirt $22.14 |
UFOs Are A Psyop Shirt $21.68 |
Thalidomide Vintage Ad Shirt $22.14 |
>add library that does what you need
>cargo build
>calls cmake
>build fails
God I hate when this happens.
Mainly only happens on Windows or if I'm using NixOS.
The more you can rely on Rust-only libraries, the better.
Use version pinning and stop giving a shit.
>The more you can rely on Rust-only libraries, the better.
Based
>The more you can rely on Rust-only libraries
A literally spreading cancer
>cancer is when things work
did you think i jusr forgot about the code of conduct, an ideologically contract formulated by libarts deepstate trannies wrecking academia and science?
i mean this is the same people saying math is racist and whites need to be displaced and surrender their belongings
Frick off back to
who the frick said anything about muh politico muh pollyticks muh polyp muh pol? only the technology is being discussed here, if you want to be a woman who hates technology and loves le people issues you've got reddit and twitter for that
the code of conduct is literally part of rust
the COC is the payload, the rest of the project is merely the delivery mechanism
They were sure quick to jump down your throat. Now? Silence. The CoC should be mentioned in every Rust post.
thank you frens
Is it?
in fact cancer is when they work too much and show up where you don't want them
>accidently a backdoored package whoops
it's a seriously underestimated risk with code package managers. Unlike distro packages there's no concept of "maintainers" or testing before hitting the repo, just git tag a new release and boom your malicious code is on npm, pypi, crates, etc. I always run that shit in a container, at least that's some security.
>supply chain attacks never happen in distro pacakge managers
Are you living under a rock?
it's much more difficult. This took 2 years of subterfuge.
>it's much more difficult
Doesn't look like it. It happened before with ffmpeg and it happened now.
And it didn't make it out of testing repos before it was caught.
It didn't make it out because it got detected by accident, and not by a microsoft employee, not the distro maintainers.
Don't argue for the sake of arguing.
Holy cow we finally get one serious supply chain attack in a testing repo after 30 years and everyone flips out like Debian is as bad as NPM.
>testing before hitting the repo,
That's where the problem is. If the testers are compromised there's nobody preventing this.
The xz drama exposed it all.
and the same exact problem applies to soientific peer review
Welcome to the $CURRENT_CENTURY.
I wish Rust had a real competitor though. Let's hope Google doesn't kill Carbon.
C beats the shit out of rust, if you disagree it's a skill issue
I'm sure C beats the shit of of Rust in your fizzbuzz, I have no doubts.
Try serializing and deserializing some yaml using less than 10x as much code as the equivalent rust function.
#include <yaml.h> // written natively in C
So I did some digging to find out how libyaml is actually used within C programs. This page contains an example YAML parser using yaml.h. Turns out the end user of this header file has to write a lot of fricking boilerplate.
https://www.wpsoftware.net/andrew/pages/libyaml.html
In Rust, the process is much more straightforward because libraries like Serde can make use of derive macros to just... generate new functions at compile time that serialize/deserialize specific structs.
>if you use a library around a library we can make it take less code
I could write yaml_h_parser.h and then what?
This isn't python
The point is that C is a weaker language due to having weaker abstractions. You can't make a parser that is generic over all possible structs it could deserialize to. The C macro system doesn't understand types, and neither do runtime functions. The Rust macro system, however, does understand types. So you get to write something like this:
#[derive(Debug, PartialEq, Serialize, Deserialize)]
struct Point {
x: f64,
y: f64,
}
and a macro will read the struct definition at compile time as a stream of tokens, and generate functions serde_yaml::from_str and serde_yaml::to_string which will convert Yaml syntax to or from a Point object. The library writer doesn't need to know what data types you are using in your code. And you don't need to manually adapt the library to your code with a bunch of boilerplate.
And none of this makes compiled Rust executables any slower. It may make compilation take longer, but that's a pittance compared to writing the same shit over and over again with slight differences. C's not Python, but Rust ain't either. Rust gives you powerful abstractions that you can use in programs that will run as fast as C.
Okay, nocoder.
Not a fan of Rust but it sounds like you've never used either to any significant capacity
Makefiles and autoconf are a plague. Having the dependency and compilation tools built-in is a breath of fresh air.
rust code is 100% backdoored
Point to me where the backdoor is.
>
sorry that is against gender disclosure policy
welcome to the 21st century
>git clone
>sudo apt install libdep1 libdep2 -y
>cmake --build .
whats the problem again?
Your second line is different on different distros, and has problems when one of the deps requires a different version than something else on your system
Look at how to use it, it gives you tools to tediously write your own parser, same as any other C serialization library. C has no generic data structures like python, no runtime reflection like go, and no syntax-aware macros like rust, so it has no nice way to handle serialization. It was designed before people knew that was going to be a major thing languages would have to do, and it shows.
Also afaict, rust's way of handling serialization is unique in that it's the only nice way of doing it that has no performance penalty. C++ has convenient json libraries too, but they work more like python's, using dynamic data structures with runtime overhead because it's macros aren't powerful enough to handle it.
>Your second line is different on different distros, and has problems when one of the deps requires a different version than something else on your system
alright sure but realistically unless you are working on fizzbuzz any semi-large / real project, the acquiring and making dependencies work is like 0.1% of the total project dev time. Like at MOST even in c++ if you have to deal with a bunch of incompatible versions and non packaged libraries it takes 1-2 hours to set everything up, thats AT MOST. Usually it takes 5-15 mins.
Any real project takes hundreds or thousands of hours to bring to a somewhat working state.
People who cry about c/c++'s lack of dependency management systems are way over exaggerating how bad it is. I mean it didn't seem to prevent 95% of the whole industry from adopting the langs.
Let me know when async homosexualry is removed from all rust code.
i don't have any in my code