7 ms·

Conrod – A Rust GUI Library

201 points by mitchmindtree 12y ago

Jemaclus 12y ago
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!
- indiv0 12y ago
  Rust is currently 0.11, with 1.0 scheduled by the end of the year.
- Havvy 12y ago
  They put out a new point release every three months.
  - steveklabnik 12y ago
    That's currently what's going on, but it's changing in the future: https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/versioning.md https://github.com/rust-lang/meeting-minutes/blob/master/wor...
hhm 12y ago
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.
- untothebreach 12y ago
  This looked promising the last time I looked at it: https://github.com/andlabs/ui https://github.com/andlabs/ui
  - hhm 12y ago
    Interesting, thanks
- dubcanada 12y ago
  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 12y ago
    Rusts goal isn't desktop applications, its goal for better or worse is to attempt to supplant C++.
  - deleted 12y ago
    [deleted]
- oscargrouch 12y ago
  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.. I hope i get there soon..
pselbert 12y ago
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.
zwegner 12y ago
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 12y ago
  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 :)
skybrian 12y ago
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 12y ago
  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!
- perlgeek 12y ago
  This is also where passing arguments by name would come in handy.
thinkpad20 12y ago
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.
bithush 12y ago
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.
- lastontheboat 12y ago
  Nope. It's totally not a thing we're concerned about at the moment, given the language's immaturity.
- untothebreach 12y ago
  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 :)
- pcwalton 12y ago
  > 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.
kolev 12y ago
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!
peetle 12y ago
Kudos to you! Let us put the scourge that is C++ to rest.
ajindam 12y ago
I must say, very very efficient on my teeny processor.
atmosx 12y ago
Is there any project in Rust that is deployed even in dev environments?
- steveklabnik 12y ago
  There are two production deployments of Rust (that we know about): * http://labs.opendns.com/2013/10/04/zeromq-helping-us-block-malicious-domains/ http://labs.opendns.com/2013/10/04/zeromq-helping-us-block-m... * http://skylight.io http://skylight.io : the gem you install to monitor your app is written in Rust.
  - atmosx 12y ago
    Ty Steve :-)
mlinksva 12y ago
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#gui https://github.com/rust-lang/rust/wiki/Community-libraries#g... ?
- TheHydroImpulse 12y ago
  http://www.rust-ci.org/ http://www.rust-ci.org/ is a really good resource for community libraries for Rust!
- georgemcbay 12y ago
  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 12y ago
    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.
berkut 12y ago
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?
- chowells 12y ago
  Why would it? You're not constantly trashing your application state, are you?
  - berkut 12y ago
    For really simple apps, no. 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.
- SomeCallMeTim 12y ago
  Yes. 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.
- mitchmindtree 12y ago
  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 :)
berkut 12y ago
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?
plq 12y 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.
- shmerl 12y ago
  Is there a way to use Qt from Rust? It has C binding, but not C++ as far as I know.
  - nsmartt 12y ago
    It's possible to use Qt from Python, so I would think Rust could do it in one way or another.
  - lastontheboat 12y ago
    http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5 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.
    - shmerl 12y ago
      Thanks for the pointer!
- nsmartt 12y ago
  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 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.
BinaryHole 12y ago
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 12y ago
  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 12y ago
    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.
    - pcwalton 12y ago
      We haven't parallelized and optimized our implementations of those benchmarks yet. I wouldn't read too much into that.
darkpore 12y ago
Is there any plan to abstract away the need to handle drawing the widgets yourself, and provide layout functionality?
- mitchmindtree 12y ago
  - 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)!

201 points by mitchmindtree 12y ago

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!

indiv0 12y ago
Rust is currently 0.11, with 1.0 scheduled by the end of the year.
Havvy 12y ago
They put out a new point release every three months.
- steveklabnik 12y ago
  That's currently what's going on, but it's changing in the future: https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/versioning.md https://github.com/rust-lang/meeting-minutes/blob/master/wor...

hhm 12y ago

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.

untothebreach 12y ago
This looked promising the last time I looked at it: https://github.com/andlabs/ui https://github.com/andlabs/ui
- hhm 12y ago
  Interesting, thanks
dubcanada 12y ago
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 12y ago
  Rusts goal isn't desktop applications, its goal for better or worse is to attempt to supplant C++.
- deleted 12y ago
  [deleted]
oscargrouch 12y ago
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.. I hope i get there soon..

pselbert 12y ago

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.

zwegner 12y ago

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 12y ago
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 :)

skybrian 12y ago

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 12y ago
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!
perlgeek 12y ago
This is also where passing arguments by name would come in handy.

thinkpad20 12y ago

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.

bithush 12y ago

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.

lastontheboat 12y ago
Nope. It's totally not a thing we're concerned about at the moment, given the language's immaturity.
untothebreach 12y ago
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 :)
pcwalton 12y ago
> 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.

kolev 12y ago

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!

peetle 12y ago

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

ajindam 12y ago

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

atmosx 12y ago

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

steveklabnik 12y ago
There are two production deployments of Rust (that we know about): * http://labs.opendns.com/2013/10/04/zeromq-helping-us-block-malicious-domains/ http://labs.opendns.com/2013/10/04/zeromq-helping-us-block-m... * http://skylight.io http://skylight.io : the gem you install to monitor your app is written in Rust.
- atmosx 12y ago
  Ty Steve :-)

mlinksva 12y ago

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#gui https://github.com/rust-lang/rust/wiki/Community-libraries#g... ?

TheHydroImpulse 12y ago
http://www.rust-ci.org/ http://www.rust-ci.org/ is a really good resource for community libraries for Rust!
georgemcbay 12y ago
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 12y ago
  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.

berkut 12y ago

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?

chowells 12y ago
Why would it? You're not constantly trashing your application state, are you?
- berkut 12y ago
  For really simple apps, no. 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.
SomeCallMeTim 12y ago
Yes. 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.
mitchmindtree 12y ago
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 :)

berkut 12y ago

plq 12y 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.

shmerl 12y ago
Is there a way to use Qt from Rust? It has C binding, but not C++ as far as I know.
- nsmartt 12y ago
  It's possible to use Qt from Python, so I would think Rust could do it in one way or another.
- lastontheboat 12y ago
  http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5 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.
  - shmerl 12y ago
    Thanks for the pointer!
nsmartt 12y ago
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 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.

BinaryHole 12y ago

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 12y ago
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 12y ago
  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.
  - pcwalton 12y ago
    We haven't parallelized and optimized our implementations of those benchmarks yet. I wouldn't read too much into that.

darkpore 12y ago

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

mitchmindtree 12y ago
- 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)!