Hacker News new | ask | show | jobs
by plq 4313 days ago
I have mixed feelings about this.

On one hand, I'm enthused that Rust, arguably the only serious contender to C++'s throne, is gaining traction.

On the other hand, I'm scared that respectable projects like Qt (~6M lines of C++, man-millenia of work!) will be considered "obsolete" by the coming generation and another cyle of wheel reinvention will begin, tossing away man-centuries worth of polished, working code on the sole ground that it's C++.

It's not like C++ is going anywhere anytime soon, (Some serious infrastructure reportedly still runs on COBOL after all!) but what if we could finally settle down on a technology for a certain kind of problem and focus all our energy on building new stuff? Wouldn't that be grand?

I wonder whether there's another industry that keeps reinventing itself every 20 to 30 years and still gets away with it.

7 comments

It would be a shame for man-millennia of work to be lost, but it would also be a shame for advancement to be stalled by these kinds of concerns. Experimenting with new approaches and ideas, direct competition between projects, excitement over new languages and frameworks. These are all factors that lead to advancing the state of the art.

It's worth being concerned about losing the lessons learned from Qt, but this is a kind of false dichotomy between the old and the new.

With that said, I don't think those lessons will be lost anyway. Qt can't (and shouldn't!) last forever or remain in its current form. C++, though it will live for a long time yet, will eventually fall out of favor, and large sections will eventually be purged from Qt as the project matures. The man-years that went into the portions that were, or some day will be, removed have taught Qt developers and users a great deal.

Qt developers and users will bring knowledge and wisdom to new projects that will compete with Qt (directly or indirectly). Some projects will survive and some won't. Some will be much the same as Qt, while some will be completely different from the start. Conrod, as it happens, is an approach to a different kind of GUI development (see this comment: https://news.ycombinator.com/item?id=8244224).

This, of course, doesn't include developers who do their own things without ever using Qt. Hopefully, they will encounter blog posts and articles about some of those lessons, as well as attracting developers who've learned some of these lessons.

This isn't a case of getting away with reinventing the industry. In this nascent stage, computer science, with all the renegade hackers and developers, is still a necessary occurrence when new languages and frameworks are invented.

GCC stagnated until it received competition froom LLVM (clang). something similar seems to have happened to C++ the language itself, and i think viability of competing languages has played a large role.
Interest in development of C++ has never been more vigorous. Representatives from more companies than ever before are getting involved in C++ standardization and giving talks: see http://cppcon.org for details. There are now numerous study groups involved in standardization, each focusing on a specific feature targeted for C++17. Scroll down to the bottom of this page for details: https://isocpp.org/std/the-committee.

C++11 and C++14 have done a lot to enable users to write clean, efficient code. I probably would not be using C++ today if I were forced to write in C++03 style. I am still not convinced that C++ has gotten any easier to learn over time. But for those who know how to use it well, no language ranks better in allowing users to write clean, efficient, and portable code.

"Respectable"? "Man-centuries worth?" Of course I'm used to hearing crazy things on the internet, but you just totally blew my mind right now. You know, man-centuries were spent to build and "polish" such glorious (and surely working!), once respectable pieces of technology like threshing machine or steam engine, yet I somehow don't feel I miss them much. Seriously, it's just ridiculous.

No, what worries me much more is the fact that there is no antialiasing on the "Envelope" in demo video.

Besides, probably it will surprise or even scare you, but Qt isn't the only, the first or the last GUI framework, there're many more, and new are created all the time. …And not even single actually good one invented still, but that's another topic. So there isn't any reason to think of that Conrod thing as something more than "just another one GUI framework". At least, until it would turn out to be somehow superior to ones that already exist. And if it will turn out to be superior to, say, Qt, then Qt should go to trash and I couldn't care less about all that "man-centuries" of yours. But, realistically, it's unlikely to happen, so everything we could hope for is some less complicated, useful for just some subset of GUIs micro-framework. In fact, it would be already very nice by itself, since it would spare Windows-developers of the pleasure of 30Mb cross-platform "Hello worlds" using Qt.

It feels pretty grand to consider the prospect of no longer having to debug crashes due to expired QTreeViewItem pointers, or spending time counseling junior team members to check for expired weak pointers.

Qt is excellent for its epoch, but if you've read the source you will know that we should not treat it as sacrosanct. Algebraic types and explicit lifetime declarations and macro syntax extensions could all do wonders for it.

> On the other hand, I'm scared that respectable projects like Qt (~6M lines of C++, man-millenia of work!) will be considered "obsolete" by the coming generation and another cyle of wheel reinvention will begin, tossing away man-centuries worth of polished, working code on the sole ground that it's C++.

I imagine that as soon as Rust hits something like version 1.5, we will start to see semi-automatic converters from C/C++ to Rust, something similar to the C-to-Go effort underway to get to a self-hosted Go compiler.

Qt will probably take 5 years to be ported in a decent way, but I am pretty sure that a sizeable part of that codebase will be translated without too many problems, given its relative clarity.

>Rust, arguably the only serious contender to C++'s throne

Does anyone consider Ada another contender to C++? Statically strongly typed, safe manual memory management, wide-spectrum, hard real-time & embedded capable.

Public opinion is a matter of very considerable importance in such questions, and Ada simply doesn’t have it there, while Rust does. So no, I would not consider Ada “a serious contender to C++’s throne”, regardless of technical comparisons with Rust and/or C++.
And yet, when you travel by train, plane, being monitored in an hospital, real time OS in factories, there is most likely Ada underneath.

If Rust wants to become a real systems programing language, it needs OS vendor support, not HN cheering.

> there is most likely Ada underneath

I have worked for quite a few real-time safety-critical systems, including one of the domains you mentioned. I have ex-colleagues who now work for other such domains. I assure you, that Ada is rarely ever seen. It's just C all the way, and usually running without an OS. I used to see job openings for Ada programmers some 15-20 years ago, but I haven't seen anyone use it in any of the firms I worked at. The only thing that seems to be changing these days is a creeping in of Matlab/Simulink-generated C code.

Kongsberg writes it's missile-guiding software in Ada. A pretty strong endorsement if you ask me.
I do in the areas where human lifes are at risk.
Is there a way to use Qt from Rust? It has C binding, but not C++ as far as I know.
http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-exampl... is discussion on using C++ libraries from Rust that focuses on QT as a motivating example with runnable code at the time.
Thanks for the pointer!
It's possible to use Qt from Python, so I would think Rust could do it in one way or another.