Rust!

So you don't actually know what you're talking about. Got it.

every time, same with the avataring

>Rust is better. It would only "fail" because C shills sabotage it.
no, it will fail bc its shit and no one wants to use it (picrel)
also C shilling is actually a relatively new thing you disgusting liar

i know bc i started it. unintentionally. by btfoing your rust shillthreads attacking C.

>picrel
extremely misleading.

ugh, theres so much wrong in your post, including your picrel i dont even know where to begin
lets start with the fact that C is not C++.
cuz its not. so your the premise of your post goes to hell, in a handbasket, jerking off furiously

errr... what were left with, then?
that C took a good while to take off? that it had many concurrents? that it got accepted bc it scratches a specific itch? that your concept of shilling is inadequate to the time period were talking about?

and wtfs with isaac newton ffs

if thats what rust does to a mfer
it should be banned from everywhere as a public health concern

>shilled since the 50-60's
thats exactly what you said
C++ was shilled to replace C since its inception, toughever
and C doesnt really appear on the market job-wise

if youre gonna fail its not bc C is shilled.
its because rust is (somehow) shittier than C++.

>If you say Dennis Ritchie invented the OS
this i didnt say. also C++. like i said you said

>That pic was made by a C shill
catastrophic reading comprehension failure. on your behalf to make things sufficiently clear.
thats (among others) what i meant by "what rust does to a mfer"

>Rust will fail because... BECAUSE IT JUST WILL, ALRIGHT?

>Explain. I don't know what that means
How do I put this basically enough? It's a philosophical theory, the kind you might encounter if you took time to read some books. The fundamental premise is to envision history as a sequence of "dialectical" conflicts. Each dialectic begins with a proposition, a thesis... which inherently contains, or creates, its opposite - an antithesis. Thesis and antithesis. The conflict is inevitable. But the resolution of the conflict yields something new - a synthesis - eliminating the flaws in each, leaving behind common elements and ideas.
Thesis(Rust) and antithesis(C).

[...]
>Explain. I don't know what that means
How do I put this basically enough? It's a philosophical theory, the kind you might encounter if you took time to read some books. The fundamental premise is to envision history as a sequence of "dialectical" conflicts. Each dialectic begins with a proposition, a thesis... which inherently contains, or creates, its opposite - an antithesis. Thesis and antithesis. The conflict is inevitable. But the resolution of the conflict yields something new - a synthesis - eliminating the flaws in each, leaving behind common elements and ideas.
Thesis(Rust) and antithesis(C).

I'm saying that Rust will inevitably lose the battle. It's not built to last. We're not saying C is better with no reason. We're just hastening the inevitable.

Rust is deemed by some as a corporate anomaly, crafted to relegate codemonkeys to tasks beyond their purview, thereby suppressing wages across the board. Moreover, it obstructs those who have no requirement for its subsystems. While chatter abounds regarding its convenience, scant mention is made of its tangible utility to the world. Survival notwithstanding, its divergence from the principles underpinning good programming languages remains evident.

>I can guarantee you that Rust has more thought put into it than C will ever have throughout its entire lifetime
who cares.

think smart.
bc who cares if you think more, but all you conclusions are shit?

Why should I? You haven't provided any arguments for why C is better. I also didn't make this thread to argue with cnile baby ducks. Make a thread about C instead of posting on a thread about something you don't like.

Also, I did casually provide one reason already:

My pipeline was
>C++ programmer for 10 years
>Learn Rust
>Hate it
>Go back to C++
>Eventually try rust again
>Dislike it, but end up using some new patterns in C++
>Few months go by, decide to try again
>It clicks. Everything is really simple and intuitive. Certain kinds of optimizations that are really hard to do safely with a language like C++ are a breeze, if not automatic
>Try to go back to C++ but cannot deal with the lack of a borrow checker anymore

[...]
Never felt the need to use an LSP for rust.

[...]
Ownership and borrowing aren't shackles. It may look like they are, but they're actually extremely helpful at expediting development. There is no performance loss, development time wise or performance wise. You have been visited by the classic skill issue. You know A and now you're upset that B isn't like A. That's cool, just don't pretend to know B when you don't, it just makes you sound like an idiot.

Then again you're unironically arguing Rust is more limiting than C, so I guess you're pretty far gone at this point.

>Certain kinds of optimizations that are really hard to do safely with a language like C++ are a breeze, if not automatic

You are the one arguing that Rust has literally no features that are an improvement on what C offers, and you will die on this hill because you're way more concerned about reinforcing your biases and being superior to everyone else rather than actually having a discussion about anything. Make no mistake, you're acting like I'm the one treating the language I'm currently using as if its a sports team, but you are 100% projecting.
Besides, we all know that your goto counter-arguments for everything I can throw at you will boil down to
>1. just don't make mistakes
>2. just write more code
You won. I am defeated and in tears. So why not just simply close the thread? Report it while you're at it.

>a specialized solution with equal quality of code will always be faster than a generalized one.
You are so far off the mark you aren't even in the same stadium motherfricker. Just close the thread, you have literally nothing of value to contribute.

Ok, I'll take the bait: there are no checks. Good quality Rust code will be generally faster than C code because the kinds of solutions you have to build in C to have a chance at maintaining the program will be inherently less efficient than rust solutions which can ensure correctness at compile time.

Unless you think benchmark code is in any way representative of the conventional way people use the language, your argument is moronic. The whole purpose of the borrow checker and lifetimes is precisely to remove these checks from the runtime. That you don't know this and think that there is an actual runtime cost to the things I'm talking about betrays that you know jack shit about the thing you're trying to criticize.

Not only that, but you can objectively do everything you can do in C in Rust, so it doesn't even matter. Riddle me this: Why would I use your shitlang when rust can do all yours can and more, with 0 downsides?

But I'm looking forward to watch you argue that Rust is less efficient because Arc, while C doesn't even have any kind of static dispatch. This is the thing, to the Cnile baby duck, void* is enough, but when talking about performance it suddenly disappears from the conversation altogether. But let me guess, real C programmers write concrete structures for every type they decide to use for their ADTs, right? I am looking forward to having a great big chuckle at your bending over backwards to defend _Generic by the way.

>rust lib writers benchmark against the libc
What else would they benchmark against? It's the only other performant standard library aside from the rust one, and the most widely used. This is not the strong argument you think it is.

Your argument is
>C got here first, therefore C is better.
Do better.

>lol. functions? lmao
This may be news to you, but sometimes we write things suboptimaly from a performance perspective so that they are easier to manage in the long run. An example of this is implementing polymorphic solutions in C using function pointers that have to be dereferenced because C has no static dispatch. Another example is checking for optional parameters in a function, instead of writing different functions for each possible parameter configuration, which is something we do in every language.

I can guarantee you one thing: every decision made in rust is made with performance in mind, and I don't mean that in the meme "this scripting language is so LE FAST" way. Performance is more a core of Rust than it is a core of C.

>rust lib writers benchmark against the libc
>incompetents benchmark libs against libs
>competent people benchmark their tailor made solutions to the fastest libs to see if theyre as competent as they think they are
You are incoherent. If they're writing a standard lib, why wouldn't they benchmark against the most widely used standard lib?

>one of the components of my project is a quasi scripting language
>and comfy pointers to functions are comfy
Function references in Rust are better by a wide margin. Rust also has closures, which C doesn't have.

Again,
You don't know the language. You feel very threatened as evident by your posts, so you flail around in an attempt to "deboonk" something you know nothing about because you feel bad that someone likes something you don't, and you see it is actually gaining some traction.
It's ok to like and use C. Let it go.

>if thats how you understand "less checks to be made"
Show me the checks. Go.

>yeah. in C performance considerations are left to the programmer.
>rust is designed for people who cant into opti.
>heck, rust is deigned for people who cant into strings...
Not really. Rust gives you a ton of flexibility to optimize, to make the code do exactly what you want, and that's why it's so complex. Making Rust code fast is a manual process where you have to know how everything works. The language gives you tools and even lets you create tools but doesn't do your work for you. Case in point:
>no. but i can admit theyre equivalent and the difference is subjective
>type Binop = fn(i32, i32) -> i32;
>let bo: Binop = add;
>x = bo(5,7);
>
>vs
>int x;
>int (*ptr_add)(int, int) = &add;
>x = ptr_add(5, 7);
This is only one kind of function reference, Rust has various other options. Consider:
fn add_using(add: impl FnOnce(i32, i32) -> i32) {
let x = add(5, 7);
}
Rust will monomorphize a separate version of this function for each callable type that you use with it. This means that in a lot of cases it's guaranteed to hardcode the function call instead of resolving it at runtime, giving it an opportunity to inline. (You can also pass it C-style function pointers, and then it will monomorphize a single instance that uses those.)
C doesn't really give you that tool, you have to use generics or copy/paste. Which is a pain in the ass so people reach for it less often even in cases where it would perform better.
Rust also has boxed functions as a third alternative. And it lets you distinguish between callables that are freely callable and ones that require exclusive access and ones that can only be called once.
So they're not equivalent. They're a superset.

its still deterministic even if you do
what you mean is that you might not know what will be the result.
its not the exactly the same.
and theres UBs that are rock solid.
like derefs on packed pointers.
like binary ops on floats.

Some UB is solid and documented as such, some UB is simply bad news that you really can't rely on.

It literally is generics, but unlike whatever implementation you're thinking of it has to be resolvable at runtime. If it isn't then your code won't compile. It doesn't silently deoptimize it into a vtable. (You can manually request a vtable though.)
You're in control of your code's efficiency. It doesn't sweep it under the rug.
It helps to learn the language you're arguing about! I don't think it'd convert you but it would let you make better criticisms.
>having 50 different ways of achieving something you could achieve using only one only increases code complexity... for free. for shits and giggles.
All the different ways exist for a reason. You can't just assume something was done for no reason, come on, that means you don't understand it.
>bc whenever you want to make something custom and optimized you will be doing unsafe.
>you will be writing C, only with rust syntax.
No. You usually don't need unsafe and unsafe mixes well with many higher-level features. You can write generic unsafe code.
>but in small teams?
>in applications where rust features become a cognitive burden?
Works fine IME. In C you have to track all the same shit manually, I don't think the cognitive burden increases overall.
>im literally telling you that each tool has its niche.
C has its niche for sure and it's not going away but I don't think its niche is the one you're describing.
>rust wont replace everything bc its not designed for that
Obviously.

>depending on the keyword you parse, the value behind it can be a float or an int for example.
Rust isn't dynamically typed, so how do you envision the setup for this?
The most likely implementation would use a separate variable for each possible type with its own separate function call. Like so:
enum Value {
Int(i32),
Float(f64),
// etc
}

match parse_value() {
Value::Int(integer) => print_debug(integer),
Value::Float(number) => print_debug(number),
}
The compiler sees the first function call, sees that it uses an i32 variable, and generates an i32 version of print_debug().
Then it sees the second function call, sees f64, etcetera.
If you want dynamic dispatch you have to use it explicitly:
let value: Box<dyn Debug> = parse_value_dyn();
print_debug(&value);
(You have to define and implement parse_value() differently so I gave it another name.)
Notice the "dyn" keyword. That's how you opt into that. Notice also the Box to allocate the value on the heap (since you don't know its size). This doesn't happen silently either. Pessimization is a deliberate manual choice.
C++ templates are also guaranteed to be monomorphized, and because the details are kind of sloppy there's really no alternative.
(But it implements vtables using a completely different mechanism, namely virtual functions, while Rust builds both generics and virtual function calls on top of traits so that it's easier to switch between them.)

(cont.)
>C has its niche for sure and it's not going away but I don't think its niche is the one you're describing.
idk man
if rust becomes a cognitive burden, its a cognitive burden, no?

to clarify:
i would use C
>whenever you need all the performance you can get
bc C is perfect to create low-level custom solutions.
>whenever you have to put something where it doesnt really fit
bc of a (quasi) lack of automations, and because of a syntax that makes it easy to manipulate memory.

all in all i might look into rust at some point, just for honesty sake
it wont be tomorrow tho. im in the middle of something rn

you need all the performance you can get
I don't think this works out, at least not in general. You can write very fast Rust code using weird specialized tricks, just like C. A lot of high-performance work today is done in C++.
The benchmarks don't show this, neither silly microbenchmarks nor larger systems.
you have to put something where it doesnt really fit
Completely agreed about this one.
>all in all i might look into rust at some point, just for honesty sake
Good luck!

>Rust isn't dynamically typed, so how do you envision the setup for this?
ugh... im too tired to learn rust on the fly rn
and my C++ is quasi non existent

but in generics and templates
when type deduction plays a role
and it cannot be decided at compiletime
it decays into a jump table and runtime computation
maybe theres some way i didnt think of, maybe longjumps idk
but it isnt like theres 30 ways you could go about things... and...
>while Rust builds both generics and virtual function calls on top of traits so that it's easier to switch between them.)
yeah, you say as much yourself
also isnt a trait just a vtable? only the vtable is "global"? while you regroup specific types into a trait... right?

but then fundamentally, at the root of it all, the two procedures you can do, is either duplicate functions (or generics- automatisation thereof) (ifit can be decided at runtime) or a jump table/case statement.
which you can do in c.

and if you really abhor duplicate code you could either cobble toegether a macro, or just go all the way in and extend the language for which extension you just do a modif pass on your code before shoving the product into the compiler
you could even seamlessly integrate this, and even the construction of your tools for passe purpose themselves into a makefile.
and you can do that easily bc C is so simple at its core. its dead simple to algorythmically generate C code.
python would already be a bigger pain in the balls
i will learn it someday but i think rust could be a chore. at least if one would want to keep a granular control over the code generation

i mean, if youre stubborn, you could create a self generating memory management system you graft onto regular C code, just with the addition of a couple symbols for instance.
its been a while i wanted to create a code analysis tool which would follow the lifetimes of my variables. i never really needed it,but it would be nifty to have
(cont.)

like i wrote
if type deduction is involved
and it cannot be decided at compiletime
>it is decided at runtime
maybe rust doesnt do runtime type deduction, but c++ does, i wasled to believe

thanks anon. i was kinda stepping in the dark here

[...]
Different anon here
To make this very clear, types that do dynamic dispatch have a different syntax (with the dyn keyword) from types that do static dispatch
This was one of the few syntax changes after 1.0, to make it harder to accidentally do the slow thing when you expect the fast thing to happen

aaah, ok
you solved it by giving control to the user over which solution is used
makes sense.

So you can do this in C, but in C it's weird and fiddly enough that it's a tool of last resort, while in Rust it's often actually the most convenient way to do something. People will write generics all over the place and libraries will provide them without thinking twice because you don't have to explain to users how to use them, they already know.
It's like how you could in principle do everything in assembly, and yet...

>>c
and fiddly
>thats purely subjective.
>it "weirdness" can even be discussed in an objective manner, since theres so many languages that borrow from C (B) syntax
That's about something very specific unrelated to syntax, please reread and take note of the context

Nah, this is your responsibility
Just reread your own post from yesterday, this one:

>Rust isn't dynamically typed, so how do you envision the setup for this?
ugh... im too tired to learn rust on the fly rn
and my C++ is quasi non existent

but in generics and templates
when type deduction plays a role
and it cannot be decided at compiletime
it decays into a jump table and runtime computation
maybe theres some way i didnt think of, maybe longjumps idk
but it isnt like theres 30 ways you could go about things... and...
>while Rust builds both generics and virtual function calls on top of traits so that it's easier to switch between them.)
yeah, you say as much yourself
also isnt a trait just a vtable? only the vtable is "global"? while you regroup specific types into a trait... right?

but then fundamentally, at the root of it all, the two procedures you can do, is either duplicate functions (or generics- automatisation thereof) (ifit can be decided at runtime) or a jump table/case statement.
which you can do in c.

and if you really abhor duplicate code you could either cobble toegether a macro, or just go all the way in and extend the language for which extension you just do a modif pass on your code before shoving the product into the compiler
you could even seamlessly integrate this, and even the construction of your tools for passe purpose themselves into a makefile.
and you can do that easily bc C is so simple at its core. its dead simple to algorythmically generate C code.
python would already be a bigger pain in the balls
i will learn it someday but i think rust could be a chore. at least if one would want to keep a granular control over the code generation

i mean, if youre stubborn, you could create a self generating memory management system you graft onto regular C code, just with the addition of a couple symbols for instance.
its been a while i wanted to create a code analysis tool which would follow the lifetimes of my variables. i never really needed it,but it would be nifty to have
(cont.)

>theres nothing fiddly about using a couple sed's at the least, and writing an extension to a language at most.
This is very fiddly, which is why it's done only rarely. I can't offhand name a C project that does it like that, and only one project comes to mind that hacks in generics using the preprocessor (postgres). I haven't studied a ton of C projects but I've looked at enough to notice a pattern—if you know some good examples then please post them.
Meanwhile all Rust programmers use Rust generics all the time because they just werk and you don't need to explain to other programmers what scheme you've concocted.
This extreme difference in usage indicates something, right?
If fast code is inconvenient to write then people will write less of it.

especially to eliminate dead code
or multiple variables being utilized to set up/calculate the same parameter
like turning the whole program into a tree of dataflows if you see what imean
not only as a debug tool, but maybe even more as a refactoring/code exploration tool.

>with the same problem as generics: if they cannot be decided at compile time, they turns into a jump table.
Hahahahahahahahaha

Hahahahahahahahahaha
You "know" a whole total of 1 (one) language, motherfricker. Unironically rope.

>ub is still deterministic. git gud, scrub
In what sense? Can you still upgrade your compiler?

>yeah. in C performance considerations are left to the programmer who wrote the compiler.
FTFY. You forgot the end of your sentence.

>rust is designed for people.
FTFY.

no argument = i accept your concession, rustroons

>yeah. in C performance considerations are left to the programmer.
>rust is designed for people who cant into opti.
>heck, rust is deigned for people who cant into strings...
Not really. Rust gives you a ton of flexibility to optimize, to make the code do exactly what you want, and that's why it's so complex. Making Rust code fast is a manual process where you have to know how everything works. The language gives you tools and even lets you create tools but doesn't do your work for you. Case in point:
>no. but i can admit theyre equivalent and the difference is subjective
>type Binop = fn(i32, i32) -> i32;
>let bo: Binop = add;
>x = bo(5,7);
>
>vs
>int x;
>int (*ptr_add)(int, int) = &add;
>x = ptr_add(5, 7);
This is only one kind of function reference, Rust has various other options. Consider:
fn add_using(add: impl FnOnce(i32, i32) -> i32) {
let x = add(5, 7);
}
Rust will monomorphize a separate version of this function for each callable type that you use with it. This means that in a lot of cases it's guaranteed to hardcode the function call instead of resolving it at runtime, giving it an opportunity to inline. (You can also pass it C-style function pointers, and then it will monomorphize a single instance that uses those.)
C doesn't really give you that tool, you have to use generics or copy/paste. Which is a pain in the ass so people reach for it less often even in cases where it would perform better.
Rust also has boxed functions as a third alternative. And it lets you distinguish between callables that are freely callable and ones that require exclusive access and ones that can only be called once.
So they're not equivalent. They're a superset.

[...]
Some UB is solid and documented as such, some UB is simply bad news that you really can't rely on.

(cont.)
... that would make it a generalized solution.

i gtg for ~30 mins
brb

>yeah. in C performance considerations are left to the programmer who wrote the compiler.
That's a fact. The speed of C programs depends on the programmer who wrote the compiler.

From one of your idols:
https://justine.lol/endian.html
> Now you might be looking at the code above and be thinking, surely that's the slowest thing imaginable. Here's a israeliteel from the TensorFlow codebase expressing that sentiment:
// Fall back on a non-optimized implementation on other big-endian targets.
// This code swaps one byte at a time and is probably an order of magnitude
// slower.
#define BYTE_SWAP_64(x)
~~*(x)&0x00000000000000ffUL) << 56) | ~~*x)&0x000000000000ff00UL) << 40) |
~~*x)&0x0000000000ff0000UL) << 24) | ~~*x)&0x00000000ff000000UL) << 8) |
~~*x)&0x000000ff00000000UL) >> 8) | ~~*x)&0x0000ff0000000000UL) >> 24) |
~~*x)&0x00ff000000000000UL) >> 40) | ~~*x)&0xff00000000000000UL) >> 56))

> That might have been true with old compilers, but it's not true today. The more verbosely well-defined your code is, then with a good modern compiler, the smaller the generated code will be. Here's what we get if we run it through clang.godbolt.org:

>if its too slow, you can inline asm in C.
https://doc.rust-lang.org/reference/inline-assembly.html

I was just pointing out that this was a feature in rust as well. What kind of brainrot do you have to be under to write a reply like this to a post like mine?

Nowhere in my post did I call you shit for not using an LSP, I implied you are stupid which is entirely different and valid.
Let me explain so there's no confusion in your head:
Not using an LSP does not make you a good programmer, it doesn't make you a bad one either, what it does do is lower your productivity for no reason other than you feeling superior to people that actually use tools meant for their job.
Not using an LSP in 2024 is intentionally gimping yourself.

Ok, thanks!

>async is strictly superior to what you find in other systems programming languages.
I think Go's CSP style concurrency with goroutines is better because it's so simple. But both goroutines and async are million times better than anything else.

also crabs benolng in my belly, not in my computer

Aww man, what the frick. These things you're saying are really hurtful man. 🙁

also crabs benolng in my belly, not in my computer