
Conrod – A Rust GUI Library - mitchmindtree
http://blog.piston.rs/2014/08/30/conrod-update/
======
plq
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.

~~~
SkyMarshal
_> 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.

~~~
chrismorgan
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++.

~~~
pjmlp
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.

~~~
lake99
> 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.

~~~
borplk
Ada is alive and well. [http://www.seas.gwu.edu/~mfeldman/ada-project-
summary.html](http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html)

------
mlinksva
I had to look up what "immediate mode" means --
[http://sol.gfxile.net/imgui/](http://sol.gfxile.net/imgui/) discussion at
[http://lambda-the-ultimate.org/node/4561](http://lambda-the-
ultimate.org/node/4561)

Add to [https://github.com/rust-lang/rust/wiki/Community-
libraries#g...](https://github.com/rust-lang/rust/wiki/Community-
libraries#gui) ?

~~~
georgemcbay
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.

[https://mollyrocket.com/861](https://mollyrocket.com/861)

~~~
mitchmindtree
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.

------
kolev
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!

------
pselbert
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.

------
skybrian
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?

~~~
mitchmindtree
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!

------
zwegner
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](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.

~~~
mitchmindtree
I'm trying to OS what I can in another PistonWorks project called rust-dsp

[https://github.com/PistonDevelopers/rust-
dsp](https://github.com/PistonDevelopers/rust-dsp)

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 :)

------
berkut
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?

~~~
mitchmindtree
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 :)

~~~
SomeCallMeTim
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.

~~~
mitchmindtree
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 ;-)

------
BinaryHole
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++????

~~~
Jweb_Guru
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.

~~~
tormeh
Currently Rust, Scala, Go and Haskell are all about equally fast, according to
[http://benchmarksgame.alioth.debian.org/](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.

~~~
igouy
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
:)

~~~
tormeh
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.

~~~
igouy
Why wouldn't you expect Rust program performance to be distinct from
interpreted program performance?

------
bithush
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.

~~~
pcwalton
> 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.

------
hhm
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.

~~~
dubcanada
I don't believe Go intends to be used for Desktop applications. I believe
that's more Rust's goal.

Go I suspect is intended for more service related stuff, backend, server,
processing, etc.

Though I'm not 100% sure about this.

~~~
valarauca1
Rusts goal isn't desktop applications, its _goal_ for better or worse is to
attempt to supplant C++.

------
darkpore
Is there any plan to abstract away the need to handle drawing the widgets
yourself, and provide layout functionality?

~~~
mitchmindtree
\- 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)!

------
Jemaclus
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!

~~~
Havvy
They put out a new point release every three months.

~~~
steveklabnik
That's currently what's going on, but it's changing in the future:
[https://github.com/rust-lang/meeting-
minutes/blob/master/wor...](https://github.com/rust-lang/meeting-
minutes/blob/master/workweek-2014-08-18/versioning.md)

------
thinkpad20
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.

------
peetle
Kudos to you! Let us put the scourge that is C++ to rest.

------
ajindam
I must say, very very efficient on my teeny processor.

------
atmosx
Is there any project in Rust that is deployed even in dev environments?

~~~
steveklabnik
There are two production deployments of Rust (that we know about):

* [http://labs.opendns.com/2013/10/04/zeromq-helping-us-block-m...](http://labs.opendns.com/2013/10/04/zeromq-helping-us-block-malicious-domains/)

* [http://skylight.io](http://skylight.io) : the gem you install to monitor your app is written in Rust.

~~~
atmosx
Ty Steve :-)

