Hacker News new | comments | show | ask | jobs | submit login
One Year with Rust: I wrote a full featured application in rust, and so can you (vitiral.github.io)
153 points by vitiral on Feb 25, 2017 | hide | past | web | favorite | 38 comments



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 stabilizing low-level stuff and creating better apis there for doing things that are currently kind of annoying like creating your own data structs, and doing bit manipualations in fast math libs, etc.

Anyway rust is awesome, especially cargo (finally sane build/package management/versioning for a systems language). I will never code in c++ again if I can help it.


The rust team deserves a thanking rally for pulling this off.


>Sure, c/c++ has more libs, ...

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.


One of their (more minor admittedly) goals this year is to improve/stabilize no_std as well as make std more portable. Looking forward to another great year in rust!


To be clear, no_std is itself stable, but when creating a binary, you need two language items, and those aren't stable. It's not 100% clear what the right path is yet for that, but we'll get there. :)


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.



So glad to hear you're loving Rust!

https://github.com/rust-lang/rust-roadmap/issues/15 is the roadmap item for some things relating to this; id you want to chime in with your pain points here, that'd be very helpful!


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.


>I suspect they are doing C with classes style programming and (rightfully) hating that.

Rightfully? People resort(ed) to "C with classes" to make C++ tolerable and/or reliable.

If anything, it's the opposite: when most people complain about C++ it's about C++ itself, the full language, and its whole baggage of features and their obscure interactions and intricacies. Not about using C++ as C with classes.


Using C++ as "C with classes" with some carefully selected new features is an absolutely fine subset of the C++ language and IMHO the only way to circumvent the mess that C++ has become. The problems are the huge pile of cruft that has accumulated over the years in the std library, the boost-over-engineering approach, and the unfocused development of the language (instead of cutting the cruft down new standards add random new features on top of the existing mess). The current 'shiny new languages' will probably look the same in 30 years though.


stop the hype, please.


Yes. Finding Rust and doing some real things with is has been mindblowing. I have mainly Ruby/Scala/Python/Clojure background and I've only written a small lisp with C before, so Rust had some new concepts I needed to tackle. Now I've made my first app using Tokio having one asynchronious thread and a couple in sync. And even with hard concurrent/parallel code, if it compiles, it usually works.

Getting there might be a challenge sometimes, especially when you're just starting. But believe me learning Rust is worth the trouble.


What I would like to see is story from someone that is C/C++ expert and transitioned to Rust with their performance sensitive software, not side/hobbyist project, but real product working in production. I am interested in challenges that this person/team had, in which situations using unsafe was a must, what kind of performance problems they had with Rust abstractions (not all are cost-free) etc. And I emphasize on projects that strictly needed to be written in C/C++, not for example web api which requirements allowed it to be written for example in Java/Go etc.

Anyone like that here that could share his story?


On vacation so no links, but check out posts from Andrew Gallant (ripgrep, regex), any of the Servo/WebRender/Stylo experience reports from the Firefox team, and I there're some reddit comments out there about Rust's use in production at Dropbox.


thanks for the pointers; I was curious about Dropbox's approach and found this thread in the rust sub, if others are interested: https://www.reddit.com/r/rust/comments/4adabk/the_epic_story...


not that I know of, it would be awesome to hear about! Personally I think rust would excel at database development.

This doesn't answer your question, but rust is looking really good in the benchmarks game lately: http://benchmarksgame.alioth.debian.org/u64q/rust.html


Seems odd to compare Rust and Python.

They're different levels of abstraction and I think are both great languages that serve different use cases.

I'm always going to be more productive in Python. And Python has an awesome ecosystem for web apps. Rust gives you native compiled binaries, concurrency, and speed in general.

Why you'd consider these two languages for the same app is beyond me.


I agree and disagree. They are very different, but rust can do pretty much anything that python can do -- but do it better. The only time I would be more productive in python is if the app is very small (like a script).

Any bigger than that and rust is the right hammer for my nails. Probably just personal preference, but I strongly prefer the type safety and performance guarantees of rust.


There are definitely areas where rust and python are closer in abstraction level than you might initially think. For example, rust's iterator trait enables things which are remarkably powerful when compared against python comprehensions.

Another example is the rayon library which is incredibly succinct compared to the multiprocess module in python.


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 the other scripting languages I listed.


Agreed. People always mention the GIL like it's the achilles heel of Python, yet when discussing NodeJS the single threaded nature is almost described as a feature.

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?


I can't send you links, but you can make GUIs using GTK and QML. The QML crate by cyndis is no longer being maintained, but there is a new one by White Oak. Just add "qml" or "gtk-rs" to your project's cargo.toml file.


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 C++ and Qt.


CAD software would definitely be an exception!

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


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


It depends on how heavy. Single page apps (like arifact's) can be quite snappy. Elm really is a great language for doing this.


Sadly, the performance of most webapp-based desktop applications has been underwhelming compared to their native peers.


a very helpful perspective. Going from Python to a language with static types and different approach to concccurrency. Thanks for sharing!


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 mutable. This gives you a good balance of both performance and control.

It also has the benefits that make elm great like no exceptions, pattern matching, etc.

So ya, they are different languages but share a lot of the same concepts and benefits.


That's awesome. I'll definitely have to give it a go then!


Your tool and book look very interesting. I'll give them a try.


Thanks, I would love any feedback!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: