641–650 of 929 posts
Earlier quoted context omitted.
In what world is C++ harder to learn than Rust?
There is C++ code that 99.999% of people that list C++ in their resume are unable to explain. You can get comfortable with some idioms of C++, that's fine. Can you understand what any valid C++ code means? No. Such person does not exist, not even Bjarne.
I'm glad I don't have a Twitter account. I'd have spent the whole day arguing with stupid replies (both for AND against OP's point).
Earlier quoted context omitted.
That's a bold claim (since both languages are Turing complete). I presume you meant safe Rust? But that's kinda the point. If something is memory tricky it is supposed to go into unsafe so you can make a safe abstraction around it. Unless you meant actually all of Rust. In that case, please share what's inexpressible in Rust.
No. I mean that there is a great deal C++ can capture and present in a library that cannot be expressed in Rust. Much of this will never be in Rust because of this or that early choice of direction. At the most basic level, in Rust you cannot overload operators. You have no opportunity at all to code a move constructor. I could list off others all day long, but you probably would not understand most. Then there are t…
SQL builder programmers, for example, wanted assignment operator overload.
However, I'd argue that it's the wrong kind of overload to enable. The more code can do behind the scenes, the harder it is to reason about it, e.g. :
c = b;
sql!(a = b)
I didn't say it was easy. I didn't say it was impossible either https://mcyoung.xyz/2021/04/26/move-ctors/.
> Then there are the things the borrow checker will not let you do, that would be correct, but it can't see that.
Sure, but that's the Rice theorem at work (https://en.wikipedia.org/wiki/Rice%27s_theorem). Any non-trivial property of code is undecidable. That's why you have the unsafe escape hatch where you reason about why it's safe.
[1] which isn't that different C++ which prohibits some operator overload, but in C++ the list of operator not overloaded is small
Earlier quoted context omitted.
https://www.areweguiyet.com/ Until rust catches up with some meaningful feature set that Qt provides starting a GUI project in rust is probably going to be painful.
Most GUI apps don't need what Qt provides though. They mostly need stability and cross-platform support, so ... they should start with something like Tauri or Sciter, and if there is something they need natively they will be in a much better situation to pick their poison. https://github.com/tauri-apps/tauri uses OS provided WebView https://github.com/sciter-sdk/rust-sciter uses Sciter
But Qt provides that…
tauri has exactly 1 release, that was done 4 days ago.
sciter has done no release in over a year, and has 6 releases total.
It would be completely insane to pick either of those instead of Qt.
Earlier quoted context omitted.
I was not keen on spending time reading rust syntax specs the moment you said rust is actually c++.
When did I say rust is actually C++? I said its memory allocation model is the same: normally done in containers or smart pointers, but malloc and free are still available under the hood if you really need them. Many other things about rust are extremely different from C++.
So rust has heavy memory allocation implicit in the syntax (not meant only for the stack). I remember now I did not want that (like those horrible c++ new/delete).
Thx to have refreshed my memory about rust syntax.
Earlier quoted context omitted.
Surely you're joking, because I simply refuse to believe that you think Rust developers are actually sitting around thinking how to put other devs out of a job instead of, you know, using Rust simply because it's a better, more well designed language.
I didn't read it that way at all. I read it as: where can we find a lower cost (than C++) pool of developers. It's not particularly conspiratorial. Companies are always looking to expand their labor force and good C++ devs can be very expensive, so why would you want start a new project in C++? Security is another aspect altogether...
Inside Azure there’s an over reliance to C#, and the older versions of it to boot! So one team in charge of making .NET run faster and better, while the other one drags on using decade old versions Then for “speed” there’s weird mashups of C++ and C# that are just littered with terrible internal build tools that harken back to a nice 2010s and the idea of: “Idk it builds in my machine just fine” As far as Rust goes,…
This ^^ Really, anyone senior in Microsoft shouldn't be making this sort of argument. They already have a perfectly fine memory safe language that they could use way more widely than they already do. The number of bugs in Windows that either shouldn't happen or are too hard to debug when they do, because Microsoft insist on still using C++ instead of C#, is just phenomenal. Why can Google ship a mobile OS in which la…
I'm sorry but what the fuck. I paid my fucking phone 1k€ and yet it's bewilderingly slower than a RPi4 with a native apps stack. Every single interaction in the UI is slow and has some amount of lag, even with a 120fps screen. Android is to me the very best argument against Java there is - who knows how many tens of thousands of man-hours spent into optimizing it and it just does not perform to any acceptable level even with best in class hardware. It also has the most app crashes I have seen on any platform.
Earlier quoted context omitted.
> we're seeing more and more clients take memory safety seriously Running your test suite with asan, msan, tsan isn't sufficient? From my experience you need to start doing really nasty things (which shouldn't pass code review) before the sanitizers won't find your issues.
There are plenty of things that ASan won’t catch, like misuse between contiguous allocations. But that’s sort of tangential: the goal is to write software that’s correct to begin with, not poke holes in it with the testsuite after the fact. With Rust, I can pick third-party dependencies that I can be (vanishingly) confident don’t have memory safety issues; when I start a greenfield C++ project, any dependencies I bri…