18 ms·
I'm old enough to remember Win32 programming in C/C++ because it was the only thing that worked. There was a problem though. Memory management, shitty standard
by obviouslynotme 6y ago
I'm old enough to remember Win32 programming in C/C++ because it was the only thing that worked. There was a problem though. Memory management, shitty standard library, and a non-existent packaging system. Java came around and gave you something that worked. Memory management? The runtime does it. Want to do X? Here is a library for X. These combined with academia moving over to Java killed new C++ development hard. It seemed good at the time. Java sucked but Widgets and MFC sucked harder. Qt wasn't that popular yet.
There was only one problem with Java. Even on new machines, you would get noticeable random pauses doing simple things. This never happened in C++ apps even with full MFC bloat. The GC just wasn't that good yet. Programmers would also include FAR more code and libraries because it sped development up. Even today, C++ applications only include libraries if they absolutely have to because of how painful it is.
All of C++'s disadvantages become advantages when you look at them from the lens of performance. Manual memory management means that even if you are slow, you are consistently slow. You don't get the peaks and valleys that really irritate humans who are incredibly sensitive to rhythm. Memory leaks are honestly not even a problem unless you have long running servers. Even then, you could honestly just restart. The near-complete lack of standard libraries and complete lack of a package system highly reduced the amount of fluff you had. If you wanted it in your software, you had to do it yourself. This led to very simple, non-pretty, static interface that just tried to look like Word without the Toolbar of Death. The best optimization has always been to Do Less Stuff.
It's only going to get worse too. The same companies who think C++ is too complex for their programmers are going to laugh at Rust. People in Java or .NET shops aren't going to move over. "Native" is increasingly becoming a JavaScript space which has all the terrible performance of JavaScript usually combined with the slowness of internet connections. For good and ill, package management is now standard.
Microsoft Office used to run fast on a 486 with megabytes of ram. Think about that. Are you a more complex or intensive program than Word? I bet that ePCR has far higher specs. The program running on it isn't inherently more complex. It's literally a form filler, but it isn't used because of how ridiculously bloated even the most basic software has become. In the 90's, you could have made that machine by installing Windows on a machine and programming a VB program in a few weeks that hooked up to a printer. It would have been more responsive than a state-of-the-art ePCR that sits unused today.
- hansvm 6y ago> Memory leaks are honestly not even a problem unless you have long running servers. Not your main point, but having to kill a program or an OS and restart whatever I was working on because some process can't be bothered to give back memory it doesn't need (and that I now do need) is a major pain.
- ReactiveJelly 6y agoLuckily, the same programs that leak memory are probably the ones that handle crashes poorly
- bsder 6y ago> Memory leaks are honestly not even a problem unless you have long running servers. Firefox is a counterexample to this statement. Rust appeared because experienced Firefox developers simply couldn't manage C memory manually, C memory with garbage collection, C++ memory manually, or C++ memory with garbage collection.
- ReactiveJelly 6y agoYeah, kinda. Rust is meant to solve memory unsafety, which is an even worse problem than memory leaks, especially when you're running untrusted code.
- Scarbutt 6y agoAnd still, Firefox is less efficient and less secure than Chrome or Safari.
- renox 6y agoUh? While Rust provide memory safety it doesn't prevent memory leaks..
- MaxBarraclough 6y ago> The GC just wasn't that good yet. Also last-minute loading and verification of classes. Interpretation overhead and JIT compilation wouldn't help either, especially on a single-core machine. Many aspects of Java make more sense for servers than for desktop UIs. (This might finally be changing, with recent progress on ahead-of-time compilation of Java without requiring an obscure proprietary JVM.)