My personal rule of thumb is that if someone is making gurglings about X possibly happening in the future, I will probably take some steps to make it easier if X does indeed happen in the future. If it's something I think is pretty much universal, I don't bother. "What if X" is not good enough, you also need "they were talking about/speculating about X". This rule tends to serve me well.
On every PC I have, the Ukraine "live feed" video at the top manages to start playing on its own as soon as I'm not looking. It doesn't do it at predictable times, but it usually does it as soon as I scroll down a bit, so I have to scroll up to turn it off. https://www.cnn.com/europe/live-news/russia-ukraine-war-news...
As someone who uses both Rust and C++ frequently with a good understanding of both languages, I can say that Rust is for the mostpart more pleasant to work in, but Rust's handicap is that it makes working in raw pointers when you really have to quite painful.
If you need full raw pointers with aliasing mutable pointers, the fact that fn drop() takes a &mut T is a problem that can only currently be worked around with fugly hacks, like nesting your data type in another pointless structure, not to mention the giant pile of ambiguous UB that you risk whenever pointers and references interact that could so easily be avoided if Rust would just implement an -fno-strict-aliasing switch, but the devs refuse on what appears to be ideological grounds. The result is that for unsafe Rust, you get about the safety level of C much of the time, because RAII and many language facilities are not safe to use. Unsafe Rust is currently so dangerous that I feel much safer reaching for C++ for some of it. Mutable reference uniqueness, I think, should be enforced by the borrow checker and NOT by pain of inescapable possible undefined behavior at the assembler level.
Now for C++.
C++ is lacking a LOT of useful safety features that Rust comes with baked in, such as Mutexes owning their data, the borrow checker, a good, fast atomic reference counting type, and things that translate to more safety indirectly, like algebraic enums, assignable and movable arrays, tuples built into the language, etc. Generics in Rust, however, are significantly more painful to write due to the lack of duck typing. Perhaps the Rust devs felt that duck typing was too "dangerous" for templates, but because they're statically evaluated, these issues almost never materialize, and so in practice duck typed templates are almost always superior to Rust's generics.
C++ is definitely more mature and pragmatic as a language, but Rust is probably better for systems programming overall, at least if they fix their goddamn unsafe UB stuff.
As for move semantics, that book isn't for "what you MUST do to keep things semi-safe!" though it contains some stuff to that effect. It's more about optimization and tricks from what I can see. Move semantics take a little while to wrap your head around, but once you know the basics of C++'s move semantics, you can pretty much figure out what's going to happen by looking at a class' definition briefly.
Haskell gives me headaches. I write a lot of Rust, which has elements of both. I think their approach is pretty good, though sometimes regular inheritance would just be easier.
I don't hate OOP. I don't love it either. I tend to write my code in a mix of procedural and diet-OOP paradigms. It tends to produce less state, less inter-dependencies, and doesn't require abandoning stuff like mutable state.
Why do I want mutable state so bad? Because it's the easiest, least abstracted solution to the problem much of the time, and closer to what the compiler will actually want to generate.
I think trying hard to stick to a single paradigm is folly. I like mixing and matching according to the task I'm attempting to accomplish, and I have a firm conviction that my code benefits from this ideology. Encapsulation I do value, but not as a "hard no". I use access specifiers to tell you "you probably don't want to mess with the guts of this thing, it can take care of itself better than you can."
As for inheritance, I don't use it very often. I like how C++ has no base "Object" class. A lot of the time I'm basically writing structs with methods, and I think that's often the right approach.
Eh. I just cast both to a bigger integer type where possible, which in practice, is almost always. So if I'm averaging two uint32_ts, I just cast them to uint64_t beforehand. Or in Rust, with its lovely native support for 128-bit integers, I cast a 64-bit integer to 128-bit.
The big issue I had with learning Rust is not the simple stuff -- I could write safe Rust fairly quickly. The problem I continue to have is that many internal behaviors of the language are totally undocumented and inexplicable. For example, implicit reborrows. They happen everywhere, but it's still just a pile of unicorn farts as far as documentation. The idea of a language with no documentation for a given syntax is horrifying. Rust does very well in documentation for beginners, but if you actually want to understand the language, if you want to know what's really happening, you're usually fucked.
Well I have nothing useful to add other than my personal priorities for a job, in order of importance. I'm a whiney little bitch when it comes to this stuff.
People/Environment -- If I hate the people I'm working with, I'm not going to stick around long. I've quit jobs for that reason before, and I would do it again. I have a low tolerance for assholes. For example, worked for a vending machine OEM that shall not be named. Boss was filthy rich and said "oh we'll pay for you to go out here to X!" and then had me ride a fucking Greyhound. I should have bailed right then and there, but I gave it a try, since I was young and fairly new to actually getting paid for my work. Guy had a new secretary every other week, and they always looked like they were one sharp comment away from swan-diving into a wood chipper. I've never seen office workers with that much terror in their eyes and voices before. Needless to say, I didn't stay with him long. Paid well, but getting technical specs, tools, and the data I needed for projects was like pulling teeth from a methed-out rhinoceros, and that proved to be the last straw. I remember once I was told to my horror and disbelief that they had literally completely lost core technical specs that I needed for the project, then they wanted to know why work was progressing slowly. At that point I just quit. Tried to ship his equipment back to him but the cheap motherfucker wouldn't even pay for the shipping, then just stopped talking to me when I asked him to. Guess he didn't care about the vending machine parts. Ironically they were worth more than the shipping, and totally worthless to me.
Integrity -- I look for a company that isn't actively making the world a worse place. I don't mind boring code, as long as I can write it well and be proud of what I've created at the end of the day. What I do mind, however, is predatory practices, unethical dark patterns, and user-hostile design and terms of service. If I think you're Facebook 2 Electric Boogaloo, I won't apply in the first place. If I think you're the "good guys" however, you'll have undying loyalty. *Sidenote: Sickens me to hear that so many of my fellow developers are willing to worsen the world for an extra zero on their check.*
Technology -- You must be asking me to use a language/toolkit/etc that won't make me want to blow my brains out every day at 5:01pm. I can work with tools and languages I don't particularly like, but do not, for example, ask me to build you an Electron app, PHP backend, or Java app. I will walk rather than endure that. Maybe some help in an emergency, but if you make that my main duty, I'm done. I'm fussy, but that's just me. It's very important to me personally to be able to respect the tools I'm using.
Autonomy -- I hate being micromanaged. I'm not incompetent. I've created programs with hundreds of thousands of lines of C++ and Python code by myself. If you second-guess every tiny decision I make over long periods, I will descend into quietly loathing you at the very least.
Money? -- I'm not a greedy person, but don't insult me. At least pay me something close to market. There's great irony in that statement right now, as I'm not making even close to what I'm supposed to (basically poverty wages for some of these months), as I'm trying to help a tiny startup keep its head above water because the boss is actually a decent guy and someone I respect. I suppose it illustrates just how much the kind of people I work with matters to me.
The company I work for hired several incompetent devs who wrote an abortion of an Electron client. It very nearly killed the company. I finally convinced the boss to let me rewrite it in Qt, and now our feedback is far, far more positive on the UX. Qt and GTK+ are one of those things that work "well enough" on the big three, especially Qt (GTK+ has serious theming issues on macOS), and it's hard to justify Electron as long as Qt or at least GTK+ exist.
Fuck Electron. I've seen what it can do to a product firsthand. If you get a competent web dev, it might work, but it will be slower than snail shit.
Just write it in Qt. You don't need to use C++, Qt has bindings for many languages, including Python, Rust, JS with Qt Quick, and even Lua.
Myself, I don't mind modern C++, though in many cases I prefer Rust.
Your argument seems to be that bad developers write bad software? Isn’t that true no matter the platform? I have written equally successful software in both Electron and Qt. In my experience, a competent developer can write great software given almost any platform.
While that may be partly true, Electron inherently attracts low-skilled, incompetent programmers due to its 'easiness', while in reality JS isn't that much easier than, say, Python. Not only do you have to deal with dumber programmers writing the code, but what people forget is that CPU and RAM usage isn't just some metric you see in htop or Task Manager. Electron apps are much slower than native apps at doing almost anything, sometimes to the point of obscenity. That was a big reason we were forced to ditch Electron, the WebKit bullshit was just too much for what we were trying to do. No matter how many bugs I fixed, it was still a bloated sack of shit. Qt was easy to write. Sure you had to put a few #ifdefs here and there, but for the mostpart, it was portable, easy, and Qt Creator saved us a ton of time compared to baking our own. If you write any application in "native" widgets for the host OS, shame on you. That is definitely the wrong way to do things in almost every case nowadays. That said, Qt and GTK+ provide so much better of a user experience with only slightly increased difficulty. It's hard to justify Electron.
> If you write any application in "native" widgets for the host OS, shame on you. That is definitely the wrong way to do things in almost every case nowadays
Could you elaborate on that? Isn't using the native GUI API of the OS a relatively sensible default, especially if you aren't targeting multiple OSes? If you definitely want cross-platform support, I can see the argument for choosing one of the cross-platform frameworks but I still don't think that means using the native GUI API is such a bad choice.
Qt is a great choice for writing multi-platform desktop apps. It would take a lot longer, and add unnecessary complexity, to write the UI specifically for each platform.
I suppose for OS utilities targeting a specific platform only, that makes sense. But for portability, you sure as shit shouldn't be trying to write a custom GUI using the native OS GUI toolkit for all three platforms. It's surprising how many make this mistake. It's like they've never heard of Qt and are surprised development takes forever.
The only problem I had with Electron was the slow booting time. Other than that it worked fine. I didn’t see any more bugs than I see on any other platform. Perhaps the problem was that you are very familiar with Qt and not with Electron? I am not saying that Electron is perfect. I don’t think any platform is. But it seems to me that (again) the problem you are describing is that bad developers will write bad code on any platform. And yes a lot of inexperienced developers know JavaScript so they are attracted to Electron and write bad code. Completely agree. But I think it is unfair to blame Electron for that. Just saying :)
Just reading the title of this post gave me a most perverse hearty laugh. I strongly applaud the deranged motherfucker who decided that implementing a quantum computer in SQL was worth the effort.
Next up: D-Wave emulator in COBOL.
For a certain set of problems, solving them in pure SQL, with all it's limitations, allows me to focus on the problem without all the cruft. Just pure logic.
