>>108654488
This pic gets me frustrated as FUCK i cant explain why

>>108654964
Result isn't even valid

>>108654488
Get rid of usize, isize.
Implement your own string and vector using your arena allocator.
Get rid of the other STL crap too.

>>108655562
you realize you can just change allocators right?does your shitty hand-rolled string have support for pmr? no? stfu then nigga

>>108655574
>stl garbage
Stop name dropping ridiculous slop and people will take you more seriously.

>>108655574
std::vector and std::string are horrifically bloated and slow. The assembly they generate is vomit inducing.

>>108654488
Here try this

static void *myvar;

File: trail.jpg (168 KB, 3840x2160)

168 KB JPG

>>108654488
this video got shared on lemmy a couple of days ago:
https://www.youtube.com/watch?v=7fGB-hjc2Gc
this triggered A LOT of COPE from bjarne tards. from hallucinations about it being fully AI generated (got passed denial to the bargaining step eventually, arguing that AI images alone are very bad), to arguments about them being disrespected because the video is too long, to conspiracy theories about the author. nothing about the content itself lol.
i haven't watched it all yet. but this trail return type syntax (picrel) caught me off guard. i didn't know this existed lol. i bet all the junior and sophomore /g/eets arguing "rust syntax bad" here didn't either lmao.

File: blue.gif (25 KB, 704x720)

25 KB GIF

>>108654488
Anon, the problem is not the language, the problem are the ownfart sniffers that write "maintainable" code like this:

https://godbolt.org/z/qK5Tebf8T

>>108654488
daily reminder that c++ doesn't have sum types in its million page spec. so no, you can't have the equivalent of Option or Result, not even with std::variant.

>>108655917
>bjarnetard coper in the wild
>the problem is not the language
lol

File: urw.gif (443 KB, 480x238)

443 KB GIF

>>108655928
Non coder opinion discarded.

>>108655905
>lemmy
45yo tranny hangout

i like _t postfix notation. the problem with abbreviated type naming is that it interferes with abbreviated variable naming.

what is u64? is it a temporary variable or typedef? you cannot tell. other retardation with object/generic naming is out of interest.

>>108655635
Why? What do they do that a better implementation would do differently and why does that produce bad (inefficient I assume) assembly?

>>108656104
>what is u64? is it a temporary variable or typedef? you cannot tell
Doesn't your editor highlight types and variables differently? Next you'll be arguing for Hungarian notation because your editor can't tell you the type of a variable.

>>108656241
std::vector and std::string use this grotesque grow routine which allocates a new array and manually copies over everything rather than using realloc. Most objects are safe to realloc, but the fuck heads who are in charge of c++ have not made it possible to optimize the common case, even thought people have been asking for it for decades. Forcing everyone to roll their own containers.

>>108656296
>which allocates a new array and manually copies over everything rather than using realloc. Most objects are safe to realloc
Even realloc can only grow in place so much before you have to move buckets around. Because you can't tell malloc to reserve VAS without actual memory backing it up.
>unless you're on shitkernels like Linux with their overcommits

>>108656325
I am not talking about grow in place. I am talking about how massively bloated and inefficient the grow routines are. Instead of just calling realloc. It has to instead allocate a new array, then it has to loop through all the objects, copy construct them to the new location, then destruct the old objects.

Also, on some operating systems, realloc is optimized by using paging to move the array to a new address without copying. Which is a massive performance boost for large arrays.

>>108655635
exactly. no argument. foo ass nigga with his half assed, slower and worse version of fucking STL constructs. go back to golang lil dalit, let the real niggas do the real work.

>>108656427
>>108656427
>>108656427
>I am not talking about grow in place.
Yes, you do. Read again:
>std::vector and std::string use this grotesque grow routine which allocates a new array and manually copies over everything rather than using realloc
And about the only area where realloc still strikes is in-place resize. Anything else does exactly what std::vector and std::string do according to your own post.

>I am talking about how massively bloated and inefficient the grow routines are.
Interface issues. Which both malloc and realloc have. If you want them fixed you have to use mmap yourself.

>realloc is optimized by using paging
Now you're paying for the syscall plus the TLB shootdowns.

>>108656427
>I am talking about how massively bloated and inefficient the grow routines are.
Those are defined the allocator. Sounds like a skill issue you're suffering from anon.

>>108656325
>Even realloc can only grow in place so much before you have to move buckets around.
That 'shitkernel' you mentioned can remap virtual memory addresses so that the array can grow in place even though the physical memory is not contiguous. Windows has no equivalent to mremap(2).

>>108655942
you wanna challenge?

>>108656524
>That 'shitkernel' you mentioned can remap virtual memory addresses
>>108656460
>Now you're paying for the syscall plus the TLB shootdowns.

>>108656542
>O(n_cpus) operation is too expensive, do an O(n_bytes) one instead even though n_bytes is orders of magnitude larger than n_cpus

>>108654488
> u64
The new millennium is almost here and there's not even u128 or i128.
Lost cause.

scheme@(guile-user) [1]> (expt 2 10)
$1 = 1024
scheme@(guile-user) [1]> (expt 2 64)
$2 = 18446744073709551616
scheme@(guile-user) [1]> (expt 2 128)
$3 = 340282366920938463463374607431768211456
scheme@(guile-user) [1]> 

>>108656584
>O(n_cpus) operation is too expensive
It sure is. Otherwise we would already see write permission removal for syscall parameters.

>>108656460
calling realloc requires much less instructions than calling new then manually copying the objects, then calling delete. And if the object has a non-trivial constructors its even worse since it needs to do the whole copy construct / destruct dance. The difference is that realloc is one generic routine that works for everything, wheras the new/copy/delete thing is duplicated for every single overload of std::vector

> Now you're paying for the syscall plus the TLB shootdowns.
God you are low IQ. This is the default feature of the memory allocation system, it default feature, not something you specifically choose to use.

>>108654488

using f32 = float;
using f64 = double;

pretty sure those type equivalences are not mandated

>>108656584
One is a one-time cost, the other isn't.

>>108656620
>Otherwise we would already see write permission removal for syscall parameters.
What do you mean?
Do you have benchmarks showing mremap is slower than copying? Because glibc realloc uses it for large allocations and I highly doubt they did that without benchmarks showing it being more performant than a simple copy.

>>108655917
what the hell is going on in that snippet and how is it different to just doing https://godbolt.org/z/afGc6cz6v?

>>108655905
>"rust syntax bad"
The original K&R C parsers from the '70s were far more advanced. Even today ... with languages, operating systems, and project having been invaded by retards ... you don't have to specifically call-out things that look like functions as functions. It's a shame rust's parser was just copied from some school project which received a grade of "C-"

> I Know! Since I'm a fuck nut and can't write a parser to discern obvious functions, I'll abbreviate my community nick name: "fuck nut" and force you to put it front of every function to remind you of how much you hate rust. Now to fix my elevator!

>>108656641
>calling realloc requires much less instructions than calling new then manually copying the objects
You have never ever looked at memcpy, and so I haven't bothered reading the rest of your post.

>>108656646
Why is shootdown not a one-time cost?

>>108656670
>Because glibc realloc uses it for large allocations
Mate, I'm drunk on 60% of a bottle of Gin, so all I'm gonna ask you is how glibc determines when to use the shared heap and when to use separate arenas, and if you can think of use cases where this gloriously blows up in your face.

... and if that's not enough: >>108656692

>2026
>cannot inline forward declare types from nested namespaces
kek
you can't:
void func(const std::vector<struct datatypes::Data>&);
you need to:
namespace datatypes { struct Data; }
void func(const std::vector<datatypes::Data>&);
just because okay???

>>108655985
>45yo tranny hangout
this contains two contradictions with reality as accepted by 4jeet:
1. trannyism existed 20+ years ago.
2. trannies don't ack themselves by the time they hit 40.

<r*ddit space>

unlike /g/, which is 80+ jeet, 10% mutt-tard (no offence), 10% everyone else, lemmy is a very diverse place (in the good ideological sense, not the retarded skin pigmentation sense).
at the center resides freedom instances which federate with everyone, including the semi-connected islands of genderists, commies (real ones, so not genderists*), neoliberals, ...etc.
and then there are national and topic instances...etc. with the programming topic one blocking "politics" from the global feed.
i can see how lack of both jeets and mutt-dominance can be triggering for many here though.
and since you kvetched about something other than the content of the video (how surprising!), i will post a link to the thread, to come back from the diversion, and make bjarne tards seethe harder lol
https://programming.dev/post/49020872

-----<r*ddit footer>----

* what a funny coincidence. i just checked the cool piracy instance. and the hottest topic is a cross-post from a commie/tankie instance catching the neoliberal instance being zios lol

https://lemmy.dbzer0.com/post/67441443

>>108656460
>Now you're paying for the syscall plus the TLB shootdowns
which will still be faster than a large memcpy

>>108656700
Language syntax isn't about ease of machine parsing. Everyone can build a parser that looks ahead until it hits an opening paren, the issue is that function definitions/declarations become *much* harder to search for.
in Rust and any other language that have a dedicated function keyword, you just search

fn funtion

and are done with it.
in C and related language you have to enforce the shitty GNU indentation style, because otherwise it is impossible to differentiate definition/declaration from invocation.
Your post is peak midwittery, and it is plain as day you've never actually designed your own syntax.

>>108656708
God your IQ is so low. You seem to have zero understanding of the concept of functions, and how they work to reduce program size. Yes, memcpy does the same work, but it does it in one place, not duplicated a billion times for every single type you use with std::vector. And also, memcpy is also more optimal then a copy constructor destruction loop which is what c++ enforces, since it does not have a trivially movable type trait. People like you are the reason why c++ applications grow to beyond 100mb.

>>108656700
>parsers from the '70s were far more advanced
what does that even mean lmao, and why is it desirable?
and what are your thoughts on c++ parsing, you know the actual topic of this thread. or just give use your view on the

auto doThing() -> int {
 // ....
}

syntax

>>108656774
>which will still be faster than a large memcpy
Nope. If you have 32 cores (which I have), and they take 1K cycles each (low estimate), you end up with 32K cycles spent. On my machine you'd need a 256 KiB cache-to-cache copy to make up for that.

For a single page.

And unfortunately kernels do NOT support the bulk transfers that true monoliths would encourage to make up for that loss in cycles.

>>108656641
this /g/eet variant of dunning-kruger is quite smth lmao

>>108656791
Go cope someplace else, I'm not interested in your nonsense.

>>108655905
auto doThing(auto& arg) -> decltype(auto) { return arg; }

>>108655905
why is this in 4k

>>108656795
It’s obvious that “auto” means the same thing as rust’s “fn”
… it was designed that way to make it easy to search for functions because I don’t know what ctags are and I write everything in one file without any C++ or ANSI C features except for excessive lambdas and trigraphs like >>108656779 does.

>>108656877
> why 4k
I can’t see it unless it’s in 8k @ 240 fps with 12-bit HDR color.

>>108656255
relying on IDEs and other tools too much, instead of doing actual coding? - nah

>>108656427
the realloc copies stuff around too

> realloc is optimized by using paging to move the array to a new address without copying

ye, black magic. how do you think it works, retard.

--
why this talk went into libraries? since when library must be a part of the language? libc is as much retarded as stl

>>108655905
>that video
don't bother watching it. it's essentially two hours of him ranting about IDE-related issues, non-issues or things that were fixed in C++17 or later.
>auto-complete shows too many results (he literally said this)
>you got to use the "clunky CTRL+F command" (another quote from the video, forgot the exact context)
>nested namespaces are bad (solution: don't nest them)
>template errors are difficult to read (solution: concepts)
it's so bad it is almost funny, but it's moreso tragic knowing this drooling retard spent weeks researching and editing only to make approximately zero valid arguments

>>108656984
>relying on IDEs and other tools too much, instead of doing actual coding? - nah
What a vacuous statement
If you really enshittify the programming experience for everyone with suffixes and prefixes just so that you don't have to learn how to use a tool like global then your colleagues almost certainly hate you

>>108654964
you probably just hate modular, maintainable software, a strong ecosystem, dead simple low-level interop, and lightning-fast executables

>>108654488
c++ is so comfy

>>108656984
> the realloc copies stuff around too
Obviously the work has to happen somewhere. I am complaining about std::vector duplicating the code over and over and over. This is why c++ ends up with 100MB+ binaries, because of all the template bloat. Also, not a single person response chain has acknowledged the overhead of the copy construct / destruct bloat that c++ enforces because it does not have as trivially movable type trait.

>>108656779
you cannot avoid naming by having "fn" keyword in a language. if you only know GNU, then thats your problem

>>108657001
having a coding discipline achives more in coding than having tooling deps. im not prone to retard shaming, hehe.

>>108657031
>This is why c++ ends up with 100MB+ binaries

i put it on a threading model, c++ folks went all in on that. huge static binaries cannot just spawn around. JS pioneered object-based concurrency but NODE is a static ~100MB thread "safe" binary.

tooling too. build with ASAN UBSAN sanitizer-san, feel the dep depth. thats a normal way in there.

>>108656998
>COPE

File: cppformatting.png (263 KB, 783x1788)

263 KB PNG

>>108654488
CPP is alright, you just need to use the correct indentation and formatting

>>108657167
your color theme sucks though

>>108656779
> otherwise it is impossible to differentiate definition/declaration from invocation
I think this is mainly just a C/C++ problem. Its possible to define a C like language without the ambiguous parsing. D for example I believe does not this issue, and can be parsed without needing a symbol table.

>>108655905
These 2 hours could have been spent learning C++ instead of complaining about it.

>>108657138
sigh, since you're so desperate for it: (you)

>>108657012
>modular
without working modules
>maintainable software
as long as the bus factor doesn't hit the only people who know the subset of the lang used from the million page spec and the build procedure quirks involved.... and no future compiler compatibility issues... and no dependency rot.... and... lol
>a strong ecosystem
which you can't trivially use because of build/packaging complexities.
and there is no one ecosystem because dependencies will force you to their subset

>i'm gonna use ze modern c++24 and sheeit
>dependency 1 is C with classes
>dependency 2 has its own wrapper types/constructs for everything
>dependency 3 is RAII-maxxed
>dependency 4 (mythical) use modules/concepts/...


>dead simple low-level interop
only through C ABI like literally every other system or system(ish) language. otherwise, not true and something only a nocoder would say
>lightning-fast executables
not faster than C/Rust/Zig/...
in fact, idiomatic use of OOP makes it slower. "fast" C++ projects are written in C style.

File: file.png (54 KB, 793x946)

54 KB PNG

all you need to see to learn all about this old sad language

File: file.png (7 KB, 760x283)

7 KB PNG

>>108657198
>this is considered impossible to read by cppoids

>>108656998
>>this part of c++ is shit
>just don't use it/do it
>>this other part of c++ is shit
>just don't use it/do it
>>and this is also broken shit in c++
>then don't use it/do it
>>and there are 10,000 more broken things that are a part of the language
>then don't use them/do them
what is this COPE template called?

>>108655905
Rust syntax is objectively bad for human comprehension, it also has bad designs hardcoded.

VIDEO: a retard who stayed within sucha bad (C++) environment for so long coping with its bad-ness - cannot be taken seriously, imagine sitting in barrel with shit and complaining about shit - just get out of there, retard. the later somebody understands something - more retarded he is, meaning, again, cannot take his judgements seriously.

>>108657226
alright, i will entertain your diversion
>Rust syntax is objectively bad for human comprehension
can you point to these "objective" measurements?
>it also has bad designs hardcoded
expand

>>108657200
not helping yourself posting broken code buddy.

>>108654488
usize/isize are uintptr_t/intptr_t, not size_t/ptrdiff_t. Rust does not support distinction of size/address/pointer

>>108657226
>implying there is a real-world good c++ environment
>implying that any two persons would agree on what that mythical environment would look like
lol the COPEs continue

>>108657320
what if my computer has multiple address spaces of varying sizes?

>>108657346
c++ is a language standard, wdym "environment"? you mean an operating system?

>>108657485
Rust stdlib will use intptr_t to represent size, even if size_t can be smaller in C/C++. You can still make your own allocator related types and functions that have distinct size_t type, but standard rust will just assume everything is as big as integer representation of a pointer(not address)

>>108657506
that seems really dumb for a language with such comprehensive polymorphism

>>108657167
what the fuck

>>108657485
You're still only programming one processor.

>>108657499
see the parent comment

>>108657506
>Rust stdlib will use intptr_t to represent size, even if size_t can be smaller in C
Clearly, they never lived through the A20 line days or ever heard of embedded systems. The AS/400 has 128-bit pointers.
rust's "designers" (using the word 'designers' is a stretch, I know) comprehension of how computers and CPUs work isn't even at square one.
They obviously didn't even know enough to formulate questions to ask someone who does know.

>>108657693
he doesn't explain it either

>>108657718
you remind me of old ISO/ANSI worshiping C tards* who used to go "nooo integers can't assume 2's complement semantics because PDP-11 hardware didn't work like that" or some shit.
atypical requirements can be handled at the code generator level. you know, where the crux of arch support is actually done. if that's not workable, then tough luck. there is no need to shit up a language forever because of that retardation.
* not to be confused with everyone who uses C, of which i'm one

>>108654488
t. Rust tranny

>>108657905
speaking of negative integers, was there even any hardware that really meshed with the C standard overflow rulings? i can at least understand "we can't mandate signed overflow behavior" attitude, but coupling it with "yeah unsigned must always cleanly overflow, i mean who the fuck does unsigned saturation lmao" seems contradictory at best
>t. knows nothing of embedded

>>108657546
Polymorphism has nothing to do with integer sizes.

>>108657718
When you are working on embedded software you are mostly likely not going to use stdlib, only core so it's not a problem to define your own types for memory related stuff.
There is only a few niche architectures still in use that have different pointer and address sizes, and just using pointer sized integers for sizes and addresses is not that much of a deal in practice anyway.

>>108656761
>rust tranny advocating for the ultimate bastion of leftist faggotry on the internet
say it ain't so

>>108658385
good morning. congratulations on your literacy certificate. and thank you for your jeet input.

>>108654964
Low IQ people get angry at things they don't understand.

>>108656761
Not familiar with this platform. Looks like Reddit overall. It says it's truly free, but are there stipulations on that? For example, are there any major far-right / nazi instances? What about loli (still legal in most of the US)? Just curious because those are the 2 pain points for most platforms I've seen.

>>108658594
visit any instance. go to the bottom of the page. there is a link to "Instances" (or just append "/instances" to the url).
There you can get a full list of federated and blocked instances. Blocked instances would be those with some technical problems, or considered "out there" in their content/purpose. What consists "out there" varies depending on the instance operator(s). But there are instances that don't like to block anyone unless it's strictly necessary. Those and topic instances (programming, piracy, ...) is where i hang out from time to time.
it's far from ideal, technically and socially. but the transparency (public federation mentioned above and public modlogs) together with decentralisation makes it infinitely better than r*ddit. it's also less botted. and while there are groups of circlejerks, there is no global one.

>>108654488
>template <typename T, typename E>
>using Result = std::variant <T, R>;
Tell me you didn't try to compile without telling me.

i couldn't give a Fuck less about trannies ranting
Still coding in C++ ,lick my assembly output and go suck your Dick-checker ,lazy faggot without a job.

>>108659184
>lick my assembly output
It's bloated and full of unnecessary checks, no thank you.

>>108655905
I only use trailing return types for dependant names in definitions of functions and usually put it on the next line for readability:

template<typename T,<template <typename> concept C>>
requires C<T>
template<typename U>
auto foo<T,C>::f(this auto && self,U && u)
requires C<bar<U>>
    -> baz<T>::template barbaz<U>

>>108654488
>isize
>size that can be negative
rust troons are retarded. inttypes.h naming convention is way more sane and superior to rust's garbage

>>108661636
>>size that can be negative
ssize_t has been in POSIX since before you were born.

>>108661655
>posix is c++
I sincerely hope there's a cure for whatever is wrong with you

>>108657053
>you cannot avoid naming
huh?
>only know GNU
the GNU allusion was a so called example
>>108657175
no. it too does

return_type function_name(arg_list)

for declarations.
and because return_type can be any arbitrarily aliased identifier, the only reliable way of searching for a function declaration is

grep '^functionname\s*('

when following GNU convetions, or the same but without the line anchor, forcing you to individually distinguish between definition/declaration and invocation.
>>108661655
POSIX, the ultimate arbiter of well thought out design decisions. There's a reason ssize_t is outside the standard

>>108654964
I do this in all my software too, why type unsigned int or std::uint32_t when u32 will do?

>>108654488
imagine getting filtered by letters

>>108657239
>alright, i will entertain

the follower trait, 's when someone follows something in hope his thing will be greater one day that never comes. Rust follows C++, in that video, in rewrites. its obvious to mention.

>can you point to these "objective" measurements?

Rust and C++ have the richest punctuation inventories because of module/path (::), generics/templates, and advanced error‑handling operators.
Zig sits between Rust and C++: it adds the @ builtin-call marker and a comprehensive set of compile‑time symbols, while keeping the overall symbol count modest.
Go deliberately minimizes required symbols, relying on a small keyword set and implicit semicolons.
C remains the most compact in both symbols and keywords, reflecting its long‑standing minimalist design.

you can generate a table with keyword counts and their combinations with AI, though it doesnt account for abbreviations and other stuff but may serve as rough value. hardcoded async/await for example, who said that is good? dr.JS?

>>108657346
its kinda non-mandatory aka non-invasive. you may reduce the use of those and do "standalone" builds with a shellscript file. rust comes with a package manager dude, everythings official

>>108662034
The type aliases in that pic are just to resemble Rust for the sake of trolling, not any practical reason.
There's nothing wrong with using aliases to reduce typing though, I do it too. For example if my code will use STL vectors of Foo I might make a FooVec type. If I want to nest those in another vector I might make FooMatrix. But it's to save space/keystrokes, not to obscure the smell of my rotting neovag.

>>108662259
>nothing wrong with using aliases to reduce typing
exactly, you can take the good things from other languges and use them in C++. It's what makes it so powerful

>>108662259
>There's nothing wrong with using aliases
unless it's pointers
anyone using FooPtr = std::shared_ptr<Foo> needs to be bonked with a shovel

>>108662343
Unless that good thing is a clean syntax.

>>108662359

template<typename T> struct FooPtr{
    T value;
    operator T *() { return &value; }
    operator const T *() const { return &value; }
    T & operator*() { return value; }
    const T & operator*() const { return value; }
    T & operator[](size_t i) { return (&value)[i]; }
    const T & operator[](size_t i) const { return (&value)[i]; }
};

Assignment, additive and relational operators are left as an exercise for the reader :^)

>>108662359
if only there was a concept that allows you to know that a type value contains references that could "die" before you realize, and forces that knowledge to be explicit at the type system level.

>>108662246
The claim:
>Rust syntax is objectively bad for human comprehension
The proof:
>Rust and C++ have the richest punctuation
lol
/g/eets are something else. the shallowness of their knowledge is unmatchable, nor is their desire to larp with it.

>>108658199
>Polymorphism has nothing to do with integer sizes.
Type polymorphism absolutely does, what are you talking about?
BitInt(n) in C23 is an example of such polymorphism. In a real type system, it can be completely implicit. Rust literally already does this for integer literals.

>>108663272

1. Visual Clutter
Punctuation marks (braces, brackets, arrows, colons, etc.) are visual tokens that the reader must parse before understanding the underlying intent.
When a language interleaves many different symbols, each line of code contains more “visual noise,” forcing the eye to switch frequently between symbols and identifiers. This slows the mental decoding process.
2. Cognitive Load of Operators
Each distinct operator introduces a semantic rule the reader must remember (e.g., precedence, associativity, side‑effects).
A large, heterogeneous operator set forces the brain to maintain a larger lookup table, increasing the chance of misinterpretation..
3. Keyword Proliferation
Keywords are English‑like tokens that convey high‑level concepts (loops, conditionals, type declarations, etc.).
A modest, well‑organized keyword set allows the reader to map code fragments directly onto familiar programming constructs.
When the keyword inventory expands dramatically, developers must memorize many specialized terms..
4. Interaction Between Symbols and Keywords
Languages that combine dense punctuation with rich keyword sets suffer a compounded effect: the reader must simultaneously resolve a myriad of operators and recall numerous special words.
Conversely, languages that favor few symbols and concise keyword groups enable the reader to focus on logical structure rather than syntactic minutiae.
5. Context‑Dependent Parsing
Some languages allow the same symbol to have multiple meanings depending on surrounding code (e.g., overloadable operators, context‑sensitive delimiters).
This ambiguity forces the reader to consider additional context, raising the mental effort required for each line.
--
7. Overall Impact on Comprehensibility
Higher symbol/keyword density higher initial parsing time lower immediate comprehensibility.
The effect is most pronounced for newcomers and for code that is read infrequently (e.g., legacy codebases).

>>108657172
it's just the Emacs default color theme, except the green

>>108663380
>emacs

says more than enough

>>108663357
>1. Visual Clutter
Rust gets most of this from sepples. They are both bad about it. Albeit, go too far in another direction and you end up with the same noise, it's just not defined by the grammar (see: Common Lisp)
IMO Rust's worst offenders for visual noise are namespace accessors and the horrendous module grammar. Rust code is filled with pimples (pub impl), because web developers have an aneurysm at the idea of an interface living in one place.

>>108657012
>>108662034
It's probably bad practice since some of these might not be accurate under certain conditions and people shouldn't need to learn your weird macro system.

using namespace std

is valid though

>>108663450
using statements aren't macros

>>108655917
>A useful immediately executing multi-shot sender that sends some values through the value channel.
this might be the greatest comment i've ever seen in code lmfao

>>108663357
>LLM reply
lmao
>>108663418
>another anon with uninformed surface take
:: doesn't case any "clutter" mid-code in Rust, because its only idiomatic "accessor" facility there is associated (as in non-method) function calls. And I say "idiomatic", because you could pre-import these functions too. So it's not a hard requirement. But not importing is actually "cleaner".
There another :: "non-accessor" use which your surface knowledge may not know about, which is ::<>. But that's not "cluttery" either when using idiomatic chaining formatting, and can be replaced by defining let bindings with explicit types when needed, when types can't be inferred.
--------
there is no "objective" measure that can ascertain "readability" trivially from the full set of used punctuation. this is true for all languages.
all the collective you can provide is some waffling, and when pressed, LLM replies lmao

>>108663418
>it's just not defined by the grammar
>Some languages allow the same symbol to have multiple meanings depending on surrounding code


its defined >>108663357

>They are both bad about it
>its kinda non-mandatory aka non-invasive.

defined too >>108662246

>>108657485
That belongs to the compiler now, chud, just like memory allocation. You will use whatever size it deems appropriate, and you will like it.

>>108663690
I'm not going to lie, you're not being particularly coherent, so apologies if my interpretation of what you're saying is wrong.
>because its only idiomatic "accessor" facility there is
You're already starting in a space where the double colon accessor was added to the language. A facet of the grammar, by the way, adopted in no vague terms to attempt and make the language more appealing to C++ developers.
The entire fact of the matter is that it was needless, and stupid, just like the addition of methods to a language that is explicitly not built around OOP. Giving method invocation the prime real estate of "." in such a language is definitionally pants-on-head retarded. These are simple, easily observable missteps in the language's UX stemming from bad design decisions. Treating them like the word of god is ridiculous.
>there is no "objective" measure that can ascertain "readability" trivially from the full set of used punctuation
Only if your concept of readability isn't based in an objective measure in the first place.
Are you really just going to retreat like a coward into an epistemic side-argument that you can't even be bothered to form in a sound manner?
Do you really think you're going to convince anyone of your talking points by doing so? Particularly while lashing out and accusing everybody who doesn't agree with you of being an LLM.

I'm not inclined to give you any more attention on this matter. You are a deeply unpleasant person. Trivial doesn't mean what you think it means, by the way.

>>108656774
People really overestimate the cost of basic cache friendly writes and reads compared to syscalls, or even dealing with the allocator locks

>>108656588
Give me one use case for u128 or i128.

>>108664117
Converting HPET timer period from femtoseconds to hz

>>108664154
there are many ways to do high-precision calculations without dedicated large-sized types.
in fact, if you indulged in compression techniques, you will find that methods like arithmetic encoding or ANS work at the theoretical level by storing all data into one number which is either very large (ANS), or requires a large number of float precision bits (Arithmetic).
How does that work? Well, look it up.
>>108664117
and those exist in rust now anyway

>>108655905
picrel gay as fuuuck.

>>108664117
Ipv6, zfs, addresses (virtual and whatnot), hash values, database keys, high precision w/o floats (scaled ints), moving/comparing memory, bitflags, etc. it’s better for every reason 8 bits was better than 4, 16 was better than 8, 32 was better than 16, and 64 was better than 32.
Larger busses, more gpio bits, etc., etc., ad nauseam.

>>108663353
>Type polymorphism absolutely does, what are you talking about?
I'm talking about the difference between pointer and an address. That has nothing to do with polymorphism, it's a property of computer architecture.

>BitInt(n) in C23 is an example of such polymorphism. In a real type system, it can be completely implicit. Rust literally already does this for integer literals.
BitInt(n) is just a family of integer types. It's not means of polymorphism, you can't declare variable or function that can accept multiple different types, do subtyping, etc(that's what polymorphism means).

>Rust literally already does this for integer literals.
Rust has no language level counterpart of BitInt(n). Also literals are values, not types.

None of this has anything to do with the original topic though.

>>108662359
Why?
What if it was SharedFoo?

File: 1774004160446914.jpg (20 KB, 471x388)

20 KB JPG

>>108655905
i fucking loved that video

Linus GOD was 100% right "[...] if only to keep the c++ programmers out"

retarded language

danes = retards

>>108664896
I would like to interject for a moment plz.
Do note that ISO is INTERNATIONAL STANDARD.
The gestalt of C++ wouldn't have been possible without the contribution of people from all corners of the world, who pushed their retardation to the limits to give us this gift.

>>108657718
>Clearly, they never lived through the A20 line days or ever heard of embedded systems. The AS/400 has 128-bit pointers.
And you can't cast pointers to or from integers on an AS/400 because they have tags and aren't integers, which is the whole foundation of how security works on that system. "intptr_t" makes no sense on a computer with tagged pointers.
>rust's "designers" (using the word 'designers' is a stretch, I know) comprehension of how computers and CPUs work isn't even at square one.
It's still better than C's "designers" (they literally can't imagine anything that isn't like a PDP-11 even though they used Multics which wasn't like a PDP-11). C has worse problems with handling pointers that aren't just integers or computers where the smallest addressable unit is a word and multiple characters are packed in one word.
>They obviously didn't even know enough to formulate questions to ask someone who does know.
You're describing Ken Thompson and Dennis Ritchie and projecting. Rust was designed primarily for x86 and ARM. When it starts getting used on different platforms, they will have to support that. Rust people are interested in security, so they probably will want to make Rust usable on computers that have tagged pointers or where pointers are not just integers, because they are more secure. C people can't understand it enough to be able to know that computers that do pointers differently are possible.

>>108661636
>>isize
>>size that can be negative
>rust troons are retarded. inttypes.h naming convention is way more sane and superior to rust's garbage
"Rust troons" is your mistranslation of "Dennis Ritchie" (which does sound similar in a way). It's retarded because it came from C and Unix. Rust uses that for compatibility with C code that uses "sizes" that can also be negative numbers, like functions returning negative numbers for errors, which is a C convention. An example is the read() function in Unix. Rust already has its own way for returning errors.

>>108661944
>POSIX, the ultimate arbiter of well thought out design decisions. There's a reason ssize_t is outside the standard
POSIX is as well thought out as C and C++ (which means it sucks). It's literally just Unix made into a standard, and C/C++ came from Unix.

>>108665673
no, C is more coherent than Posix. Posix is the grotesque combination of multiple early unix-likes, which is why it's incoherent in a way Unix or C(++) aren't

>>108658199
>pointer sized integers for sizes and addresses is not that much of a deal

if youre building a runtime, you dont make integers of size A, B, C, D.., you make an integer. otherwise there will be a situation of complete retardation, now happening with JS runtimes. it simply stuck in the compatibility trap because those designers decided another integer type (BigInt) will be a solution. Rust is an implicit runtime, thus, naturally tries to reduce integer variety.

>>108665673
>It's retarded because it came from C and Unix

everything comes from somewhere. the last video i watched C&Unix bad, was some fag (real gay/fag in rainbow t-shirt with little pythons) complaining about Linux apis (how is it related to those unix philosophies?). modern C code utilizes fixed types, those which end with _t

>>108667038
no, POSIX is more coherent than C. C is the grotesque combination of multiple early BCPL-likes, which is why it's incoherent in a way POSIX isn't

>>108667270
give examples or stay in a retard chamber

>>108667168
>if youre building a runtime, you dont make integers of size A, B, C, D.., you make an integer.
Runtime has nothing to do with integers. Both C and Rust have minimal runtime which you can ommit by using ffreestanding/core and it does not change supported integer types. The later is a language feature not runtime feature. And if course, the distinction between pointer and address has nothing to do with languages and is a property of the underlying computer architecture.

>now happening with JS runtimes. it simply stuck in the compatibility trap because those designers decided another integer type (BigInt)
Number type is a language feature in JS, not runtime related. No matter if you use V8, SpiderMonkey, Deno, etc you get the same number types which are defined by the JS specification, not runtime.

>Rust is an implicit runtime, thus, naturally tries to reduce integer variety.
Rust is a language, not a runtime. It has its own runtime which is typically linked on top of C runtime and can be omitted if you just use core subset.

>>108656524
How does that work? Do you still get good cache locality? Cache is by physical address, no?

>>108657217
>be handyman
>have a spanner
>have a wrench
>have a flathead screwdriver
>have a phillips screwdriver
>task requires me to use screwdriver
>BLDFDSJKREN BUT I WANTED TO USE EVERYTHING GRRRR EVERY OTHER TOOL WAS USELESSS@@@@
This is you.

>>108661944
>can't be done with regular expressions == can't be done at all
Genuine retard.

>>108667652
>spanner
>wrench
>flathead screwdriver
>phillips screwdriver
Sepples provides nothing this useful.

>>108667587
>Both C and Rust have minimal runtime

having runtime written in C is not like being a runtime called Rust, it cannot be the same "freestanding" meaning, ye, like pointer and address - different words, hehe

>Number type is a language feature in JS, not runtime related.

every feature in JS - is a runtime feature, because JS is not a compiler-based, JS is a runtime-based language.

>Rust is a language, not a runtime. It has its own runtime which is typically linked on top of C runtime and can be omitted if you just use core subset.

Rust is an implicit runtime, that is my term to name those languages btw. implicit is because its kinda obscure, for some reason those who use it, try to deny its being a runtime, thus implicit. "core subset" sounds funny dude, what if i use core subset of PHP or Go, will it become language not a runtime?

>>108667716
you can say it about C++ btw, if you dont use exceptions dont use those generators etc, there will be no automated stuff injected in the stack and it could (probably) escape the runtime, but Rust? unlikely

>>108656588
rust has them

https://doc.rust-lang.org/std/primitive.i128.html

>>108664117
there is none. x64 cpus can't even handle the full 64 bits memory range.

>>108667716
The automatic execution of **`Drop` destructors** is fundamental to Rust’s ownership system. When a value goes out of scope, its destructor is invoked to release resources such as file handles, network sockets, or memory owned by a `Box`. This behavior is baked into the compiler and is required for deterministic resource management; there is no option to suppress it.

**Thread‑local storage (TLS)** support is always present on platforms that provide it. The `thread_local!` macro and any internally‑generated TLS for thread‑specific data rely on the operating system’s TLS facilities. Because TLS is a core part of the language’s concurrency model, it cannot be turned off on targets that support it.

The **stack‑based ownership and borrowing checks** performed at compile time rely on runtime stack unwinding for panic handling, but the underlying stack layout and the guarantee that references never outlive their owners are enforced by the compiler and runtime stack semantics. These checks cannot be disabled; they are essential to preventing use‑after‑free and data‑race bugs.

Finally, **type‑based alias analysis** and the associated *strict aliasing* rules are enforced by the compiler and manifest at runtime through the absence of undefined behavior. Rust guarantees that two mutable references cannot alias the same memory, and this guarantee is upheld by the generated code regardless of any runtime flags. This safety property is non‑negotiable and cannot be switched off.

>>108655905
Based
>RMS: “C++ is an ugly and badly designed language.”

>>108664117
https://arxiv.org/abs/1902.01961v3

>>108667716
>having runtime written in C is not like being a runtime called Rust
Rust is a language, not a runtime. Rust runtime is written in Rust.
https://github.com/rust-lang/rust/blob/main/library/std/src/rt.rs

>it cannot be the same "freestanding" meaning
no_std is Rust counterpart of GCC -ffreestanding

>every feature in JS - is a runtime feature, because JS is not a compiler-based, JS is a runtime-based language.
JS is a standarized language and numberic type is defined in its standard. Runtime only implements that language feature and might or might not include some non-standard extensions.

>Rust is an implicit runtime
Rust is a language, not a runtime. It has Rust runtime which is often linked on top of C runtime.

>that is my term to name those languages btw
Learn proper terminology. Language and runtime are not the same thing. Runtime is piece of code written in some language that provides basic facilities for the same or different language to operate in specific environment. Usually it only refers to piece of code executed before main function/code but that depends on context.

>"core subset" sounds funny dude, what if i use core subset of PHP or Go
PHP and Go do not have core subsets. Rust does have a freestanding core subset.
https://doc.rust-lang.org/core/

>>108664298
There are ways of doing high precision calculations with nothing but redstone dust and torches. Still, it's easier to reason about algorithms when you have various integer sizes available.

>>108668099
Rust language produces a runtime, a runtime that is implicit in many ways, one is that those rust cultists deny its existence.

here is the list >>108667776 to see.. same threading model waged but hardcoded now.

btw i think language that produces itself is only a fashion. it is not free, the comprehension is the price. a potential peer who could take that language development much likely adapt for A=>B, rather B=>B

>>108667827
what 128 bits has to do with it? bigger the bag, bigger the price. 64 bits is optimal

>>108667652
>be handyman
>spanner is bent
>wrench adjusts only on tuesdays
>flathead screwdriver has a shotgun trap in the handle which might randomly go off and shoot you in the face
>phillips screwdriver is made out of foam
This is C++.

>>108667660
in practice, yes indeed.
you are not going to derive a workable two-level context-free grammar, the last time that's been attempted was algol 68, notwithstanding that no application can work with those.
So you need to use a LSP every single time, which means you can only make those specific queries that the IDE or LSP addon's creators have graciously predefined

>>108668198
>Rust language produces a runtime
Correct

>one is that those rust cultists deny its existence.
I literally just linked you the runtime in the very post you are replying to. Let's do it again:
https://github.com/rust-lang/rust/blob/main/library/std/src/rt.rs

>here is the list >>108667776 to see.. same threading model waged but hardcoded now.
Everything on that list is obviously wrong but since it's AI generated I am not going to respond to it. If you want to have proper discussion you gotta formulate your arguments yourself instead of asking a bot to think for you.

>btw i think language that produces itself is only a fashion. it is not free, the comprehension is the price. a potential peer who could take that language development much likely adapt for A=>B, rather B=>B
I have no idea what are you even trying to convey at this point.

>>108668261
ok retard

i guess compiling c means solving the halting problem then

>>108665673
cope and seethe

>>108668316
I see you don't understand these terms nor know how to write a compiler
Next post write something sensible, or I won't converse with you any more

>>108668198
> i think language that produces itself is only a fashion
Most languages should be (or actually were) bootstrapped from C, directly or indirectly. There is no (good) reason to delete the head of that chain.
Hell, C++ started out as the cfront preprocessor — generating C code — before exceptions almost killed C++ altogether. Commercial interests had a hand in eventually killing that idea because C++ became impossible to parse and they needed to recoup their losses on the investment of time or buying the Edison parser.

>>108668198
the intermediate multiplication results in a 128-bit unsigned integer. if your attention span is too low to read an 18 page paper, it's a waste of time replying to you.

>>108668369
>Most languages should be (or actually were) bootstrapped from C, directly or indirectly.
There is no reason for other systems programming languages to bootstrap from C.
Rust used to be bootstrapped from Ocaml before it became self hosted.

>>108668369
>Most languages should be (or actually were) bootstrapped from C, directly or indirectly. There is no (good) reason to delete the head of that chain.
They shouldn't need any C at all. Relying on C means you're relying on someone else's compiler you have no control over, when you're already making a compiler. If your compiler relies on C, it's not a compiler, just a "scripting language." FreePascal doesn't use any C. Mezzano doesn't use any C.

>>108657167
I'm gonna hit you