Which one of them provide full temporal memory safety?
How come Google is pouring incredible effort into mitigations rather than just fixing it all with existing static analysis? Here's this week's example: https://v8.dev/blog/retrofitting-temporal-memory-safety-on-c++
And why wouldn't it be? It's capable of anything just like C++. You will either learn it now that the ecosystem is still small or learn it when it inevitably turns into a gargantuan mature ecosystem because the trend isn't stopping tomorrow, that i can assure you.
it has sdl2 I guess
I mean they're trying which is kind of sad
You might start out with that and then find out half way its missing stuff
It doesn't even have raylib
And I mean that's like featureless stuff. The ecosystem for gaming for C++ is massive. They will never catch up.
sad
bevy had it's first jam a few months ago, the engine itself is still quite barebones
https://itch.io/jam/bevy-jam-1
embark is the only studio that i know that is using it for some of their new stuff
https://github.com/EmbarkStudios
You can't.
The most valuable asset of Rust (even more valuable than the language itself) is it's community. Even at such an early stage in it's lifetime. The Rust Strike Force will rewrite the entire universe in Rust.
The unsafe keyword is a declaration that you know that you do and that the compiler can trust you. You will create your double linked list exclusively within the boundaries of that unsafe block while the rest of your codebase is safe.
And there is LITERALLY nothing wrong about that.
2 years ago
Anonymous
that's a long way to say "i can't"
2 years ago
Anonymous
No. It's a long way to say "i can".
2 years ago
Anonymous
So Rust isn't actually safe, it just provides tools to make it easier to keep track of potentially unsafe code.
Thing is, I already have a linter in C++ which warns me if I'm doing something unsafe, so all Rust has to offer at this point is syntax so ugly it makes C++ look nice.
2 years ago
Anonymous
I think this works
use std::cell::RefCell;
use std::rc::{Rc, Weak};
Everyone knows that, that's why Cpp gays are seething. They know the only thing they have is the larger ecosystem and they feel threatened when they're reminded how fast the adoption rate of Rust is growing.
Rust still cannot be bootstrapped without a C++ compiler thanks to LLVM so there's no "C++ seethe" as they're still winning. Rust may have some niche use or can be used for moron programmers who can't into memory management.
>still cannot be bootstrapped without a C++ compiler
This is not important in any practical way.
I guess it matters in pissing wars. But surely you can do better? I use Rust and I could do better. The library ecosystem matters more, the architecture support matters more, the C interoperability matters more. All of those are ways in which C++ has Rust beat. But Rust using LLVM? It doesn't matter.
I don't see the point
I already pointed out there is software to check for C/C++ safety which is rust's main gimmick
What are the other features like lifetimes and tupples and what not?
And people are wasting time doing this massive effort recreating everything for no reason.
>there is software to check for C/C++ safety
And this doesn't actually let people write C++ with the same guarantees as Rust. Doing that is fundamentally very difficult, maybe practically impossible.
Seriously, listen to the C++ programmers working on Chrome: https://www.chromium.org/Home/chromium-security/memory-safety/
They're not switching to Rust just yet, but they don't think this is a solved problem in C++ and they think Rust would help if only rewriting weren't so costly.
You can totally say that Rust is immature and not worth the migration, but the problem is real. The CVEs pile up. Don't stick your head in the sand.
2 years ago
Anonymous
It seems odd to me that the rust compiler can catch memory bugs during compile time but a static analyzer can't catch them afterwards.
Why is that?
2 years ago
Anonymous
Static analyzer for which language?
You do realize that Rust is fundamentally different than CPP when it comes to memory management?
2 years ago
Anonymous
>afterwards
Are you confused with sanitizers? Static analysis happens at compile time, or even without compiling the code at all.
Rust's safety mostly comes from static analysis. The reason you can't retrofit that same analysis into C++ is that Rust is completely designed around it. So language features are designed not to interfere with it, and the standard library and all third party libraries are annotated with safety information and designed so that that annotation is possible.
To port Rust's lifetime checks to C++ you would have to replace all libraries and ban a lot of language features, and at that point why not just use a new language and get rid of many of C++'s other warts?
>This is not important in any practical way.
It means that rust will inherit every bug from LLVM due to its reliance, which are likely to be memory bugs so I wouldn't say it's not important. >The library ecosystem matters more, the architecture support matters more, the C interoperability matters more. All of those are ways in which C++ has Rust beat.
Indeed but doesn't just have a FFI that lets you run C/C++ code without any issue or slowdown or is that not possible?
>It means that rust will inherit every bug from LLVM due to its reliance, which are likely to be memory bugs
A memory bug in LLVM only means that you can e.g. make the compiler segfault. That's bad, but it's not much of a security risk for your compiled program. LLVM creates your binary but your binary does not contain LLVM inside it.
A logic bug in LLVM can cause a miscompilation that creates a bug in your binary, but you can have logic bugs in Rust too. >Indeed but doesn't just have a FFI that lets you run C/C++ code without any issue or slowdown or is that not possible?
Rust has zero-cost C FFI, but you have to write or generate bindings because the Rust compiler doesn't understand C code. So it's possible and efficient but annoying.
2 years ago
Anonymous
>This is not important in any practical way.
It means that rust will inherit every bug from LLVM due to its reliance, which are likely to be memory bugs so I wouldn't say it's not important. >The library ecosystem matters more, the architecture support matters more, the C interoperability matters more. All of those are ways in which C++ has Rust beat.
Indeed but doesn't just have a FFI that lets you run C/C++ code without any issue or slowdown or is that not possible?
I don't see the point
I already pointed out there is software to check for C/C++ safety which is rust's main gimmick
What are the other features like lifetimes and tupples and what not?
And people are wasting time doing this massive effort recreating everything for no reason.
No it wasn't. It was only a mistake to think you can do everything OO. C# fixed Java's mistake. Structured, OOP, Functional all possible in one language. Mix all 3 to edge all day and maximize your orgasm.
There's still a gray zone though. What's the proper balance between simple procedural code, functional programming and OOP? Is C# too OO? Is Scala too FP? Is Kotlin more balanced?
2 years ago
Anonymous
>What's the proper balance
Procedural in your main to establish dependency injection and kick off your main loop, object oriented to do your main task, functional for real time deterministic properties on your objects.
2 years ago
Anonymous
>functional for real time deterministic properties on your objects.
WAT?
2 years ago
Anonymous
NTA but just use common lisp and be a wizard tbh
mostly comfy functional style
mutable state and even OOP available when you want it
I know this is a shitpost, but if you aren't going to use SFINAE just do this.
template <typename T>
[[nodiscard]] static constexpr T add(T&& a, T&& b) noexcept {
return a + b;
}
I hate the Black person who came up with trailing return types for C++. "Hey write '-> return type' at the end of your signature but don't forget the 'auto' from the beginning" Why would I ever use trailing return types if I have to write something in the beginning of the signature anyway?
if the return type depends on a decltype() of the template arguments or some shit, then you need the trailing return type. if it doesn't then it's just useless wankery
You'll think that I'm trolling or that I'm an idiot, but I really don't see the point of this language when there's already C and OOP doesn't provide as much over the plain old structural programming as it's claimed it does.
Various things, I've implemented some algorithms and data structures, GPGPU in CUDA C, Color image segmentation using fuzzy clustering, recently some application to test a networking library for ethernet switch.
C++ homosexuals should be happy that actual alternatives to their dumpster fire are popping up. when my job switched from Java to Kotlin i cried tears of joy. you morons will fanboy programming languages what the frick
one word
not needed
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Safety is just an icing on top of the cake. Rust is much more than that.
not worth it if the ecosystem is barren
It doesn't even have imagemagick or anything to replace it
Looks like it has bindings
work in progress ff
Which one of them provide full temporal memory safety?
How come Google is pouring incredible effort into mitigations rather than just fixing it all with existing static analysis? Here's this week's example: https://v8.dev/blog/retrofitting-temporal-memory-safety-on-c++
not rust
https://lkml.org/lkml/2021/4/14/1099
Already fixed, was just a WIP wart
sir those are 8 words
Rust (one word)
>you(1) will(2) never(3) be(4) a(5) woman(6)
Check again.
well add 2 because he said "one word" so its correct
Is Rust able for game dev like C++ is?
And why wouldn't it be? It's capable of anything just like C++. You will either learn it now that the ecosystem is still small or learn it when it inevitably turns into a gargantuan mature ecosystem because the trend isn't stopping tomorrow, that i can assure you.
it has sdl2 I guess
I mean they're trying which is kind of sad
You might start out with that and then find out half way its missing stuff
It doesn't even have raylib
And I mean that's like featureless stuff. The ecosystem for gaming for C++ is massive. They will never catch up.
sad
apparently a lot of work has been done on bevy. haven;t tried it though.
bevy had it's first jam a few months ago, the engine itself is still quite barebones
https://itch.io/jam/bevy-jam-1
embark is the only studio that i know that is using it for some of their new stuff
https://github.com/EmbarkStudios
>diaper-wrapped bloat language with a safety cap mechanism
>black magic
do not redeem sir.
i will rewrite every single rust software in C and there's nothing you can do about it
You can't.
The most valuable asset of Rust (even more valuable than the language itself) is it's community. Even at such an early stage in it's lifetime. The Rust Strike Force will rewrite the entire universe in Rust.
write a doubly linked list without unsafe blocks
The unsafe keyword is a declaration that you know that you do and that the compiler can trust you. You will create your double linked list exclusively within the boundaries of that unsafe block while the rest of your codebase is safe.
And there is LITERALLY nothing wrong about that.
that's a long way to say "i can't"
No. It's a long way to say "i can".
So Rust isn't actually safe, it just provides tools to make it easier to keep track of potentially unsafe code.
Thing is, I already have a linter in C++ which warns me if I'm doing something unsafe, so all Rust has to offer at this point is syntax so ugly it makes C++ look nice.
I think this works
use std::cell::RefCell;
use std::rc::{Rc, Weak};
#[derive(Debug)]
struct Node<T> {
value: T,
prev: Option<Weak<RefCell<Self>>>,
next: Option<Rc<RefCell<Self>>>,
}
type List<T> = Rc<RefCell<Node<T>>>;
fn new<T>(value: T) -> List<T> {
Rc::new(RefCell::new(Node {
value,
prev: None,
next: None,
}))
}
fn insert<T>(node: &List<T>, value: T) {
let new = new(value);
new.borrow_mut().prev = Some(Rc::downgrade(&node));
if let Some(next) = node.borrow_mut().next.take() {
next.borrow_mut().prev = Some(Rc::downgrade(&new));
new.borrow_mut().next = Some(next);
}
node.borrow_mut().next = Some(new);
}
fn iter<T: Clone>(node: &List<T>) -> impl Iterator<Item = T> {
let mut cur = Some(node.clone());
std::iter::from_fn(move || {
let node = cur.take()?;
let node = node.borrow();
cur = node.next.clone();
Some(node.value.clone())
})
}
fn main() {
let list = new(10);
insert(&list, 20);
insert(&list, 30);
for num in iter(&list) {
println!("{num}");
}
}
>The Rust Strike Force
i don't think you realize how gay that sounded
>implying any Rust programmer would feel bad about being called gay
Cool man, sounds like a fun project. I hope you have fun (and learn something).
bro don't listen to the rustsister. if you want real magic, learn common lisp
rust has the high levelness of lisp and the low levelness of c elegantly combined
>high levelness
Haters gonna seethe,
but Rust blows away CPP to oblivion.
Everyone knows that, that's why Cpp gays are seething. They know the only thing they have is the larger ecosystem and they feel threatened when they're reminded how fast the adoption rate of Rust is growing.
Rust still cannot be bootstrapped without a C++ compiler thanks to LLVM so there's no "C++ seethe" as they're still winning. Rust may have some niche use or can be used for moron programmers who can't into memory management.
>still cannot be bootstrapped without a C++ compiler
This is not important in any practical way.
I guess it matters in pissing wars. But surely you can do better? I use Rust and I could do better. The library ecosystem matters more, the architecture support matters more, the C interoperability matters more. All of those are ways in which C++ has Rust beat. But Rust using LLVM? It doesn't matter.
>there is software to check for C/C++ safety
And this doesn't actually let people write C++ with the same guarantees as Rust. Doing that is fundamentally very difficult, maybe practically impossible.
Seriously, listen to the C++ programmers working on Chrome: https://www.chromium.org/Home/chromium-security/memory-safety/
They're not switching to Rust just yet, but they don't think this is a solved problem in C++ and they think Rust would help if only rewriting weren't so costly.
You can totally say that Rust is immature and not worth the migration, but the problem is real. The CVEs pile up. Don't stick your head in the sand.
It seems odd to me that the rust compiler can catch memory bugs during compile time but a static analyzer can't catch them afterwards.
Why is that?
Static analyzer for which language?
You do realize that Rust is fundamentally different than CPP when it comes to memory management?
>afterwards
Are you confused with sanitizers? Static analysis happens at compile time, or even without compiling the code at all.
Rust's safety mostly comes from static analysis. The reason you can't retrofit that same analysis into C++ is that Rust is completely designed around it. So language features are designed not to interfere with it, and the standard library and all third party libraries are annotated with safety information and designed so that that annotation is possible.
To port Rust's lifetime checks to C++ you would have to replace all libraries and ban a lot of language features, and at that point why not just use a new language and get rid of many of C++'s other warts?
>It means that rust will inherit every bug from LLVM due to its reliance, which are likely to be memory bugs
A memory bug in LLVM only means that you can e.g. make the compiler segfault. That's bad, but it's not much of a security risk for your compiled program. LLVM creates your binary but your binary does not contain LLVM inside it.
A logic bug in LLVM can cause a miscompilation that creates a bug in your binary, but you can have logic bugs in Rust too.
>Indeed but doesn't just have a FFI that lets you run C/C++ code without any issue or slowdown or is that not possible?
Rust has zero-cost C FFI, but you have to write or generate bindings because the Rust compiler doesn't understand C code. So it's possible and efficient but annoying.
>This is not important in any practical way.
It means that rust will inherit every bug from LLVM due to its reliance, which are likely to be memory bugs so I wouldn't say it's not important.
>The library ecosystem matters more, the architecture support matters more, the C interoperability matters more. All of those are ways in which C++ has Rust beat.
Indeed but doesn't just have a FFI that lets you run C/C++ code without any issue or slowdown or is that not possible?
Kek, anything that can be rewritten in Rust, will probably be rewritten in Rust
because then it would be infinitely easier to maintain.
I don't see the point
I already pointed out there is software to check for C/C++ safety which is rust's main gimmick
What are the other features like lifetimes and tupples and what not?
And people are wasting time doing this massive effort recreating everything for no reason.
Obviously, if they didnt feel threatened they wouldnt be salty every time it is mentioned.
yeah pretty much
KEK
saved
>only true wizards will understand
OOP was a mistake
This is template programming, not OOP
No it wasn't. It was only a mistake to think you can do everything OO. C# fixed Java's mistake. Structured, OOP, Functional all possible in one language. Mix all 3 to edge all day and maximize your orgasm.
There's still a gray zone though. What's the proper balance between simple procedural code, functional programming and OOP? Is C# too OO? Is Scala too FP? Is Kotlin more balanced?
>What's the proper balance
Procedural in your main to establish dependency injection and kick off your main loop, object oriented to do your main task, functional for real time deterministic properties on your objects.
>functional for real time deterministic properties on your objects.
WAT?
NTA but just use common lisp and be a wizard tbh
mostly comfy functional style
mutable state and even OOP available when you want it
In Rust this is just
#![feature(const_trait_impl)]
#[must_use]
const fn Add<T: ~const std::ops::Add<Output = T>>(a: T, b: T) -> T {
a + b
}
In C this is just:
#define Add(a,b) (a+b)
In Rust this is just
macro_rules! Add {
($a:expr, $b:expr) => {
$a + $b
}
}
rofl @ that syntax
Toss away the nodiscard, noexcept and is_arithmetic checks. You don't make mistakes, do you?
I know this is a shitpost, but if you aren't going to use SFINAE just do this.
template <typename T>
[[nodiscard]] static constexpr T add(T&& a, T&& b) noexcept {
return a + b;
}
I hate the Black person who came up with trailing return types for C++. "Hey write '-> return type' at the end of your signature but don't forget the 'auto' from the beginning" Why would I ever use trailing return types if I have to write something in the beginning of the signature anyway?
if the return type depends on a decltype() of the template arguments or some shit, then you need the trailing return type. if it doesn't then it's just useless wankery
C++ is a language done by and for super sane programmers
You'll think that I'm trolling or that I'm an idiot, but I really don't see the point of this language when there's already C and OOP doesn't provide as much over the plain old structural programming as it's claimed it does.
what have you written in c?
Various things, I've implemented some algorithms and data structures, GPGPU in CUDA C, Color image segmentation using fuzzy clustering, recently some application to test a networking library for ethernet switch.
Tge point is too import solution duh
C++ homosexuals should be happy that actual alternatives to their dumpster fire are popping up. when my job switched from Java to Kotlin i cried tears of joy. you morons will fanboy programming languages what the frick
the main reason I am happy alternatives exist is that it got those asshats in the C++ committee to actually start working on the language again.
C2 is based but C is baseder