271–280 of 470 posts
Earlier quoted context omitted.
You say that as if Cargo, MSBuild, and pip aren’t massively loved by their communities.
Coming from c++, pip and python dependency management is the bane of my life. How do you make a python software leveraging pytorch that will ship as a single .exe and be able to target whatever gpu the user has without downloads?
Most arguments in the article boil down to "c++ has the reputation of X, which is partly true, but you can avoid problems with discipline". Amusingly, this also applies to assembly. This is _exactly_ why I don't want to code in c++ anymore: I don't want the constant cognitive load to remember not to shoot myself in the foot, and I don't want to spend time debugging silly issues when I screw up. I don't want the outdated tooling, compilation model and such.
Incidentally, I've also been coding in Rust for 5 years or so, and I'm always amazed that code that compiles actually works as intended and I can spend time on things that matter.
Going back to c++ makes me feel like a caveman coder, every single time.
Earlier quoted context omitted.
I would argue that rewrite in C++ will make it a lot better. Rust does have some nice memory safe features that are nice enough that you should question why someone did a rewrite and stuck with C++, but that C++ rewrite would fix a lot.
Fresh codebases have more bugs than mature codebases. Rewriting does not fix bugs; it is a fresh codebase that may have different bugs but extremely rarely fewer bugs than the codebase most of the bugs have been patched out of. Rewriting it in Rust reduces the bugs because Rust inherently prevents large categories of bugs. Rewriting it in C++ has no magical properties that initially writing it in C++ doesn't, especia…
That said, I still think it's a rather weak argument, even if we do accept that the rewrite will do most of the bug removal, since we aren't stupid and move to smart pointers, more stl usage and for each loops. "Most" is not "all".
The safety part in this article is incorrect. There's a google doc somewhere where Google did an internal experiment and determined that safety c annot be achieved in C++ without an owning reference (essentially what Rust has).
Earlier quoted context omitted.
"Massively loved" and "good decision" are orthogonal axes. See the current npm drama. People love wantonly importing dependencies the way they love drinking. Both feel great but neither is good for you.
I'm getting the impression that C/C++ cultists love it whenever there's an npm exploit because then they can gleefully point at it and pretend that any first-party package manager for C/C++ would inevitably result in the same, nevermind the other languages that do not have this issue, or have it to a far, far lesser extent. Do these cultists just not use dependencies? Are they just [probably inexpertly] reinventing e…
AUR stands for "Arch User Repository". It's not the official system repository.
> I'm getting the impression that C/C++ cultists love it whenever there's an npm exploit
I am not a C/C++ cultist at all, and I actually don't like C++ (the language) so much (I've worked with it for years). I, for one, do not love it when there is an exploit in a language package manager.
My problem with language package managers is that people love them precisely because they don't want to learn how to deal with dependencies. Which is actually the problem: if I pull a random Rust library, it will itself pull many transitive dependencies. I recently compared two implementations of the same standard (C++ vs Rust): in C++ it had 8 dependencies (I can audit that myself). In Rust... it had 260 of them. 260! I won't even read through all those names.
"It's too hard to add a dependency in C++" is, in my opinion, missing the point. In C++, you have to actually deal with the dependency. You know it exists, you have seen it at least once in your life. The fact that you can't easily pull 260 dependencies you have never heard about is a feature, not a bug.
I would be totally fine with great tooling like cargo, if it looked like the problem of random third-party dependencies was under control. But it is not. Not remotely.
> Do these cultists just not use dependencies?
I choose my dependencies carefully. If I need a couple functions from an open source dependency I don't know, I can often just pull those two functions and maintain them myself (instead of pulling the dependency and its 10 dependencies).
> Are they just [probably inexpertly] reinventing every wheel?
I find it ironic that when I explain that my problem is that I want to be able to audit (and maintain, if necessary) my dependencies, the answer that comes suggests that I am incompetent and "inexpertly" doing my job.
Would it make me more of an expert if I was pulling, running and distributing random code from the Internet without having the smallest clue about who wrote it?
Do I need to complain about how hard CMake is and compare a command line to a "magic incantation" to be considered an expert?
Earlier quoted context omitted.
I'm just pointing out that one reason devex sucks in C++ is because the fact you need a wide array of tools, that are non portable, and require learning and teaching magic incantations at the command line or in build scripts to work, doesn't foster what one could call a "good" experience. Frankly the idea that your compiler driver should not be a basic build system, package manager, and linker is an idea best left in…
For most people this is a feature not a bug as you suggest. It may come across as PITA, and for many people will do, but as far as I am concerned, while also having experienced the pain of package managers in C++, this is the right way. In the end it's always about the trade-offs. And all the (large) codebases that used conan, bazel or vcpkg induced a magnitude more issues that you would have to handle which otherwis…
Earlier quoted context omitted.
This is true and I will concede this point. Appreciate your feedback! However if I may raise my counter point I like to have a rule that C++ should be written mostly as if you were writing C as much as possible until you need some of it's additional features and complexities. Problem is when somebody on the team does not share this view though, that much is true :)
> However if I may raise my counter point I like to have a rule that C++ should be written mostly as if you were writing C as much as possible until you need some of it's additional features and complexities. How do you define “need” for extra features? C and C++ can fundamentally both do the same thing so if you’re going to write C style C++, why not just write C and avoid all of C++’s foot guns?
Earlier quoted context omitted.
I will die on the hill that string concatenation should have its own operator, and overloading + for the operation is a mistake. Languages that get it right: SQL, Lua, ML, Perl, PHP, Visual Basic.
Those languages need a dedicated operator because they are loosely typed which would make it ambiguous like + in JavaScript. But C++ doesn't have that problem. Sure, a separate operator would have been cleaner (but | is already used for bitwise or) but I have never seen any bug that resulted from it and have never felt it to be an issue when writing code myself.
Granted this is probably a novice-level problem.
C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really im…
I agree with the discipline aspect. C++ has a lot going against it. But despite everything it will continue to be mainstream for a long time, and by the looks of it not in the way of COBOL but more like C.
C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really im…
People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no…
It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time.
It's easy to publicly shame people who do hard things for a long time in the light of newer tools. However, many people who likes these languages are using them longer than the languages we champion today were mere ideas.
I personally like Go in these days for its stupid simplicity, but when I'm going to do something serious, I'll always use C++. You can fight me, but never pry C++ from my cold, dead hands.
For note, I don't like C & C++ because they are hard. I like them because they provide a more transparent window the processor, which is a glorified, hardware implemented PDP-11 emulator.
Last, we shall not forget that all processors are C VMs, anyway.