31–39 of 39 posts
How do I make a GUI application in rust? Does it have support for Qt, MFC, or maybe WPF?
Earlier quoted context omitted.
I really wish python had a good concurrency story, it would last far longer as a language if it did. The GIL is why it's reducing in popularity.
> The GIL is why it's reducing in popularity. Unlikely. Python, Ruby, PHP, Javascript all do not have in-process parallelism. In contrast, C/C++, Java/Scala/Clojure, Go, and Rust all have in-process parallelism. This just furthers seabrookmx's point that Python and Rust belong to two different classes of useful languages. --- P.S. Python's multiprocessing module is an order of magnitude better/easier than anything in…
Anyone reading hackernews knows that Node doesn't have an issue with popularity (and AFAIK Python doesn't either).
How do I make a GUI application in rust? Does it have support for Qt, MFC, or maybe WPF?
Just personal opinion here, but I think GUI's should/are being phased out. I much prefer writing a front-end web app and package it inside the application. That's what artifact does.
I've been doing a lot of rust lately and I have to say it blows c/c++ out of the water. Sure, c/c++ has more libs, but almost every other feature in rust is fantastic, and wrapping a clib via ffi is really easy in rust. My only (minor) complaint with rust is that they aren't pushing no_std enough IMHO, but I'm biased since all my code is no_std :) so obviously I'd like to see a lot less work in the stdlib and more on…
By that way, in referring to C++, are you referring to modern C++ or C with classes? Whenever is see people criticizing C/C++, I suspect they are doing C with classes style programming and (rightfully) hating that.
Was your experience with Rust comparable to your Elm experience? I've been coding a lot in Elm lately and LOVE the reliability of the everything. Once you make it past the compiler, you know that it's not going to crash and that you'd managed all possible cases. (I bring this up since using Elm was mentioned in the article)
Rust is much more feature full, allowing you to do things (like mutate data) that you can't do in elm. It also has a lot of new concepts (like lifetimes). All of these things are to allow for ultra high performance applications - it can run as fast or faster than C! One nice thing about rust is that everything is explicit. If someone can mutate your data, you have to pass "&mut" to them and declare your variable as m…
Earlier quoted context omitted.
Just personal opinion here, but I think GUI's should/are being phased out. I much prefer writing a front-end web app and package it inside the application. That's what artifact does.
But at present I don't know how to use this approach for the imaging or CAD software I develop. I need the ability to share GPU data between front and back ends, along with accurate timings for the control of various hardware devices. This is possible with Java (think the design of MATLAB or Mathematica) but the additional glue to enable cross language communication doubles the code size. That is why I'm sticking to…
I think they are JUST starting with some gui frameworks for rust,so I think the language is a little behind there. Never done extensive searching though
Earlier quoted context omitted.
Just personal opinion here, but I think GUI's should/are being phased out. I much prefer writing a front-end web app and package it inside the application. That's what artifact does.
I'm pretty sure that its just case of low-hanging fruit; its difficult to claim that webapps are at all effecient in their work, its just that most gui's don't actually have much work to do. But native apps are clearly preferable when a heavy interface is part of your app's usage
I've been doing a lot of rust lately and I have to say it blows c/c++ out of the water. Sure, c/c++ has more libs, but almost every other feature in rust is fantastic, and wrapping a clib via ffi is really easy in rust. My only (minor) complaint with rust is that they aren't pushing no_std enough IMHO, but I'm biased since all my code is no_std :) so obviously I'd like to see a lot less work in the stdlib and more on…
My problem is honestly that Cargo has spoiled me. C (& C++) may indeed have more libraries; but adding them to a project is a non-trivial exercise.
Assuming your project subscribes to the "build it with one command" philosophy then:
- You'll need to install the target project's build system
- You'll need to invoke that from your project's build system
- You'll need to copy those artifacts (which depends upon implementation details of their build system) to the right output directory (which depends upon implementation details of your build system.)
- Then finally you get to include the headers complete with ifndef guards. (Honestly it's getting increasingly more difficult for me to even tolerate C/C++ header files.)
- P.S: probably repeat this list for every target platform you build on.
---
When installing a package takes a single line of configuration, or a single command, I am far more likely to ignore my "not invented here shoulder-demon" and just add a 3rd party dependency. In C/C++ I actively avoid adding dependencies, regardless of how numerous they may be.
Earlier quoted context omitted.
Can you explain what you mean by "you need two language items"? I'm just getting into Rust now and planning some bare metal stuff.
https://doc.rust-lang.org/book/no-stdlib.html (This link will change in one or two releases; I landed a new "Unstable Book" a few days ago.) The TL;DR is Rust expects certain stuff to be implemented in Rust code to work, and that's provided by the standard library. When you don't use the standard library, libcore implements all but a few of them. Implementing them is not yet stable.