Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Conrod – A Rust GUI Library

blog.piston.rs

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Conrod – A Rust GUI Library

#71

Post by Jweb_Guru »

tormeh wrote: post #68
Jweb_Guru wrote: post #47

Earlier quoted context omitted.

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 s…

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.

* Pending some in-the-works reforms, and not including implementation-specific features like labels as values (https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64).

Re: Conrod – A Rust GUI Library

#72

Post by igouy »

tormeh wrote: post #68
Jweb_Guru wrote: post #47

Earlier quoted context omitted.

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 s…

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.

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

Re: Conrod – A Rust GUI Library

#73

Post by SomeCallMeTim »

mitchmindtree wrote: post #43
berkut wrote: post #27

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…

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.

Re: Conrod – A Rust GUI Library

#74

Post by tormeh »

igouy wrote: post #72
tormeh wrote: post #68

Earlier quoted context omitted.

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.

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"…

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.

Re: Conrod – A Rust GUI Library

#75

Post by mitchmindtree »

SomeCallMeTim wrote: post #73
mitchmindtree wrote: post #43

Earlier quoted context omitted.

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…

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

Re: Conrod – A Rust GUI Library

#76

Post by igouy »

tormeh wrote: post #74
igouy wrote: post #72

Earlier quoted context omitted.

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"…

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.

Why wouldn't you expect Rust program performance to be distinct from interpreted program performance?
Post reply on HN