Rust
-
just because they are accepting of people based on gender identity doesn't mean toxicity cannot exist.
terfs are a great example of that.
Sure, but I'm saying in general. I don't know why you're so convinced of your position from the one experience you had.
-
not a big fan of rust personally. I think it would be much smarter to bring borrow checking to C through annotations. That way we would not have to rewrite the whole world
While I agree that would solve much of the motivation behind rewriting in rust, I don't think it would bring many of the rust-enthusiasts over to C. For me at least, the killer feature of rust is having a modern tooling and language with proper library management, functional stuff in the language and one language standard everyone agrees upon.
-
While I agree that would solve much of the motivation behind rewriting in rust, I don't think it would bring many of the rust-enthusiasts over to C. For me at least, the killer feature of rust is having a modern tooling and language with proper library management, functional stuff in the language and one language standard everyone agrees upon.
I don't think it's about bringing rust enthusiasts to C, it's about the fastest way to bring more safety to the entire ecosystem.
I'm not convinced it's possible with just annotations, mind.
-
This post did not contain any content.
Considering that FFI is very much a thing, I'm finding it difficulty to understand the point it's trying to make.
-
I don't think it's about bringing rust enthusiasts to C, it's about the fastest way to bring more safety to the entire ecosystem.
I'm not convinced it's possible with just annotations, mind.
It is possible, it would bring in quite a few restrictions though. The bigger problem I see is that it wouldn't be entirely clear as an end user whether a program is memory safe or not. However, this isn't the case with rust neither. Maybe some kind of certification would help
-
While I agree that would solve much of the motivation behind rewriting in rust, I don't think it would bring many of the rust-enthusiasts over to C. For me at least, the killer feature of rust is having a modern tooling and language with proper library management, functional stuff in the language and one language standard everyone agrees upon.
Yeah, I don't think there's anything wrong with coding in rust for people who like it. But I do think it's quite a bit of useless work that could be spent more wisely on new products instead of rewriting things that we already have
-
It certainly is a pillar of my mental stability.
Ah, me a pillar of my insanity.
-
not a big fan of rust personally. I think it would be much smarter to bring borrow checking to C through annotations. That way we would not have to rewrite the whole world
C++ already has much more of the required language constructs, which is why there is already an attempt to add borrow checking to C++ called circle. Until that standardizes, I wouldn't expect it in C.
-
And Eiffel is in a different plane of existence entirely
-
Rust is actually awesome in many ways. No always the right solution, but nice to have in your toolbox.
Where would you say Rust isn't the right solution?
We always hear how great Rust is, but I'd be curious to know where it isn't.
-
not a big fan of rust personally. I think it would be much smarter to bring borrow checking to C through annotations. That way we would not have to rewrite the whole world
wrote last edited by [email protected]I don't think you would get much traction on C developers' existing projects. C gives you the option to do everything your way. If the developer's paradigm doesn't agree with the borrow checker, it could become a rewrite anyway.
Most projects don't use the newer c standards. The language just doesn't change much, and C devs like that. This might get a better response from the modern C++ crowd, but then you are missing a large chunk of the world.
-
not a big fan of rust personally. I think it would be much smarter to bring borrow checking to C through annotations. That way we would not have to rewrite the whole world
wrote last edited by [email protected]I struggle to learn rust because the semantics and syntax are just so awful. I would love to be enthusiastic about rust, since every seems to love it, but I can't get over that hurdle. Backporting the features into C, or even just making a transpiler from C to rust that uses annotations would be great for me. But the rust community really does not seem interested in making stepping stones from other languages to rust.
-
I struggle to learn rust because the semantics and syntax are just so awful. I would love to be enthusiastic about rust, since every seems to love it, but I can't get over that hurdle. Backporting the features into C, or even just making a transpiler from C to rust that uses annotations would be great for me. But the rust community really does not seem interested in making stepping stones from other languages to rust.
I learned a bit of rust and I think it's just about getting used to it. It's fairly subjective, and people say the same about C++. I also prefer the C syntax because I find it's simplicity extremely elegant and prefer it to have fewer features. And I like it for it's consistency, on linux the FHS is based up on C, and it just somewhat feels ugly to break that consistency.
But I also acknowledge the advantages of rust.
-
Where would you say Rust isn't the right solution?
We always hear how great Rust is, but I'd be curious to know where it isn't.
Never used Rust but I'd like to point out the YouTube channel Low Level which covers security vulnerabilities (CVEs). He ends each video with "would Rust have fixed this?" and it's pretty interesting.
A very recent one is this: https://youtu.be/BTjj1ILCwRs?t=10m (timestamped to the relevant section)
According to him, when writing embedded software in Rust (and UEFI is embedded), you have to use Rust in unsafe mode which basically disables all the memory safety features. So in that kind of environment Rust isn't really better than C, at least when it comes to memory safety.
That's not to say Rust isn't still a good option. It probably is.
Again, I never used Rust so I'm just parroting stuff I've heard, take all of this with a grain of salt.
-
Hey now, about 1% of the Linux kernel is Rust now!
NT kernel also includes Rust.
-
NT kernel also includes Rust.
Oh really? I had no idea Microsoft was doing rust at all
-
Where would you say Rust isn't the right solution?
We always hear how great Rust is, but I'd be curious to know where it isn't.
Rust provides safety and protection.
Rust isn't as rapid as other options, has less library support, and porting existing code is relatively difficult.
IMO because of the workarounds you need to do to handle the memory safety, you end up with a lot more hard to solve bugs than you do with conventional languages. It should be noted however that the bugs don't end up being security vulnerabilities like they do in conventional systems.
If you have something that needs to be structurally sound and/or you have enough talented people willing to work on it, it's a great option. If it needs to be fast and cheap and you don't have a gaggle of rust developers on hand and it's already written in another language, it might not be the best solution.
-
I struggle to learn rust because the semantics and syntax are just so awful. I would love to be enthusiastic about rust, since every seems to love it, but I can't get over that hurdle. Backporting the features into C, or even just making a transpiler from C to rust that uses annotations would be great for me. But the rust community really does not seem interested in making stepping stones from other languages to rust.
I've personally become pretty fond of the syntax and incorporation of FP features. In all fairness though, I haven't written much C or C++ for the last two decades.
Rust incorporates some of my favorite features from FP with handy green thread ergonomics. I'm not a fan of Go, so this gives me a great option for microservices when I can avoid Node.js.
-
Rust provides safety and protection.
Rust isn't as rapid as other options, has less library support, and porting existing code is relatively difficult.
IMO because of the workarounds you need to do to handle the memory safety, you end up with a lot more hard to solve bugs than you do with conventional languages. It should be noted however that the bugs don't end up being security vulnerabilities like they do in conventional systems.
If you have something that needs to be structurally sound and/or you have enough talented people willing to work on it, it's a great option. If it needs to be fast and cheap and you don't have a gaggle of rust developers on hand and it's already written in another language, it might not be the best solution.
@rumba @Croquette They're is a lot of people scrambling to rewrite existing c projects in rust for what?
for example ffmpegs rust rewrite is slower than the c version we need more maintainers rather than creating new rust alternatives that have no purpose -
I get the meme (though why was this single unstable point - imagemagick in the original xkcd - removed? To make the left side seem more stable clmpared to the original idea?), it might be trueish atm.
But with rust I feel that a lot of projects that are rewritten in rust are quicker arriving at a "finished" (or almost finished) state where they are more or less just tools being used without much discussion anymore. I guess a lot of commonly used tools already use Rust in some way, but i rarely is an issue which makes this discussion-worthy or generates enough conflict in order to raise awareness outside.I have a hunch that open-source rust-devopment is less of a hassle as a lot of discussion about code or the quality therof is simply avoided by a stricter compiler. If the code committed compiles with rustc there's less possibility of it breaking other things in the codebase or containing hidden dangers that need to be discussed. Overall less friction, less overhead and distruction from the actual coding.
Old programs everyone agrees do exactly what they should are a perfect target for "black box" porting to a new language, where the only criteria for success are "it should function exactly like before, just more efficiently, while being more maintainable"