Thread 106402398

Objectively speaking, which one is better?

>>106402398 (OP)

the one you feel good working with

Rust uses a compiler written in C++,
you be the judge what that means

Also sage. Stop spaming threads about that dead troon language that nobody uses.

>>106402429
0% this stat is accurate

>>106402398 (OP)
C++ has the same issues Rust will have unless u have an inflation fetish

>>106402398 (OP)

>The C++ branch drops the "bottom == top" case. That is a bug. Rust’s includes the endpoint and yields an empty iterator if bottom > top

>The C++ code does top + 1 for an inclusive range. If top == INT_MAX this is UB (undefined behavior). Rust’s inclusive range has no such footgun. Signed overflow in C++ is UB during the sum as well. Rust’s i32 overflow is defined (debug panics, release wraps) and can be made explicit with checked_add.

>Rust says exactly what it does: inclusive range, filter evens, sum. Three lines. No sentinel math.

>C++ needs a named lambda, range piping, and a nonstandard-looking ranges::accumulate which may not exist on some toolchains. In standard C++23 you want std::ranges::fold_left. It is verbose.

>Rust’s iterator chain is stable today. C++23 ranges support varies and increases compile friction.

>Rust covers negatives, equal bounds, and inverted bounds cleanly. C++ relies on manual guards and arithmetic that is easy to get wrong.

Rust wins

>>106402398 (OP)
c++ because its easier to use if you know all the footguns. rust if you hate that everything is a pain in the ass to use and half the language is just a terrible mix of template code. Personally I gave up on both and just wait on beef.

>>106402398 (OP)
C++ definitely should receive some prize for taking some of the best concepts in FP and absolutely raping them with the worst syntax imaginable.
At some point they should have just abandoned this shit and stick to what C++ is actually good at.

>>106402446
What, you're not working the enormously vibrant Fortran / Prolog ecosystem?

Rust because C++ committee is Jewish and gay

>>106402398 (OP)
How do we save the tribe?

>>106402398 (OP)
now stop being retarded
int m = bottom &= ~1;
int M = top &= ~1;
int n = M - m;
return n * (m+M)/4;

>>106402901
i guess there is an existential threat against the the popularity of c++ among the hacker news and reddit crowd but other than that literally who cares

>>106402910
this is a midwit response
this is like when fags use n & 1 for their isEven() functions and think they are genius

>>106402901
jajaja penne, well that's a way to know xe didn't troon out

>>106402910
ops left &= .... point still stands

>>106402398 (OP)
picrel. why do people hate imperative code which is fast, easy to debug and easy to understand? Can't the modern programmer follow instructions?

>>106402398 (OP)
Anything is better than the pust abomination.

>>106402398 (OP)
>which one is better?

You can consult the Gartner's "language alignment chart" on the left, which will provide the answers you need.

>>106402398 (OP)
Rust. C++ if you have some killer library you can't reasonably replace, e.g. Unreal or some shit.

>>106403251
>and easy to understand?

On the OP image, the code at the bottom (Rust) is objectively easier to understand.

Still don't let this observation distract you from the fact that Rust is retarded, as C++ is too.

Imperative code is clearer on certain cases but not all, wanting to keep everything imperative is retarded in year 2025 as was also in year 1990.

>>106402398 (OP)
should be bottom..top + 1 in the rust one too. ..= is ok... but it's not a simple gt/lt.

>>106402398 (OP)
>cherrypicking

>>106403471
>doesn't realize why doubly linked lists are unsafe
>doesn't realize you're leaking the safety contract to the user in the C++ example
why are there so many midwits on /g/?

>>106403488
>C++ example
saar, can I talk to your manager?

>>106402573
Assuming someone has an inflation fetish, what is the language they should use? Asking for a friend.

>>106403539
what moron would use C when it doesn't even have templating?

>>106403251
Because the functional interface is objectively clearer. No one thinks you are a genius for using imperative calls ranjeet.

>>106403583
/g/ Cniles are fags who think they are badass because they use void* instead of templates, because muh type safety is for pussies.
Honestly they should just fuck off back to JavaScript in that case.

>>106403488
Explain why doubly linked lists are unsafe and what leaking a safety contract is.

>>106403621
easy to have multiple mutable access or store dangling refs. a loose ass linked list is fine if it's hidden from users, like if you wrote a bespoke LRU (literally the only usecase I could ever come up with in 2025 for a linked list) and never expose your list to the user.

>>106403640
Exposing anything to the end user is unsafe unless you completely lock down your code to the point it cannot do anything useful. At what point do you draw the line and stop trying to be an overbearing parent and start letting people do what they want to do? If people want to do stupid shit, like randomly free a node not using the provided methods and then refer back to that destroyed list later, let them.

>>106403662
not correct. both Haskell and Rust prove this.

>>106403616
Nobody on /g/ is using C, it's all just larpers and freshmen trying to feel smart. Be nice tobthem they wre doomed to live as the permament underclass

>>106403471
somewhat off topic but i think both are cool
the first has a gap moe cool and the other has a natural cool

>>106403662
Also fyi.
C, C++ and Rust all enforce strict aliasing by contract. So anything you think Rust prevents is also, very likely, invalid in the others.

>>106402429
>2021

>>106403583
Morons that created Android, the platform your mom bought you to post on the internet.

>>106403251
>filtered by FP
nothing personnel kid

>>106403771
>Morons that created Android
the same ones rewriting a lot of stuff in Rust?

>>106403251
because loop fusion has existed in gcc and llvm land for some time.

>>106403807
No, different ones. The ones rewriting things in Rust are relatively new and have a short half-life period.

>>106403818
ok? C is still a shit lang for writing reusable containers in though. Really struggling to understand why (You) or anyone would choose such an inferior language when C++ exists.... really the only semi-valid excuse I can come up with is writing stable ABIs and only because platform C compiler output has sort of become the defacto ABI of every major OS for some reason, despite being entirely unspecified outside of different OSes.

>>106403669
It's a shame nothing useful has been made in either language.

>>106402398 (OP)
The C example looks cleaner.
Has actual control structure.

>>106403251
you dont need else{} after a return.
also flip the if and do an early-return to decrease nesting

>>106403251
Because they are idiots.
That code could run on a c compiler, now lets add our complex libraries. with types that create a bit of work round. Look it's a c++ only solution!

>>106403361
I worked as a Scala programmer for a couple years and understand the pitfalls of FP

>>106404038 was meant for >>106403803

>>106403471
>use double linked list C implementation
>*segmentation fault*
>gdb bt only tells you that somehow list_insert had NULL pointer in its inputs, even though you wrote 5 lines of code per call of the function that this won't happen
>oops turns out in one of the function calls you forgot the check
>fix the bug
>now program compiles but for some reason it displays completely corrupted data
>depending on the inputs sometimes it segfaults no reason
>gdb every time tells you the segfault is at a different location each time
>lose your mind
meanwhile with Rust:
>use an automatically growable vector for the program instead of a doubly linked list
>complain in forums and imageboards that you should have used double linked list but Rust makes a double linked list super difficult to implement compared to C where it's just 20 lines of code
>program compiles and works first try

>>106403361
>unironically agreeing with pic rel
https://www.reddit.com/r/golang/comments/y9priy/go_vs_scala_vs_scss/?q=kai_fall&type=comments

>>106404102
This is some premium grade A cope wrapped up in a bunch of invented boogeymen. No one, I mean no one struggles with linked lists, not even cs50 faggots writing their first lines of code.

>>106403471
No usecase for slop like that in 2025, just use a slab and keep indices. A whole pointer is 64 bits which is a big waste.
And hopefully you're not malloc'ing every node, if you do that just kill yourself tbdesu

>>106403251
Imagine having a coding style so trash you spread 8 statements across 22 source LoC.

: 2aligned ( n-n) 1+ -2 and ; \ assumes 2s comp
: sumevens ( nn-n) 0 ( sum ) >r 2aligned begin
2dup >= while dup r> + >r 2 + repeat 2drop r> ;
https://ideone.com/5oMhJ1

>>106402398 (OP)
Rust

>>106402429
>Scratch higher than Ada
Always makes me chuckle.
>Rust uses a compiler written in C++,
rustc is pure Rust. It was originally written in Ocaml

>>106403830
Reminder that Linus is a subhuman midwit and nothing he says should be taken seriously

>>106404364
>retard twitter screencap written by retard who wrote this
who could have guessed.

>>106404102
>complain in forums and imageboards that you should have used double linked list
Got any links?

Absolute retard here who wants to start learning to code. Should i learn rust or C++ if i want to learn coding specifically for making video games.

>>106403903
Your post had been processed by Rust code in order to end up here

I make small program for my self some experimental stuff i like to do and at first i tried Rust because they say cargo is super useful and cool but then when it was time to write code that the LLM gave me it was utter pain, even LLM fight the borrow checker, i ended up in infinite loops of suggestions to fix the constrains exposed by rust so i gave up.

Went from C to C++ my LLM projects just grow and grow right now two projects both have 3k each that work in tandem without any problems or segmentation fault or anything alike, just some stupid problems derived from using old C libraries but if ou tried to use old C libraries in rust you would get a response by the LLM to rewrite it in rust because otherwise there is no way to make it work.

>>106404604
>Should i learn rust or C++ if i want to learn coding specifically for making video games.
Learn C# then.
Rust is pretty much unusable for gamedev unless you are hard locked on using Rust for everything. C++ is only marginally better and still mostly useful in areas you are not going to need when you are just one guy making games.
Pick Unity, Unreal, Godot, GameMaker, RPGMaker or whatever makes most sense for the kind of games you want to make. And learn whatever language is recommended for that engine.

>>106403251
This code is harder to reason with.

in c++ thats just
int calculate2(int bottom, int top)
{
if (bottom > top)
return 0;
return bottom % 2 ? calculate2(bottom + 1, top)
: bottom + calculate2(bottom + 1, top);
}

>>106404819
the indentations got fucked up
int calculate2(int bottom, int top)
{
if (bottom > top)
return 0;
return bottom % 2 ? calculate2(bottom + 1, top)
: bottom + calculate2(bottom + 1, top);
}

>>106402398 (OP)
In Java this is just :^)
static int calculate(int bottom, int top) {
return range(bottom, top).filter(i -> i % 2 == 0).sum();
}

>>106404625
>Rust
>vibe coding
Lmao, ngmi
LLMs produce Rust as if they were C++ newbie and then used some transpiller. By no means it is idiomatic code and that's why AI gets filtered by borrow checker so hard.

>>106404875
languages that cant be handled by an LLM are domed to fail

>>106404625
>>106404929
holy fuck. LLM schizos are somehow making this board worse than I can imagine.

are you the same fucking retard who posts LLM discussions as your argument talking points?

>>106404604
You can try learning Godot, also known as Godon't, the meme game engine for trannies and retards. It's lightweight, FOSS, easy to use, definitely the simplest way for a beginner to make a game. It uses its own language, but once you learn the fundamentals, all languages are the same, and language-specific knowledge doesn't matter that much.
If you really want to learn a real language, then do Unity and C# instead, but Godot is more approachable and simpler in my opinion.
People will try to meme you into using C++ or C with raylib or similar crap, but don't listen to them. Start with Unity or Godot.

>>106404365
try using linked lists in anything more complicated than 1st year university projects sweetheart

>>106404572
>br*ce
stopped reading there

>>106402429
>Rust uses a compiler written in C++, you be the judge what that means
it means you're full of shit
Rust compiler is written in Rust

>>106403251
I can look at OP's image and quickly understand what it's doing within a second. I can't with your pic.

>>106402398 (OP)
>Rustranny
>'top' and 'bottom' instead of 'start' and 'end'

>>106402398 (OP)
int sumEven(int bottom, int top) {
if (bottom % 2 == 1)
bottom++;

var total = 0;
for (int i = bottom; i <= top; i += 2)
total += i;

return total;
}

So hard!

>>106402398 (OP)
Am I the only one who thinks this looks like utter shit? Like how do you even read this code? Makes absolutely no intuitive sense. Maybe it's for the better, for gatekeeping plebs like me. But still, it looks like crap.

>>106406548
It looks like it's from a cnile/code_report talk

In Beef it's just
int Calculate(int bottom, int top)
{
return (bottom ... top)
.Filter((x) => x % 2 == 0)
.Reduce((x, acc) => x + acc, 0);
}

>>106406771
More arrow
int Calculate(int bottom, int top) =>
(bottom ... top)
.Filter((x) => x % 2 == 0)
.Reduce((x, acc) => x + acc, 0);

NTA, but >>106406623 will always run faster than either >>106402398 (OP), except maybe if you use Assembly.

It's not worth it to switch to Assembly for speed,
it's not worth it to switch to Rust for safety.
Face it, C is here to stay.

in BQN this is just
+/ (2 = 2 | range) ⊸/ range bottom + (up - bottom + 1)

>>106406807
Rust generates a pretty efficient code tho.
It can even vectorize the loop with SIMD and inline the lambda.
https://godbolt.org/z/eW6T5KrTW

>>106406915
"C++[sic] generates 'a' (?) pretty efficient code. LLVM[sic] can even vectorize the loop with SIMD and inline the lambda"


FTFY

>>106402398 (OP)
Fuck you retarded faggor kill yourself
int sum = 0;
for(int i = bottom + bottom%2; i <= top; i += 2) sum += i;
return sum;

>>106402398 (OP)
Question is, if the project wasn't pozzed with literal fudgepackery, would Rust actually be a viable option to decadent slop like C++? Replacing C is totally out ouf the question; not gonna happen, neither does it need to happen.

>>106407810
No sane person uses a language without collection classes or generics

>>106408091
Can't think of anything I ever wanted or needed to do that was best served by the use of generics, but I guess that's the industry standatd.

>>106407810
Rust is just modern c++ except done without legacy and the committee.

>>106406915
Based. Rust fucking won.

>>106405180
Based Bruce still dabbing on crimes even in death

>>106402398 (OP)
The one that the programmer did a better job with, the only thing an enduser cares about is the program working.

>>106404102
never heard of valgrind I see
>>106404484
pretty much though
embedded systems? basically don't ever allocate memory to begin with
pc programming? most things don't need it, when you do just allocate a large chunk every so often. allocating memory for each instance of an object will destroy your performance.

>>106402398 (OP)
Rust would be the perfect language if not for the borrow checker.

>>106406915
https://godbolt.org/z/96q4qn7cK :|

I'm beating Swiss Table
written in Rust btw

>>106409508
Based

>>106402398 (OP)
You Only Need Java
YONJ
All other languages are deprecated in the current year

>>106409230
so if it was a completely different language

why do people want functional imperative langues. you loose all elegance, and get worse performance than just writing the imperative "way".
(define (calculate bottom top)
(if (> top bottom)
(apply +
(filter even?
(iota (+ (- top bottom) 1)
bottom)))
0))

>>106410150
Why does lisp manage to be the most abysmal code every time

>>106410161
i was following ops method, here is a better approach that imo looks more stylish
(define (calculate bottom top)
(cond
((> bottom top) 0)
((even? bottom) (+ bottom (calculate (+ bottom 1) top)))
(else (calculate (+ bottom 1) top))))

>>106402398 (OP)
Without really knowing much about either, at least the C++ sample is self explanatory in what it does (to me).

>>106402398 (OP)
int calculate(int bottom, int top) {
int sum = 0
for (int i = bottom; i <= top; i++) {
sum += i * (i % 2)
}
return sum;
}
Typing is easy, debugging is hard.

>>106410150
Rust functional code is pretty fast

>>106410161
>hand written AST
isn't it obvious?

>>106409508
>t. writes hashmaps since more than a month
such is the power of rust

Python is better
sum(filter(lambda x: not x&1, range(bot, top+1))

>>106404929
Quite the opposite.

>>106410223
you are an odd one

>>106402398 (OP)
They're both shit.

>>106409230
I don't think so, but yes the borrow checker should be tied to the type, something like:
mut borrowable Vector = ...

>>106411358
>sum(filter(…))
>not .filter().sum()
kys jeet

>>106402398 (OP)
In point-free ML this is just
fun even x = x mod 2 = 0
val calculate = foldl op+ 0 o filter even o range


In Haskell it's
calculate bottom top = sum (filter even [bottom..top])


Rust really did itself a disservice by losing the ISWIM syntax. Probably my biggest gripe with the language (other than the dogshit module system somehow even more a fuck up than Haskell's)
As a sepples programmer, no I do not feel at home in this language just because you made it the same glyph soup. I loathe the glyph soup. It's a constant background radiation of annoying, worthless keystrokes and syntactic noise. I was never going to feel at home given the focus on safety, the affine type system, and the billion other far more important ways Rust diverges from the C/C++ family in the first place.

What the fuck were they thinking?

>>106402398 (OP)
C++ is simply better at everything. I love it, feels like breathing when coding.

>>106413417
I fucked up that ML example but whatever

>>106413442
>modules still dont work and arent tied to namespaces
>standard library just puts everything in std without dividing std into smaller namespaces
>standard library classes are snake_case
inferior language, java won

>>106411358
not pythonic enough.
sum([x for x in range(bot, top+1) if x % 2 == 0])

>>106413469
Drop the brackets, it's cleaner
sum(x for x in range(bot, top+1) if x % 2 == 0)

>>106411358
I hate list comprehensions and single line lambdas so much it's unreal

>>106413469
>>106413497
fucking hate that jeet sõyboy word pythonic
>saar you have to make it PYTHONIC(tm)

>>106403251
Code like OP exists because functional programmers have convinced standards bodies that everything should be a function and that basic constructs should be avoided unless necessary
I don't think they're entirely wrong as function names convey intent better than most other types of code, but for the simplest operations there should be thought put into whether or not it's worth using a function as apposed to a loop

>>106413640
>there should be thought put into whether or not it's worth using a function as apposed to a loop
Any time it makes core more readable it is worth it.
For example Iterator::for_each is virtually never better than a for loop. But a simple fold or reduce and especially chaining and zipping is nearly always better done in functional way.

In real code, you should mix both approaches to archive the most clean code possible.

>>106413660
>For example Iterator::for_each is virtually never better than a for loop
Except when it optimizes better

>>106409330
>https://godbolt.org/z/96q4qn7cK
is crisper than
>>106406915
>https://godbolt.org/z/eW6T5KrTW
hence another point to
>>106406807
>will always run faster

Also, the C version can also be output with the gcc v13.4 instead of clang used in the example above.
Also, this >>106406623 becomes this
https://godbolt.org/z/bKa9dq5r6
and seems unique, and is likely the most performant, since it skips the useless iterations, which at a quick glance the compiler does seem not to optimize away in the single-increment loops).
(Though "var total" should be "int total" to compile.)

Then there's also the purely arithmetic solution, i.e. there is a formula with which the output can be returned in one or two arithmetic operations.
Some are mentioned here, but I'm too lazy to verify their correctness, you do that.

Instead of realizing all this, they went and created an entire new language instead and are on crusade to rewrite all software in it.
lol.

>>106413708
Depends on language, compiler and enabled optimizations. I am talking just about code readability in languages that mix function and imperative programming.

>>106413626
not all of us are dalit like you.

>>106413442
It's ironic that Java was meant to be less complicated successor of C++ and yet in 30 years neither did Java replace C++, nor did C++ fix any issue, which led to the creation of Java.

>>106413760
I mostly agree but it can be convenient to cut down line count and recognize what you're operating on.
I've ported a lot of C code which does batch processing where I could do an iterator chain with for each in 1 line that'd be 3-5 lines in C. I think it's fine to use there, it's when the inner for_each is as many lines as a for/while that it should be avoided.
for(i = 0; i < len; i++) {
array[i] += /*op*/;
}

array.iter().for_each(|x| x += /*op*/);
There is an expressivity benefit that you may see patterns that can be optimized or combined when they're single line chains instead of bracketed loops. I've found performance gains when noticing disjoint operations that resulted in fewer iterations over a collection because the work could be combined or re-ordered in a way that would be doable with loops but not as obvious.

You Only Need Java
YONJ

>>106411350
obsessed with me
I have updated benchmarks btw, but I won't post them

>>106403251
It's obviously faster to take 30mins understanding the functional APIs in 3 lines of code than 2 minutes writing 10 lines of imperative code

>>106414792
>take 30mins understanding the functional APIs in 3 lines of code
Retard?

>>106402398 (OP)
Both are bad because they lead to integer overflow without any error

>>106415474
Uh no? The Rust one will produce an error if an integer overflow occurs. Are you stupid?

>>106406915
Even if it's efficient its worse than >>106406623
, which proves that idiomatic rust gives worse performance. Its even worse if you replace % 2 with a non-power of two value

>>106415556
I meant an error that you can catch dumbass. The code is bad because it can easily crash. You should never run it on user data.

>>106415556
only on debug builds
he is correct, I think this is a bad decision as well