Rust doesn't offer anything over C++ with smart pointers, move semantics and the automatic and safe memory management that they provide.
>change my mind
Rust doesn't offer anything over C++ with smart pointers, move semantics and the automatic and safe memory management that they provide.
>smart pointers
>safe memory management
lmfao
Rust is fricking ugly and stupid on so many levels.
Hype coders probably already switched for the 10000000000 time, troons love it because it's holding their hands,jeets like it more than python which is understandable, but not a single seasoned dev would ever use this peace of castrated shit.
C++ is uglier
lookism is midwit ideology, syntax isn't important, languages should be only evaluated on merit
Cope
> hand holding
A year away from IQfy and I see people still have never used the thing they complain about.
Rust code is actually ugly as frick.
C++ has shitty tooling. Cargo is nice, and rusts more restrictive syntax makes it easier to use smart ide features like autocomplete.
>automatically updated includes
Terrible idea
Who's idea was that
It's like using AUR for kernel and drivers without reqding PKGBUILD.
As I said, rust devs are as stupid as the language itself.
cargo dependencies are not automatically updated
it's one command to update all of them, no built in support to see changes, you just have to assume that it's not a backdoored patch, you will still waste time checking things if you care about security, by that point you may aswell audit and manually include each of them separately
Were package managers that promote keeping the source code of dependencies outside version control and without reviews and just blindingly trusting that a new version doesn't include a security risk a mistake?
yes they were, remember that xz-utils was nothingburger in the end, but on something like cargo it may have ended badly for a lot of people
do cppcels know that there's dozens of undiscovered xz-utils tier exploits active right now letting chinks frick opensorescels in the ass?
If you can't prove that you're a mossad agent right now, shut up.
The point is they will do same thing C devs did for 50+ years, all these gay managers are just for webshit garbage that does not matter
better than some random build script made 15 years ago that nobody knows what it does
non sequitur
>implying companies update their dependencies
>implying companies will use cargo and pull code directly from crates.io
what even is your point?
>Rust has Cargo
C++ gets out of my way and lets me use portage. Shut the frick up midwit.
C++ move semantics are a footgun if you use them wrong. Rust makes it a compiler error if you use a value after moving. The real benefit for Rust over C++ is Cargo, however.
Portage is not available for every platform which your users might build their program on. Do you want to include library installation instructions for every Linux distro, plus Windows and MacOS? Or would you rather let them run a single command and let the build script handle the problem for you?
I am not responsible for your moronation.
>The real benefit for Rust over C++ is Cargo, however.
I hear that. I'm getting convinced that rust is offering a real improvement over c and c++. It's weird how no one in all these years made a pip, go get, cargo, or even npn or mvn like package management system for c++ and how building c and c++ boils down to custom makefiles or even worse custom abstractions over makefiles that are platform specific (and most often incompatible even within variants of the same platform) and still really a lot on dynamic linking (frick that) or, even worse, the gate keepers of Linux distros.
because C and C++ have no authority for that, there's boomer comittee that only determines standard, then people go and do whatever they want independently
And that's a good thing, frick your pip, go get, cargo and npm malware full of backdoors and supply chain attacks.
>And that's a good thing, frick your pip, go get, cargo and npm malware full of backdoors and supply chain attacks
I hear that too but don't act like c and c++ don't have supply chain attacks. Xz happened a few days ago and surely more like that are around since everyone is doing whatever the frick they want with custom unreviewable stuff.
xz dev had to bother debian devs to include it, now think about what I have to do to release malware on cargo, that's right, nothing, I can just create account anonymously, then start pushing, absolutely noone reviews my code before it shows up on crates.io and people can download it, I could pwn tens of thousands of people before anyone reported it and it was taken down if I was author of popular rust library then one day nuked my repo and replaced it with malware and pushed it with genuine looking patch notes
vcpkg with manifests and exports is kind of ok. it sucks that you have to rebuild everytime but again, with exports it's not really that bad as you can just build once and keep the export.
now that I think about it, I've never really used Conan (doesn't provide the package I want). is it better? why is it worse than cargo let's say?
there's probably nothing wrong with it, it's just not as popular because there's no father figure telling every baseddev to use it religiously and nothing else
>why is it worse than cargo let's say?
I don't know. I made this thread to find viable alternatives to rust because I dislike the syntax and the mentality behind rust (rewrite everything, muh safety) and honestly I would like a language that won't promote leftpad() madness (I feel like cargo will have an attack like that soon) but I also want to avoid dynamic linking and makefile or cmake madness.
But honestly I think I will just deal with cargo to avoid cmake, null pointer exceptions and 100 line error messages for a simple typo.
just use meson or make directly if you don't like cmake
>imagine if you were forced to use one of those and not any other
lack of "just import it through global package manager bro" support is what prevents leftpad mentality in C and C++
I have used Conan recently, and while it's better than nothing, or doing VC through submodules, it's still more of a PITA than it should be.
>all the docs tell you EYH THIS IS OUTDATED, PLEASE USE CONAN 2.0
>switch to Conan 2.0, try to install stuff
>"Sorry this recipe hasn't been ported to 2.0"
Mostly the problem Conan faces is that there isn't a standard way to organize a C++ package, so recipe writers have a lot of work to do for every recipe.
Same thing with CPM. It's very lightweight and the concept is cool, but if you try to include Apache Arrow for example, you face the problem that Arrow isn't compatible with CMake's FetchContent, because they used a bunch of reserved CMake variable names that leak everywhere and frick up the ExternalProject build.
>>all the docs tell you EYH THIS IS OUTDATED, PLEASE USE CONAN 2.0
jej they NEVER learn
At this point all I can say is Install gentoo
>what if other distro user needs it?
dunno, package it in flatpak or something, they love bloat
>At this point all I can say is Install gentoo
Great, so you replaced a language provided package manager with a distro provided package manager and added some new gatekeepers that add their own patches. I'm not saying you are wrong though, the status of programming in 2024 is a huge mess without any chance of improvement because no solution or even suggestion exists.
>serious answer to suggestion to install gentoo
just how fricking new are you?
As this fine anon
just said gentoo (actually bsd port inspired system) is perhaps the only thing that could bring order to the chaos of programming in 2024. Unfortunately binary-first anti-compiler distros like red hat and debian "won" (the tragedy of not having build essential and gcc in the default install or more regrettably splitting binary packages in run dependencies and dev packages can not be understated) and Gentoo got associated with -O3 -funrollloops ricers but now I'm starting to reconsider and maybe this was an orchestrated plan and false flag attack to destroy Free software and computer science from within.
gentoo caved and started supporting binpkgs for every package almost since last year by the way, there's very little arguments against gentoo other than "I'm a dum consumer and want it to work like windows".
>I'm a dum consumer and want it to work like windows
There is nothing wrong with this in principle but GNU/Linux distros shouldn't have caved in and tried to be like windows, meaning wasting years promoting
>binary installations are good (tm)
>compiling from source is BAD
>NO WE MEAN IT DON'T COMPILE FROM SOURCE USE OUR BINARY PACKAGES CVCK
>dev headers/sources and build tools should not be installed by default, enjoy using an """open source""" system where you don't have the tools to build everything you use installed by default and it's often more difficult to build, install and use open source libraries from the latest development commit than a windows dev could do on visual studio with minimum fuss
>THE TERMINAL IS BAAAAAD WE SHOULD TRAIN USERS TO BE AFRAID OF THE TERMINAL AND THE MAKE COMMAND BECAUSE MICROSOFT WINDOWS USERS DON'T COMPILE FROM SOURCE
And here we are now, Linux is almost as bad as Windows, it's a huge bloated inauditable mess of systemd and xz backports and the whole thing is such a shithole we had to extend chroot into containers (which in turn promoted even more the idea of binary distribution and NEVER LOOKING AT THE SOURCE OR BUILDING FROM SCRATCH) just to sidestep the crap in modern Linux.
I'm stopping, this thread is depressing, it's so over.
language package managers exist only because distro maintainers and users are moronic, ebuilds are easy to write by the way, I
>inherit meson
setup
>DESCRIPTION
>HOMEPAGE
>SRC_URI
>DEPEND
>RDEPEND
and that's end of file because actual process to building meson packages is scripted already and it only gets complicated if you want to add use flags for every feature
>muh gentoo is just meme guise, it's not the best distro or anything!
have a nice day zoomer
I think you might have an assburger's
ah then I'm glad to use vcpkg. it's super minimalist, I often just use it as an easy way to get the headers I need. I guess recipes can get outdated but it's all just cmake and you can overlay any ports if you want to.
(and by that I mean, get the headers without actually using vcpkg for my project)
Didn't try vcpkg. Tbh when I tried Conan I was trying to do non-trivial stuff (compile with a recent GCC on an old debian) and it gets kinda complex.
>C++ has shitty tooling.
>Cargo is nice, and
>rusts more restrictive syntax makes it easier to use smart ide features like autocomplete
Nice, that's some nice arguments although they are basically the same: "C/C++ tooling sucks".
C++'s move semantics leave the value in an unspecified state, but still usable, so undefined behavior if you use it afterwards. Rust's move semantics can either leave it inaccessible which is faster and less error prone, or in a well defined state (using std::mem::take) which is like C++'s move but without the undefined behavior if you use the value afterwards.
it's not undefined behavior to use value after you moved it, if it is, your code is shit and you should have a nice day. You can move std::vector then push more elements into it, it will allocate a new buffer, because now it's a new vector.
>it's not undefined behavior to use value after you moved it
anon please
In C++, move is not some magic troony thing, it's just a special optimized copy that copies contents from one lvalue to another as efficiently as possible. std::vector move is literally copying size, capacity and pointer to data into another vector, then resetting it to 0 from the vector that was moved from. You don't understand how C++ works, shut the frick up rustroony.
>because now it's a new vector
Not necessarily. The compiler may give you a new vector, but it doesn't have to because move leaves it in an unspecified state.
there's no actual "new" vector, it simply never disappeared
also it's unspecified because it would be moronic to force anything, you ignore that it must be valid. For example std::vector will have its constructor run when it goes out of scope, how do you imagine a destructor will work unless its data is nullptr, and capacity/size is 0? If it wasn't set to that, it would be UB for destructor to run.
And this is not an assumption, that's how it was designed to work, it is valid, therefore it's safe and not UB to call any function that has no preconditions, for example push_back to moved from vector is never UB.
I should know better than to reply to utter morons larping as C++ knowers but
>Move is undefined behavior
Type(Type&& other) {
>Be me
>Defining behavior
}
I eagerly await your brain damaged, delusional reply.
not him, but that's not what he meant by it
There is nothing else that he could've meant.
Anything and everything related to the behavior of a move operation can be DEFINED inside a move constructor or operator=.
It's not magic, it's just a function.
he clearly wrote
>after
The state of the moved object after the move operation is entirely defined by the behavior of the move constructor.
If only you C++ experts could do 30 seconds of research before larping, but I understand it's a high bar.
I never wrote that he wasn't wrong. Already explained how it works ITT, noone read it btw.
Well then I apologize for lashing out at you when you're not the target of my anger.
>for example push_back to moved from vector is never UB.
I really should've written
>for example push_back on std::vector is never UB
If it was UB at any point, it's because vector is invalid state and STL has a bug that needs to be patched.
Cargo is pretty nice. I hate all the make, cmake, whatever the frick make that C/C++ has
Also, actually, pkg-config is basically standard thing for C and C++ libraries, just everyone is afraid to talk about it for some reason.
you can call pkg-config binary from Makefile
you can import .pc files in meson and cmake and many other build systems
any of these can generate .pc files to be used the same way for libraries that you build, it all just works, it just doesn't have mechanism to hurr durr pull in everything at once
If C++ was salvageable Java, Go, Rust would never have happened. There is place for C and C++, kernels, interpreters, compilers, places where you make everything from scratch, but for higher level applications use Java, Go, Zig, Rust.or one of the dynamic interpreted languages.
midwit take, people create new languages everyday just because it's cool or something, some just happen to stick
Languages stick only if they solve problems people have
all languages are tools for solving problems, I almost forgot to mention that people create DSL's frequently too, and they do solve problems.
>Languages stick only if they solve problems people have
The problem C solves:
>code is too reliable and doesn't have enough buffer overflows
problems that C solves were solved before you were born, zoomer, now it's just legacy, and fizzbuzzer larping
yes, and?
>problems that C solves were solved before you were born, zoomer, now it's just legacy, and fizzbuzzer larping
They were solved before C was born. C unsolved the problems.
you don't know anything about software and it shows
projects like systemd and wayland and companies behind them were always going to make their own personal windows competitor with Linux kernel.
>C unsolved the problems.
>humanity went to the moon before C and EUNICS and with with copper wire weaved programs that didn't crash and had advanced features like virtual machines, self healing, asynchronous non blocking programming and advanced io that modern programmers often only dream
>then C happened and more than have a century later we have null pointer exceptions, segmentation faults and backdoors in 2024
How deep does the rabbit hole go?
>computers never crashed before c
The absolute state of the trans mind. Also: before C there was nothing like your baby high level Python/Java nor Rust. You wouldn't be capable of working in what they had available to them.
>languages lower level than c
>often have to work in assembler
>punch cards
>teletype machine printouts
>white men planning every last detail before entering the code because punch cards suck and take a team to prepare >basically the ultimate racist patriarchy waterfall development team
That last point, btw, is why really robust code was really robust. They didn't accept "coders" wearing thigh high socks. They didn't have agile or scrum masters or codes of conduct.
Trigger warning: picrel can give trannies nightmares.
>before C there was nothing like your baby high level Python/Java nor Rust.
>so you claim to be a woman? and you have special pronouns? yes...could you wait a minute while i make a phone call?
>The absolute state of the trans mind.
See
>Also: before C there was nothing like your baby high level Python/Java nor Rust.
Lisp, APL, BASIC, SNOBOL, PL/I, Prolog, Simula 67, Algol 68, and Smalltalk 71 are all older than C.
>You wouldn't be capable of working in what they had available to them.
It's easier to write secure code in assembly than it is in C.
men planning every last detail before entering the code because punch cards suck and take a team to prepare >basically the ultimate racist patriarchy waterfall development team
Which is literally the opposite of how Unix and C were developed. This is the biggest thing that C and Unix people complained about with other systems like Multics.
>Lisp, APL, BASIC, SNOBOL, PL/I, Prolog, Simula 67, Algol 68, and Smalltalk 71 are all older than C.
Out of that list only two are kind of valid examples.
>It's easier to write secure code in assembly than it is in C.
>t. has never written secure code or assembly
>Which is literally the opposite of how Unix and C were developed. This is the biggest thing that C and Unix people complained about with other systems like Multics.
Yeah, they were hippies, and still better programmers than the she/hers crying about C.
My pronouns actually are you/were.
I can't tell if that's a self own, a cry for help, or a pathetic attempt at a threat.
>Out of that list only two are kind of valid examples.
All of those are higher level languages than C. All of them except for PL/I and some versions of BASIC had garbage collection.
>>t. has never written secure code or assembly
You are not using null-terminated strings in assembly and your assembler doesn't assume things about your code that change what you wrote based on nonsense undefined behavior rules.
>Yeah, they were hippies, and still better programmers than
I don't think they were better programmers than people who make better programming languages.
>the she/hers crying about C.
See
. The only crying from she/hers is about people not worshiping C.
>>Out of that list only two are kind of valid examples.
>All of those are higher level languages than C.
I did not say "no languages higher than C", I gave two very specific examples of modern languages with no real equivalents back then. Learn English.
>You are not using null-terminated strings in assembly
>MUH NUL TERMINATORS!!!
Have nothing to do with anything. I agree it's a bad design choice for robust string processing, but it wasn't intended for that. It was a dead simple way to indicate EndOfLine in terminal and simple I/O input. It kind of grew from there beyond intent, which happens.
>and your assembler doesn't assume things about your code that change what you wrote based on nonsense undefined behavior rules.
Rhetoric without example. Discarded.
>I don't think they were better programmers than people who make better programming languages.
Your definition of "better" is "holds my hand." Name your better language and we'll see if it can solve certain problems as quickly/efficiently. Only modern, popular languages that might rise to that challenge (depends on the problem) are C++ and (I'm vomiting saying this) Rust.
>The only crying from she/hers is about people not worshiping C.
Nobody tells you to "worship" C, just stop flooding IQfy with your ignorant opinions about it.
>It kind of grew from there beyond intent, which happens.
you had 51 years to fix it but Cniles are incompetent
>Prolog
My beloved
>basically the ultimate racist patriarchy waterfall development team
>That last point, btw, is why really robust code was really robust. They didn't accept "coders" wearing thigh high socks. They didn't have agile or scrum masters or codes of conduct.
That's exactly my point. Modern programming scene is a mess, the peak is in the 60s before Unix and C and Rust is just an even bigger mistake than C.
>verification not required
even really robust and reputable software is broken
>linux close syscall can be interrupted by a signal
>you should not try to close again
>zig
Does zig have a package manager like cargo or a proper build system?
No, because there are no packages to manage
>sar, pls do the needful and use java sar
Java sucks on so many levels that I would rather use Rust.
C++ move semantics are atrocious and difficult to debug. They're why I moved to Rust.
>Rust doesn't offer anything
End of.
This thread though shows that cargo and a standard build system without dynamic linking madness is real benefit or at least something that rust offers over c++.
Except any self respecting company disables crates.io and basically does what C++ programmers do anyway.
And I'm implying that anyone uses Rust in the real world.
Brother, do you even understand what move constructors actually do?
In the context of unique smart pointers I think I understand, they invalidate the existing pointer and move the ownership to another scope which then had the responsibility to transfer it back or let it be freed, isn't this what rust's borrow checker is doing?
I have come to the conclusion that I don't really like c-syntax but will tolerate it for JS and that is about it. Its a lot of typing to do anything in most of these languages and they keep mixing too many symbols and words. C++/C/Rust etc the only difference to me is how much typing I have to do.
>typing is hard
you probably find thinking before you type completely impossible
https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html
You can now be sure that it is not genderfluid.
troony thread (trannies making threads LARPing as /C/hads to incite controversy and drama).
Reminder that trannies need the drama and attention, otherwise their language goes unnoticed and forgotten into oblivionfrick.
Don't argue with the troony.
Don't reply to the troony thread.
I won't respond to any reply. Have a good day.
Out.
>troony thread (trannies making threads LARPing as /C/hads to incite controversy and drama).
"/C/hads" have always been trannies. All C threads are troony threads.
https://en.wikipedia.org/wiki/Mary_Ann_Horton
>Mary Ann Horton (born Mark R. Horton, on November 21, 1955), is a Usenet and Internet pioneer. Horton contributed to Berkeley UNIX (BSD), including the vi editor and terminfo database,[1][2] created the first email binary attachment tool uuencode, and led the growth of Usenet in the 1980s.[3]
>In 1981, Horton became a Member of Technical Staff of Bell Labs in Columbus, Ohio. At Bell Labs she brought parts of Berkeley UNIX to UNIX System V, including vi and curses; as part of the work on curses, she developed terminfo as a replacement for termcap (most of this work shipped as part of SVR2).[7] In 1987 she joined the Bell Labs Computation Center to bring official support for Usenet and Email to Bell Labs.
>Horton's 1990 book, Portable C Software[18] became a popular reference for programming in C.[citation needed] It outlined functions and programming techniques that could be reliably used on many different types of computer systems, and which methods were unportable.
>Horton is a transgender woman. Adopting the name Mary Ann in 1987, Horton founded Columbus' first transgender support group, the Crystal Club,[20] in 1989. In 1997, she joined EQUAL,[21] Lucent's LGBT employee resource group, and saw the value of being "out" at work, supported by an Equal Opportunity (EO) nondiscrimination policy. At the time, no major company included transgender language in their EO policy. Horton asked for its inclusion in Lucent's policy, and recommended the language "gender identity, characteristics, or expression". As a result, Lucent became the first large company to add transgender-inclusive language to its EO policy in 1997.[4]
So this anon was right, this thread was made by a troony larping as a Chad with a cherrypicked, easily controvertible topic to start a shit-smearing campaing, very much a-la-liberal.
troony just confessed here 99988303
>Rust doesn't offer anything over C++ with smart pointers
That's not even true lol. Rust has destructive moves. C++ does not, it's move semantics is actually just cheaper copying, it can't actually move the value to different scope.
This matters because this is the reason why Rust smart pointers are zero cost and C++ ones are not. https://youtu.be/rHIkrotSwcc
Additionally C++ smart pointers have to be thread safe. They have to be atomically counted which prevents further optimization. Actually, GCC does some pretty sketchy magic to detect if smart pointers will be used in threaded environment and this system can be tricked causing hidden undefined behavior, yay!
And now, even if you sacrifice the performance, C++ still is far behind rust when it comes to safety guarantees. It's still full of footguns and gochias that you have to be aware of or your program is no longer safe.
You clearly have no idea where the actual strengths of your language lay. Trying to compete with Rust in its game is a quick way to lose.
>Actually, GCC does some pretty sketchy magic to detect if smart pointers will be used in threaded environment and this system can be tricked causing hidden undefined behavior, yay!
Midwit understanding of UB, do not respond by the way.
From the standard:
>[intro.races]
>The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior. ...
If you trick GCC into using non atomic shared pointer and use it from different two threads you get undefined behavior.
Midwit understanding of UB as a concept once again. It is implementation defined if GCC chooses it to be, there's no UB being caused by this unless there's a bug.
>You clearly have no idea where the actual strengths of your language lay. Trying to compete with Rust in its game is a quick way to lose.
That's exactly why I made this thread and I consider it a success. A very interesting discussion and I'm starting to get why Rust may make sense after all. Thank you.
>Rust making sense
try to bitwise not an integer using ~
"Rc<RefCell<T>>" sets you free.
low iq thread
99988358
I'm not a C++ chad but I'm not convinced by Rust either. I'm just reading about both languages because I can't believe I'm there one who is seeing that rust is a solution in search of a program when many intelligent people are seeing the value in rust. Is it a crime to ask? I said in the op "change my mind" I never lied
>change my mind
if that were possible you'd have arrived at the only correct conclusion
>smart pointers, move semantics and the automatic and safe memory managemen
all bloat