>>107528975
based.
now learn how to use code blocks, newfag.

>>107528975
Reddit spacing?

This is the kind of hello world program an Indian writes

>>107529034
So how would a blond-haired blue-eyed milk-gargling Aryan write hello world?

and it only needs 4gb ram and 20 minutes to compile this in a slim 3MB binary

main.rs:5:1: error: could not resolve macro invocation 'println' [E0433]
    5 | println!("Hello World! I am happy to code in Rust.")
      | ^~~~~~~

Saaaars, how do I cargo add println! crate to my project?

>>107528975
When do you start HRT?

File: image.jpg (3.46 MB, 3024x4032)

3.46 MB JPG

>>107529289
just now

File: 1765445133673625.png (194 KB, 1055x607)

194 KB PNG

>>107528975
Plebbit spotted in 4k

>>107529064

#include <stdio.h>
int main() {
    puts("Hello World");
    return 0;
}

>>107529064
>>107531100
C is the great replacement of programming languages.

>>107531100
Classic Cnile creating bugs in hello world software, here's the correct code:

#include <stdio.h>
int main() {
    return puts("Hello World") == EOF;
}

what a fucking useless thread
imagine unironically discussing hello world
all fields

>>107531249
why so mad lil bro

>>107531230
"Curly braces are for comments." - a blond-haired blue-eyed milk-gargling Aryan

>>107531317
to be desu if C wasn't an inconsistent piece of shit, curly braces for functions would be optional just like they are in control statements

>>107530230
I still can't believe people are actually stupid enough to do this.

>>107528975
So you only chopped the tip off. That makes you Jewish. It's the first step to becoming YNBAW.
Congratulations on your journey.

I tried it yesterday and it is weird..

all that stupid syntactic nonsense...
why the fuck did they design a high level programming language (an abstraction) to be so weird and quirky?

weird strings, no explicit return in functions, semi columns have a meaning, super weird ownership and borrowing shit where you can have the same name for multiple variables, lifetimes nonsense, methods with impl..

what the fuck is this shit?
is that the future?
if so it is incredibly unreadable and weird.

>>107528983
NTA, i've been on the site for 20 years something, only learnt about code blocks like 2m ago lol

>>107531413
> where you can have the same name for multiple variables
variable shadowing is awesome.
not hard to get that a variable is limited to the scope it was declared in anyway.

Rust is a failed experiment, midwits write shitty code in this language too, there's probably more good C++ code than there's total rust code so maybe not a fair comparison, but rust has no good programmers.

>>107528975
>fn main
>not #[tokio::main]
ngmi

>>107531585
>tokio::main, not tokyo::drift
this is why rustroons never make anything great

File: Screenshot_From_2025-09-1(...).png (487 KB, 1353x1010)

487 KB PNG

>>107531100
>>107531230

"Hello Terry\n"; // HolyC Version

  Ok::<_, anyhow::Error>(())

what the fuck is this? how am i supposed to understand this language.

  #[signal]
    async fn action_triggered(
        ctxt: &SignalContext<'_>,
        action: &str,
        value: f64,
    ) -> zbus::Result<()>;

>>107531891
what's wrong with this?

>>107532003
He's retarded. Ignore him.

>>107531547
>rust has no good programmers
what an insane cope.

I like rust because it lets me express the state of the application with the type system. Just so comfy.

>>107532945
It can't even express all useful software architectures. And its escape hatches have severe drawbacks.

>>107532872
Name one good rust programmer

>>107534120
>its escape hatches have severe drawbacks.
such as?

>>107534308
you can go on pretty much any moderately complex project made with rust and look at the top contributors.

be it esp-hal / esp-idf-svc (esp32 rust ecosystem)
drivers made in rust for linux
or former C engineers that moved to rust

i don't won't give you a list as there are plenty but thinking there are none is just retarded.
pm any language has good programmers.

depends if you ask for
1. a good programmer that knows rust
2. a good programmer that's also is good with rust
3. programmer that's good with rust

for the first, any good c engineer that learnt rust applies, and there are tons
for the 2nd any good c engineer that moved to rust or overall a good rust engineer
for the last you could say any moderately big contributor to the language.

anyway, there are tons of good projects made with rust and thus tons of good engineers that know rust / rust engineers.
i didn't name a specific one because no matter whom i mentioned you'd have tried to argue some bs cope out of bad faith.
someone that can write a complex compiler is in my book a good programmer and thus that applies for a good chunk of rust maintainers.

>>107534413
I asked for a good programmer not some codemonkey who doesn't know what he's doing

>>107531100
Too verbose.

main() {
    puts("Hello World");
}

https://godbolt.org/z/6Y5GPcehY

File: SWAT harassment of Rust critic.png (3.1 MB, 1042x6176)

3.1 MB PNG

>>107529064
Don't know, but I wonder what kind of piece of shit filth that should be put in prison for life, would try to assassinate through SWATting those critical of Rust.

>>107534308
Laura TheFurry McTrannyface

Honestly I dont even dislike Rust. I developed a lot of cool shit in Rust that wouldn't have been possible without the ecosystem it has.

But it has become a furry tranny magnet. They will never be a woman. Why do they keep trying?

>>107534308
Nicholas Nethercote
Andrew Gallant

>>107534313
Insincere question, demented troll. Given that you went straight for trolling, thank you for your concession. Are you doing to try to SWAT me? >>107534514

>>107534497
whoever i name you are gonna say "not a real programmer" you are arguing out of bad faith.
so we can flip it around so i can fullfil the definition.
to you, what defines a good programmer.

and if you actualy want an answer give me a language agnostic definition otherwise you are just a troll.

>>107534557
Glad you figured out that rust has no good programmers just because of how it is marketed.

>>107534515
> it has become a furry tranny magnet
true, but you don't have to interact with them.
also you hear more about them because they seek attention and validation.
people that aren't mentally ill don't interact with the community and as such, you don't see them.

> Why do they keep trying?
mental illness

>>107534554
> this is bad because x
> can you give me an example
> le schizo rant
NTA but you are the one trolling here

File: Screenshot_20251213-09550(...).jpg (262 KB, 707x992)

262 KB JPG

>>107534528
I respect your retarded opinion but please stop naming midwits.

>>107534582
>>107534554

>>107534554
>doing
going

>>107534617
>>107534554

>>107534636
>>107534554

>>107534596
there is nothing wrong with the statement made if you read more than the headline.
"using unwrap() is okay if it's in test/example code or when panicking indicates a bug".

i don't see what's wrong with that.

>>107534650
There shouldn't be bugs in your code and your errors shouldn't require a dependency on heavy unwind machinery.
This is same cancer that's killing C++ and rust will never be a good language if new code will continue being littered with .unwrap() everywhere like it was C or something.

>>107534642
i recognize you over the thread and i realized that you are just craving attention like a tranny would.
only thing you can do is shitting thread and derailing them as soon as someone ask you an honest examples of your unsubstantiated claims.

idk what has to happen in someone's life for one to be like this but i'm honestly curious, anon, what happened to you ?

>>107534665
>There shouldn't be bugs in your code
do you realize that the hardware itself can be compromised ?
> errors shouldn't require a dependency on heavy unwind machinery
most of the time optimized away by the compiler but also entirely optional, you can produce binaries without any of it.

>>107534668
>>107534554

>>107534665
>>107534677
> and rust will never be a good language if new code will continue being littered with .unwrap()
i agree that unwrap() is not proper error handling but its existance has its place imo.

also to avoid the machinery you can do unwrap_unchecked if you are sure it'll never be a none but it's still an option.

>>107534677
Panics can never be optimized by compiler, it's always a branch that leads to unpredictable behavior that depending on how the code was compiled, will prevent some code from running at all when it should even when some system is critically failing, this is opposite of robust, this is midwit cnile style if coding.

File: file.png (20 KB, 639x109)

20 KB PNG

>>107534683
yet you are the one posting comments with nothing but links to other comment, you started it, that's what a troll would do, and you know it.

>>107534691
>>107534554

>>107534690
> Panics can never be optimized by compiler
that's false if the compiler knows at compile time that the branch is dead, or that you hint it that it is (yes you can do that).
> that leads to unpredictable behavior
uh, no, that's not UB.

> will prevent some code from running at all
that's generaly the desired behavior of someone that uses unwrap.
you can argue that it should or shouldn't be used in x scenario but i doubt its ever used accidentaly by non beginers.

> this is opposite of robust
there is more to robustness to a software never exiting with an error, depending of your infrastructure it is the proper thing to do such that you can let the infra handle the problem and have a good separation of concern.

the overall system should not be interupted, but in most case it isn't a specific program's responsability to monitor the overall system health of the infra in which it is running.

>>107534714
? exists, .unwrap() has 0 reason to, I hope rust 2.0 will say it's deprecated

Why are rustling evangelists known for, even in public, harassing others? Are they wretched and evil pieces of shit and filth?

Why did they make Linus Torvalds himself tell them to not do social media brigading?
https://lkml.org/lkml/2025/2/6/1292

>>107534714
>>107534690
also, you can compile executable such that the panic machinery isn't there whatsoever and have compile time guarantees that it isn't.

>>107534727
> ? exists
you are not supposed to send errors up the stack in a test, it's fine to use unwrap in a test as it'll fail the test, though expects can make more sense.

same thing can be said about examples, if ? is gonna end the program with an error, the result is the same, except unwrap comes with a backtrace (enabled with a flag) which is imo better than just an error (altough you can make your error type such that it contains backtraces, but you'd not have that level of sophistication in an example, more on production software).

also, let's say you do use "?", if the end result when you match that specific error is to use panic!(), it isn't any better, you made it worse by hidding to some extent where the panic actualy came from.

.unwrap() is fine to use if it is desired behavior to crash the program when a specific error happens.
now i agree that it should be very exceptional cases.

>>107534747
> they
a tiny minority of retard ruinning it for everyone else, happens in many communities unfortunately, they don't represent a % of the rust devs, but they are mentally ill and desperate for attention so of course you hear mostly about them.

i don't interract with them nor the community, like most rust devs.

>>107534749
>also, you can compile executable such that the panic machinery isn't there whatsoever and have compile time guarantees that it isn't.
least disingenuous .unwrap() defender

>>107534308
Alyssa Rosenzweig unironically

>>107534773
>Rust project that contributes to reducing e-waste
I can respect that

>>107534761
yup, there are like a dozen crates that do just that :
https://crates.io/crates/no-panic
https://crates.io/crates/dont_panic
https://crates.io/crates/panic-never
https://crates.io/crates/no-panics-whatsoever

though they aren't the one removing the panic machinery, if you make code that doesn't use it it won't be there, they are only allowing you to prove at compile time that it isn't there and result in an error if it is, ie if you used an unwrap(), expect() or panic!() anywhere, or a library you use does.

>>107534808
Nice try glowfaggot, not including KTH into my custom buttplug driver though.

File: file.png (42 KB, 1000x442)

42 KB PNG

>>107534817
you don't have to use the crates, the code is also pretty trivial, ie, just add picrel in your code and it'll fail any compilation that results in panic machinery being in the executable

>>107534826
Don't care, this doesn't stop retards like you ruining entire codebases just by writing .unwrap() once somewhere.

>>107534665
>There shouldn't be bugs in your code
If there's no bugs then unwrap is fine because it'll never hit the failure case and panic.

File: file.png (177 KB, 752x326)

177 KB PNG

>>107534833
i don't use unwrap().
i just told you that i could see where it could make sense to use it, not that i often encounter such a case.

you can also use clippy hints to generate a warn whenever unwrap/expect/panic is used in your codebase.

my rule of thumb is that i can use unwrap for prototyping but i must remove it before any commit.
if i truely want to panic i'll use expect(), but i don't think i have any of those outside the main function where things are initialized and must be successful.

>>107534858
It's not fine because midwits like you often unwrap on user input.
Rust is a misdesigned pile of crap and I know this because core::Option/Result has unwrap too when it should've been without those, because panics might be okay in your curry laced desktop app, but they aren't ever okay to be embedded deep in the foundational code.
core doesn't even count as a library, it's a fundamental shim without which rust programs cannot even compile.
This forces me to waste time auditing crates and not using 99% of them.
I will never recommend or agree with anything positive about rust in context of my employer.

>>107534877
> often unwrap on user input
if it's a cli tool and the user provided a wrong input and the program couldn't run without a proper one, it's also fine to crash.
though i'd rather use expect() to give a proper message.

> Option/Result has unwrap too when it should've been without those

i disagree, i think they have their uses, and even if they weren't here, rust is flexible enough that you could add it back in like 5 lines of code.

just define the Unwrap<T> trait and implement it for both option and result.
it's just a match { Err/None => panic!()} nothing special.

> deep in the foundational code
you do know that c/c++ have asserts right ?
also many std function can segfault in some specific cases.
> and not using 99% of them.
if you do embeded you shouldn't use a lot of crates anyway.

also, you know if you are that scared you can use catch unwind, you don't have to crash the program when a panic happens.

>I will never recommend or agree with anything positive about rust in context of my employer.
you do you, some company will use it, some not.
fundamentaly anything can be made with it, and like any language, you can make it badly.

>>107534925
It's time to grow up timmy, it does not concern me one bit what C or C++ does and I didn't read allat cope.

>>107534995
code that have no faillure branch is a fantasy that you don't see in 99% of codebases, rust or not.

there are many things where the code should be as such, ie peacemaker, but there are also many things where it shouldn't for 2 reasons.
1. exiting with an error can be the desired behavior in a huge class of software.
2. no failure branch software has an engineering cost that would be high enough that practicaly no software we use today could have been made.
be it your web browser, music player, blender, or even kernel.

especialy, when fundamentaly, the hardware itself is not perfect and can have errors.
if you want to get anything done you have to think about what's practical and the threat model of an error happening.

peacemaker ?
no crash allowed, and you better use fucking ecc hardware / hardware that can't fail.
web browser ?
do you want to 100x your devlopment time and cost to guarantee that it can't ever crash.
or do something that's good enough and may crash once a every eclipse / less often that you'd have hardware related issues anyway.

all engineering is a question of tradeoff, where you consider, time, cost, quality etc.
some tradeoffs are a worse decision than other but you can't say that all project should make the same tradeoff of perfection without being naive.

as the saying goes "perfect is the enemy of good" at some point you want to get shit done.

>>107535031
being better than C isn't a high bar and that's why rust is such a pile of shit that solves 0 actual problems with it

>>107535082
nice opinion.
i think it is very comfy to work with and has a lot of features i enjoy.
imo it's a language you can be a lot more productive with and there isn't anything you can't realy do with it.

if you want absolute safety you should use something like ada SPARK, but have fun getting anything done with it.

>>107535128
>>107535082
fundamentaly rust is a pragmatic language, it focused on doing something practical and give you the options to do what you want.
also you can do rust formal verification, there are crates for it.

>>107535132
How come 100% of rust programmers want the wrong thing?

>>107535082
>solves 0 actual problems with it
there are hundreds of in opposition with that statment.
>>107535142
which is ?
a nice system programming language that's very expressive, have a great ecosystem and lets you build complex abstractions or not use any at all?

>>107534877
>midwits like you often unwrap on user input.
I don't. I've sent PRs to projects to convert that shit into proper error handling.
But when I call Regex::new on a string literal I'm going to unwrap because what else am I supposed to do?

>>107534925
>if it's a cli tool and the user provided a wrong input and the program couldn't run without a proper one, it's also fine to crash.
I prefer an actual controlled exit. anyhow makes that easy enough even if you're lazy.
For quick and dirty code nobody but me will even run I sometimes panic but for everything else I prefer for panics to equal bugs.

>>107535148
I cannot express my disdain for midwits in rust.

>>107535132
>fundamentaly rust is a pragmatic language
it's absolutely not, rust is highly opinionated

>>107528975
What the fuck is this? It has to be a joke thread, right?

>>107535170
And for some reason it was of opinion that it should introduce same mistakes as C and C++ instead of actually being the rock solid foundation that I can fearlessly build secure systems in.

>>107535170
>highly opinionated
opinionated doesn't mean it isn't pragmatic.
imo it's a pragmatic solution to the problem at hand.

unsafe is just the equivalent of an axium, ie the assumption that this code should be trusted and thus it can do extra things.

>>107535154
> anyhow makes that easy enough even if you're lazy
i don't use anyhow, i define my own error type with a macro i made.
but yes you could do that, add the context and then just ?, that works too, but isn't the result kind of the same ?
for a simple program i find the distinction irrelevant.
there is nothing magically bad about a panic that damage your computer or anything.
> For quick and dirty code nobody but me will even run I sometimes panic but for everything else I prefer for panics to equal bugs.
yea same, as i said, i don't write panicking code in most of my projects, see : >>107534867
there are odd cases where i consider a panic to be reasonable though, if the program has no other way to continue running in any meaningful way.
though more often than not i use ? and my error handling logic logs the error somewhere before exiting the program.

>>107535208
and a panic is just taking a shit in the middle of the street because you couldn't be bothered to find a nearest public toilet

>>107535163
I cannot express my disdain for midwits in C.

>>107535224
That's why rust and C are the same.

>>107535183
> rock solid foundation that I can fearlessly build secure systems in.
rust as the language is exactly that.
you can argue about the std and whatnot, but you don't have to use it, and it's pretty solid anyway.
and if you are scared of panics, you can always catch them.

though, i agree that it's far from perfect, i still think it's the best thing we have currently.

>>107535222
a panic is nothing more than exiting with an error and providing a backtrace when the env var is set for it.
for some cases it can imo be cleaner than exit(1) with an eprintln.

anyway, you nitpick on something irrelevant, if the program is gonna exit with an error, the difference between a manual error and a panic is pretty trivial.

>>107535232
you seem to hate everything.
is there even something that you like ?
a proper alternative ?

>>107535246
Already stated in this thread and I'm not going to repeat it.

>>107535234
there's nothing rock solid about midwits, including the compiler itself, inserting panics

>>107535248
i don't know who you are and when you made that statement, can you >> it or repeat yourself ?
i've not been here the whole thread.

>>107535266
can you give me specific criticism instead of broad statments ?
what annoys you the most with the language idk.

it's far from perfect but i do think it's one of the best thing we currently have if you want to do system programming.

>>107535246
NTA but I think his response would be "they are not contrarian enough" kek

>>107535266
> compiler inserting panics
the compiler isn't inserting panics, you can make panicless executables.

>>107535304
>the compiler isn't inserting panics
why would you need to go online and lie about things like these
>>107535302
Obviously? C is a misdesigned pile of shit, if you believe that it causes bugs, you should eliminate ALL ways that it makes them happen. This includes random abort anywhere in the code.

>>107535326
> would you need to go online and lie about things like these
you are the one that made a lie, the compiler itself does not insert any panics, there is panics in the std but they don't come from the compiler and again my statement that you can make executable with no panic machinery whatsoever is true, see :
>>107534808
>>107534826

this will fail compilation if any panic is in the generated executable.

>>107535326
> C misdisigned pile of shit
NTA, agree but you still didn't share anything you think is good

>>107535340
The compiler does insert panics and it's very trivial to prove it.

>>107535291
No, I don't have anything to say to a midwit who doesn't understand what rust is what it can do, and what makes it suck.
If you really care, feel free to educate yourself.

>>107535348
those are very special cases and most are disabled in release, and can also be disabled in the build settings.
also all those "panics" are part of core and are on operator overloading, not the compiler itself.

the only one that can't be removed in compiler settings is array / slice bound checking ie foo[invalid_index]
and afaik it's defined in core::ops and is not actualy part of the compiler but more akin to operator overloading.
but again, you can use get_unchecked() to have panicless code.
or give the compiler hints.
if it knows the branch won't happen the compiler will statically remove it.

so yes, nothing prevents you from writting code that doesn't contain any panic branches.

but if you know a panic inserted by the compiler itself and is not some operator overloading of core please tell me.

>>107535379
>midwit
no u
> feel free to educate yourself
i bet you don't even know the language and you talk about learning lmao.
no u

>>107535383
>most
most bugs that rust prevents can be prevented in C++ just by using std::ranges, if most is enough, what is the usecase for Rust?
>>107535388
Midwits have hard time analyzing things and need to be spoonfed basic things, have you experienced such thing in your life, or are you too midwit to introspect?

>>107535400
>just by using std::ranges
yes but this is optional, rust will refuse to compile if the checks pass.
also c++ iterators aren't lazy, which kinda suck imo.

> if most is enough,
the cve database proves otherwise.
> hard time analyzing things
dude, i used c++ for almost a decade before moving to rust, it just is a nicer language to work with, there is no arguing that.
also you say "muh analyzing things" have learnt the language, do you master it to the point that you can build anything with it ?
if not you are the one that didn't "analyze things".

>>107535437
>>107535400
you seem to have been spoonfed your opinion, it doesn't seem to be your own.

File: image.png (9 KB, 539x96)

9 KB PNG

>>107535441
ok midwit

>>107535437
Writing non-shitty code in Rust is also optional, midwit, compiler can't force you to be white, and from your posts I can tell that you aren't.

>>107535340
>NTA, agree but you still didn't share anything you think is good
Go is well designed but not low-level enough.

>>107535483
> Go is well designed
i can understand that some people like but i realy don't like go.
imo it's way too verbose and there are a few things that annoy me about it.
one being that it'll be perfectly happy with you not handling errors and continue the execution, but it'll scream refuse to build because of an unused variable or import, which imo is realy annoying when you want to quickly comment something out to test something.
also i've seen stuff where you have 50 lines of go which are just a one or two liners in rust.

i think rust is better designed overall and i don't see a case where i'd use go over it.
however, i do think one thing, if you have a week to learn rust or go and build something with it, go will be the better pick, but i think if you already master both rust will be a lot more productive.
anyway, it's a GC lang so i don't care much about it, i do like goroutines though desu, red blue functions are annoying.

>>107531100
C++ > C

>>107535813
>main.cpp:6:23: error: static assertion failed: C++ > C

>>107535882
totally sound argument anon

>>107535437
>also c++ iterators aren't lazy
what?

int main() {
  vector a{1, 2, 3};
  auto rg = a | views::filter([](auto x) { return x % 2 != 0; }) |
            views::transform([](auto x) {
              println(cout, "computing {}^2", x);
              return x * x;
            });

  println(cout, "IT'S");
  for (auto x : rg) {
    println(cout, "{}", x);
  }
  println(cout, "LAZY");
}

>the cve database proves otherwise.
so does the ratio of amount of code written in both the languages

>it just is a nicer language to work with
that I agree with

>>107535929

constexpr bool test(int C) noexcept {
    return C++ > C;
}

int main() {
    static_assert(test(0), "C++ > C");
}

It's not only sound, but also correct and C++ agrees.

>>107535929
>>also c++ iterators aren't lazy
>what?
also just ignore the midwit, he just types random stuff that has no correlation with reality we all live in

>>107535929
what a pile of garbage looking shit (not your fault).
no they aren't.

in rust you can have let foo = iter().map().chain().zip().whatever.
and it won't do anything til you consume the iter.

that means you can write functions that take iterators as input, do modifications to it, and output a new iterator, and still no computation will have been done.
you can also do that with streams (iterators for which the data is still arriving, ie a db query).
the nice thing about that is that you can separate how your data is processed from how it is consumed.
ie you can have a function that process the stream.
and then you use the stream it gives back and you can choose to do .for_each_concurrent(concurency, closure) or .buffered_unordered() or .buffered (ordered) or .fold()
my point is that the computation is made only once you consume the stream and thus you can separate the logic that process it (and make libs out of it) from the logic that consumes it (in your application code that can consume it however it wants).

> so does the ratio of amount of code written in both the languages
newer language has less code written with it, how shocking.
also, there are stuff where it takes 30 to 50 lines of c++ code that you can do in a oneliner in rust.

> that I agree with
huh, didn't expect that one lol

>>107535929
>>107536000
huh, c++20, i stand corrected, last i know is 17.
hmm, do you guys have stream now though ?

>rust midwit shill can't remember which C++ standard contains std::ranges
>has a lot to tell us about how they work

>>107536000
what a waste of trips. stfu anon. stop embarrassing yourself

auto filter_odd(auto&& r) {
  return r | views::filter([](auto x) { return x % 2 != 0; });
}

auto square_range(auto&& r) {
  return r | views::transform([](auto x) {
           println(cout, "computing {}^2", x);
           return x * x;
         });
}

int main() {
  vector a{1, 2, 3};
  auto rg = square_range(filter_odd(a));
  println(cout, "IT'S");
  for (auto x : rg) {
    println(cout, "{}", x);
  }
  println(cout, "LAZY");
}

>>107536008
wdym stream?

>>107536015
i used c++ for over a decade.
moved to rust more than 5 years ago.

why should i know c++20 when i decided that it's a garbage language ?

>>107536046
You used C++ for over a decade but don't know how to read?
Damn, no wonder C++ has such a bad reputation.

>>107536038
>wdym stream?
streams are like iterators but for which the data is still ongoing.
think async iterators pm.
ie a database query.

you can produce arriving results as they are comming as if they were an iter, except it's a stream because all the data isn't there yet.

so you could do, ogoing_query.filter_map().zip().fold() or whatever floats your boat.

>>107536052
> don't know how to read
i do, which is why i corrected myself after the fact, see : >>107536008

i honestly expected the usual garbage response with non lazy iterators, this is a nice surprise for once.
still, this reads like garbage and function chaining / .map().zip().whatever().fold() is much nicer

>>107536055
you can process*

>>107536062
I accept your concession.

>>107536069
you still haven't addressed streams retard.
>>107536055

>>107536110
>>107536069
also it took you until c++20 to have the most basics of basics retarded feature, and it's not even done well.

>>107536110
>>107536112
see >>107536069

>>107536112
>you you you
moshi moshi, is this rust the language talking?
wtf is even the point of all these threads that are created seemingly every day?
just write a shitty pastebin with all your arguments and share it. better, maintain it with a point system

>>107536120
That would require him to write coherently.

>>107536120
fair enough but i'm not the one making the threads though, i never made a single rust related thread.

also, still haven't replied about streams
> i accept your concession

>>107536128
Not sure what I can say but I hope someone will catch you and forcefeed you your meds because there's no difference between an interator and a stream.

>>107536153
> there's no difference between an interator and a stream
retard, a stream is the equivalent of an async iterator, for which the data is still arriving.
c++ doesn't even have async.

you can't do data_still_arriving = db_query()
data_still_arriving.map().for_each_concurrent(concurency, closure).

streams allow you to process data like iterators but before all the data has fully arrived / whilst it's still arriving, and it's not just any data its async bound data.
c++ ranges are synchronous, it's data that's already there and not still arriving ie from network io.

>>107536176
Except I can.

>>107536190
show code.
make a db query and process rows as they are steal arriving with your "streams".
in rust this is a 2 liner, trivial thing to do.

>>107536201
I said I can, not I will.

>>107536206
i accept your concession

>>107536208
I do not accept your 500 dependency solution.

>>107536176
on the other hand, so what if C++ does not have streams (I don't actually know)? should all languages have exactly the same features? what happened to minimalism and uniqueness? how many teams have rejected C++ because it does not have xyz feature? and if they have then what about it? different tools for different needs.

>>107536220
It does, it's just that resident nocoder got filtered by C++.

>>107536215
it's literaly just 3.
your sql driver
your async runtime
and futures
if you want it minimal you can do it in less than 10 deps.
if you are willing to write a tiny file of boilerplate you can do it with just the sql driver.

> I do not accept your 500 dependency solution.
even though it's not even close to 500, it's better than no solution whatsoever.

i accept your concession

>>107536224
when I want it minimal, I just link to database library

>>107536220
>streams
my point is that it's just one of a TONS of things you can do in rust and not in c++ that'll save you a ton of time.
there are c++ programs that are files and files of boilerplate you could do in just a few oneliners in rust.
it just is a much more productive language and this guy >>107536215 will use the fact that the shitty language doesn't even have proper deps managment as a cope for that.

>>107536227
I can do it in even less lines using Python, less bloated dependencies too.

>>107536226
which you can also do in rust, but my point is that you can also use crates and be done with your task in a 10th of the time with no runtime cost whatsoever.
(in fact it'll be faster because the compiler has more information to optimize with, and it'll also distribute it to the threadpool).

>>107536234
>which you can also do in rust
I sure can, but you can't, that's why you're coping, you lost.
>with no runtime cost whatsoever.
OH NO NO NO NO AHAHAHAHAHAHA GEEEEEEEEEEEEEEEEEEEEEEEEEG

>>107536241
>but you can't
i've literaly used c++ over 10 years before rust.
if it's < c++17 i know more c++ than you do.
and i could probably catch up to whatever retardedness they came after that.
> with no runtime cost whatsoever.
yes, and you get multithreading (optional) for free.
and because the language is more expressive the compiler will actualy be able generate better machine code.

also, you still refused to do the performance challenge i offered you to do last time because deep you know that you'll lose to a fucking oneliner.

>>107536241
> he thinks CPPshit std performance is any good
lmao

>>107536253
I understand, all these things you listed in this thread, yes, this would be great if I was an indian, but unfortunately...

>>107536255
Still better than anything that depends on libc at all, either way, not an argument.

>>107536262
> if I was an indian
> filtered by no_std hello world
at that point i don't even care if you are brown or not, Evola would say that you are spiritually a nigger.

>>107536264
c++ uses libc...
and you can use rust without any libc whatsoever as well.

>>107536270
Maybe I can, but you sure can't.

File: gem.png (222 KB, 900x879)

222 KB PNG

>>107536265
It's not everyday that someone makes me write this, but it's one of those days when it do.
Rent Free.

>>107531413
now you know why Apple was positioning Swift as the C++ replacement

>>107536276
> Maybe I can
> can't do a no_std hello world
lmao right.
the most trivial thing.
THAT YOU STILL FUCKING FAILED TO DO and blamed the compiler for hours instead of your OWN FUCKING INCOMPETANCE

also even outside no_std, what even is musl.

>>107532003
In the future, some schlub will have to maintain that syntatic vomit. That's what's wrong with it.

>>107536292
Can you link specifically to the posts where that exact thing happened?

>>107534308
How many of these programmers are really dudes?

>>107536295
I'll be 41%'d by then, not my problem.

>>107536325
It is your problem to leave maintainable code behind.

Hopefully, Rust will follow Ada in to mainstream irrelevance.

>>107536301
jera.rs that links to epoll and filitered by no_std hello guy being the same
>>107505247
and original thread:
>>107402251

you literaly complained for hours about muh compiler when the issue was you all along.
and everytime you use "muh concession" i'll know who you are, you are the only retard replying like that even when he lost.

>>107536340
I can't find where exactly what you wrote happens.

>>107536338
No, it's literally not my problem what happens after I'm gone.

>>107531468
I have also been on /g/ for 20 years.. how the fuck do you get by for so long without seeing code blocks in a /prog/ thread?

>>107530230
pro tip: just do injections, WITHOUT antiandrogens.

>>107536346
Read the thread, search for no_std
Dude blamed the compiler for hours because he couldn't build a no std hello world.

>>107536962
>blamed the compiler
where?

>>107537223
here >>107535348

File: 1764913099967144.jpg (107 KB, 636x800)

107 KB JPG

so far this thread has been a bunch of clowns making fun of themselves. pathetic

>>107537235
What do panics have to do with no_std?

>>107537281
NTA >>107536962
but the assumption is you are arguing that the std lib contains a bunch of panicking code. all this would have been avoided if you just mentioned how the compiler "inserts panics" instead of being all smug about it with "very trivial to prove it". again, a bunch of no coder retards arguing dumb shit while trying to be purists

>>107537403
What does stdlib have to do with panics?

>>107537422
what does the compiler have to do with panics?

>>107537429
It inserts them into normal looking code.

>>107537439
show an example of this that's not a compiler bug

>>107537452
Retards really shouldn't try to samefag, their retardation outs them too easily.

>>107537482
retards really shouldn't out themselves deliberately to avoid the suspicion of samefagging

>>107537507
You have no idea how funny it is that you're this mentally ill.

>>107537515
whatever you say dr psychiatrist

>>107537528
If you want examples, go read the rust book for beginners, it shows you simplest and most obvious compiler generated panic right at the very beginning.
As a shill who loves rust, you should be ashamed that you didn't read that part for some reason, but your mental retardation really leaves no doubt in my mind that you're completely honest about not knowing.
And I cannot stress it enough:
GEEEEEEEEEEEEEEEEEEEG

>>107537555
wasted trips. links nowhere to be seen

>>107537579
geg

>>107534759
Nice lie, mentally ill Rust evangelist. Major Rust proponents like mentally ill Steve Klabnik, Hector Martin, and the general behavior of r/rust, is that of doing or publically supporting harassment.

>>107531100
/thread