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.
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++.
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.
Here's a link to Casey Muratori's presentation on imgui. Important context, IMO, since this is the genesis of imgui as an easily-identifiable "pattern" that many others have run with in various languages/environments.
Yes! this is one of the first links that introduced me to the more promising side of imgui - Conrod probably wouldn't have taken this direction without this intro.
The more I hear about Rust, the happier I get. It's an amazing language and a platform and the more adoption it gets, the higher the chances for me also get to one day use it at work and that's what I really want, honestly!
It's inspiring to see developers willing to port non-trivial C++ projects over to Rust. The more pioneers are willing to lay critical groundwork like this the more promise I see in Rust for the immediate future.
It seems odd that he says Conrod has draw signatures that are "concise" and gives an example with 11 arguments. Perhaps some of these parameters should be wrapped in a struct?
Yeah you're right, I was lining myself up for this one :-) There are plans to merge the first three args, merge the dimension args into a Shape enum and more. Still early days with lots of refining to do!
Pretty sweet looking. After seeing the Envelope A/B widgets, I thought "wonder if this was made for the purpose of a UI for a software synthesis library?" And sure enough, it was :) Is the synthesis package open source (or going to be)? EDIT: nvm, found it: https://github.com/mitchmindtree/rust-dsp
Glad to see Rust getting more traction. I'm not a huge fan of the syntax, and I'm personally putting my chips in the purely-functional space--but it's the most promising as far as a practical C++ replacement with much better semantics, which is sorely needed.
It only has a basic DSP-chain atm on top of a PortAudio IO callback, but hoping to contribute some synthesis, sampling and effects work soon! Especially now I have some widgets to design instruments with :)
Isn't using immediate mode going to make implementing more complex widgets like multi-line text-edits with selection and style, and more importantly tree controls with collapsed/expanded persistent state that lazily load children (or only display items that are visible in the active view area) more difficult?
I was wary of this when we had first started the project. Originally I had planned to just go ahead and start a classic retained UI - the idea of trying to structure a widget lib without widget structs/classes sounded incredibly painful... however after watching some vids and actually having a go myself I'm realising just how wrong I was.
A handy breakthrough in my case was to use Rust's algebraic data type to store each individual widget state within a single container in the UIContext. This is akin to "caching" the state of every widget in one place with a process that is invisible to the user, rather than requiring the user to instantiate large number of objects and work out where they will store widgets, canvases, etc. This approach also makes it really simple to only access certain parts of the state depending on what is needed via Rust's pattern matching and destructuring. I'm yet to come across any kind of widget that is more difficult to store state for than it is in a retained UI (it's even easier for the user of the lib as they don't have to think about it) though perhaps I'm naive in my early days!
All of the widget examples that you have given are already in the plans, I might as well just implement them and do another Show HN instead of rambling in the comments :)
But "immediate mode" means you need to write code to create controls. That is the wrong idea, period. You want to be able to create tools to edit dialogs -- and you DON'T want the controls to be based on pixel positions, pretty much ever.
It's not about whether you can do it. It's whether it's useful to do it that way. You've got a cool tech demo, but you're working on something that won't ultimately be useful. Sorry.
The only reason I began development on this is because of my own use case in which this style of UI suits perfectly. It suits so well in fact I'm entirely abandoning the classical retained UI which I've been using exclusively so far. I'm not claiming that this style is perfect for every or even most use cases, however from my own humble, limited experience I'm yet to come across a use case where I'd prefer to go back (I'm well aware that these probably exist).
Re pixel positions: Tooling is planned for easier widget placement... As I mentioned in the article, the project has barely had three weeks worth of work poured into it - perhaps it's best not to try and declare the project as useless when it's barely even out of the womb ;-)
For a good GUI library, you ideally want the layout to be data driven. This means you can draw the entire tree without writing a line of code; this also implies "retained mode" (the opposite of immediate mode).
If it's not data driven, you can't write an editor for it -- or if you do, you end up with something that can write code but that has a hard time re-reading code that you've modified.
Ideally there's more inherited and inferred information, and less parameter noise. A crucial feature of any modern GUI library is the ability to auto-position all the elements, for instance: The placement by "pixel" location is an outdated practice in an age of multiple screen resolutions, aspect ratios, and densities. And getting the layout part right is much harder than getting a few widgets up.
Sorry, but as a GUI library this is not impressing me.
But more complicated ones, with resizable widgets/layouts, selection changes, scroll view positions and widgets which display a lot of data, or layering/parenting of widgets make things a lot more complicated.
Does anyone has the same thought with me? The complexity of Rust is close to C++ and around equal to Java.And as many people's tought, if you don't advocate to use the GC, are there any reason to use a language which is no-simple and not faster than C++????
I think you're asking why you'd want to use Rust over C++?
First, to establish what we're not losing by using Rust:
* It can be as fast as C++ (in essentially all cases--all but compile-time metaprogramming related situations, after some in-the-works reforms are implemented).
* It can be as deterministic as C++ (usable in hard realtime systems).
* It has great FFI-level C compatibility.
Advantages over C++:
* It is substantially safer than C++. Outside of unsafe blocks, it is memory-safe and many other forms of undefined behavior are absent, including data races (unlike not only C++, but Java, Go, and most other mainstream languages that support multithreading).
* In a number of cases, it could potentially be faster than C++ by utilizing Rust's much stricter aliasing semantics.
* It should be able to compile much faster than C++, and it can infer much more thanks to its type system.
The above are things that I don't think can be shoehorned into C++ backwards-compatibly. I'm not including features like ADTs because I see no reason C++ couldn't have them.
There are plenty of reasons not to choose Rust over C++, including language immaturity, implementation immaturity, library immaturity, ecosystem immaturity, and lack of familiarity. But language feature for language feature, it offers substantial benefits.
Currently Rust, Scala, Go and Haskell are all about equally fast, according to http://benchmarksgame.alioth.debian.org/ . C, C++ and Ada are still the fastest. It's intersting to me that all the new languages are about equally fast.
I'm not talking about current benchmarks, but theoretical speed. As a language (not an implementation, set of libraries, etc.) Rust will allow for programs to run as fast as C or C++ in all situations.* Ada, Scala, Go and Haskell may be able to do better in isolated situations, but in general this is not true for them. A lot of the time, this doesn't matter, but it's very important when you want to be considered a serious competitor in the domain of systems languages.
1) Even though the benchmarks game only shows a handful of tiny programs, Rust programs have only been contributed for half the tasks. (There are Dart programs for more of the tasks.)
Incidentally, some of those Rust programs are written for multicore:
binary-trees Rust ≈ CPU Load 96% 86% 92% 92%
fannkuch-redux Rust ≈ CPU Load 100% 100% 100% 100%
regex-dna Rust ≈ CPU Load 59% 79% 80% 59%
2) Your "about equally fast" covers what others regard as enormous differences :)
Well, none of those are clear wins over any of the others. They're somewhere in between the hyperoptimized compiled languages and the interpreted ones, and very distinct from them.
> And as many people's tought, if you don't advocate to use the GC, are there any reason to use a language which is no-simple and not faster than C++????
Rust was designed to be memory-safe. That means, unless you explicitly mark a section of code as "unsafe", it isn't possible to have segfaults, have buffer overflows, use memory after freeing it, etc. A very significant amount of software bugs - famously, Heartbleed, but also a huge proportion of other security bugs in everything from servers to web browsers - can't happen under Rust code. The point is to have a much more secure programming language, as in resistant to attacks, while still being as fast and as usable as other C-style languages.
The reason Mozilla are developing this is for Servo, a new browser engine which should be far safer than existing ones - although it's also useful for pretty much any other code, as it wipes out entire classes of bugs with not much effort. If you write in a C-like language today, you could pick up most of Rust (lifetimes included) in a couple of days of playing with it.
Is there any word from Mozilla on their position for an official UI toolkit for Rust?
I am past caring if it is a totally native looking toolkit, just as long as it looks good/consistent across all platforms with hardware acceleration I am good to go.
> Is there any word from Mozilla on their position for an official UI toolkit for Rust?
Well, given those bullet points, Servo might meet your needs :)
In general we're not going to think about blessing packages as "official" unless it gets to the point where some package becomes mature and overwhelmingly dominant in its space (think Rack in Ruby or async in Node); we'd prefer to focus on making it easy to upload and share Rust packages via Cargo to build up an ecosystem.
Warning: I am not involved with the project, and it has been a while since I heard anything official.
With that said, the last time I heard, the reason for Rust's existence (Servo) did not have any plans for implementing anything outside of the browser rendering & javascript engine. So, no browser chrome, which would be the only reason I can think that they would develop an "official" UI toolkit.
I would love for someone involved in the project to correct me, though :)
Last time I checked this was the main thing that was missing for Go (a complete, multi platform GUI lib). Has there anything like this arisen yet? Some quick googling points to Gothic, which sounds promising.
Im working in a weird "application platform"(looks more like a crazy userspace OS) right now and as a step 2, im planning to bind to the chrome compositor in the low level.. and build a ui framework in Go from there.. but the phase 1 is really the most important, and i think i will pre-launch before the UI kit..
The good side of it, is that you can also bind a web rendering engine totally coded in Go or bind the webkit rendering to the compositor backend..
- re layout: yes, at the moment there's a widget_matrix which can help with positioning, but I'm also keen to add slightly more friendly functionality into the ui_context: i.e. uic.add_widget(direction, padding, |position|{ /* widget::draw... */ }) or something along these lines. I'm totally open to other suggestions and inspiration too :)
- re draw: this function is actually the only instance of code required for the widget (hence the "immediate-mode"ness), so I'm not too sure what else could be abstracted away (other than some args)!
This is amazing, especially for only being two weeks old. I played around with Rust back when it was 0.10 (is it still?), and it's an awesome language. I can't wait to see this stuff get more advanced. Great work!
Super cool! Very impressive that this all came together in such a short amount of time. Having "real-world" projects like this in Rust is essential, and this library looks great, so kudos.
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.