A Rust FFI adventure in unsafety
travisf.net
travisf.net
Up until now I've been focusing on Julia and Swift for projects that can use a new language, as the Rust pain/productivity ratio has looked too high.
Perhaps things are changing...correctness is certainly a worthy goal!
We're all extremely glad we chucked C++ and Go and switched to Rust. Rust isn't just a safer C++, it's a language that stands on it's own as extremely productive, safe, and fun to write. We combat the learning curve by giving people the O'Reilly book and the main Rust book, and we find new team members becoming productive in about a week. The Rust community is also amazing, and Cargo + RLS are the best ecosystem tools I've seen in any language.
I highly recommend Rust. If you have any questions, feel free to ask here. We're extremely bullish on Rust continuing to accelerate.
It's a nice complement to the open-source Rust book too, which may as well be read in digital form.
the rust stuff in my vim dates to v. early post 1.0 and would love to link ale + rls up.
rustup component add rls-preview rust-analysis rust-src --toolchain nightly
let b:ale_linters = {'rust': ['rls','cargo','rustc']}
let g:ale_fixers = {'rust': ['rustfmt']}
let g:ale_completion_enabled = 1In my experience the java profilers and debuggers are still better than anything that's available for rust.
RLS is great on a fundamental level (decoupling IDE from compiler), but it still has to catch up in functionality with the total compiler integration that for example eclipse has with ecj.
Kotlin and Scala have Sum types, and Rust still needs to catch up with Scala's type system.
The owners of Java only sue reimplementors that don't respect licenses, like Microsoft and Google.
None of other commercial third parties has had any issue with Java owners.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#...
Naturally I am not advocating for you to use Java instead of Rust, rather that it also has its uses in system work, and it is a valid option in scenarios where having a GC enabled language isn't a problem.
You've made at least one person's mood a little lighter today. Thank you.
I'm not going to claim that we have proof the Rust is more productive than Go or C++. I see some concrete advantages, however, Rust may simply better suited to the work we're doing. We might just enjoy writing it and therefore work faster.
The way I see it is that Rust guides you to better architectures, it offers a lot of very powerful features from FP and PL theory, and it's all engineered to make sense as a language. In that way, I think it's similar to Go in that they're both engineered while C++ has a lot of fossilized layers and has been organically grown for decades now. We have C++ code from half a decade ago that looks nothing like what we are writing now. It's this organic beast that has a lot of baggage. Rust and Go are engineered from the ground up, and with Rust editions I think they will avoid becoming the organic beast that C++ is now.
Similarly, the productivity difference will depend on how much run-time performance you need. It might be take longer to make Go code very fast if you need very fast. Having to work around the garbage collector, and avoiding interface {} etc.
well, Rust code from half a decade ago is also somewhat distinct from today's rust.. even basic cases don't compile anymore : http://progopedia.com/language/rust/
Rust is so easy to install and get up and running on any platform. But I am getting increasingly frustrated with documentation of many crates I try to use which were so easy in Python. For example serde, log4rs, clap (docs are pretty good).
For example, I can not find any way to change the log level in the log4rs implementation at runtime, or how to configure formatters with the yaml file.
To summarize:
* learning curve successfully flattened to a week by... reading two books.
* painlessly interacting with a large C++ code base
* no team member dislikes the change, instead they're feeling energized and this has even brought back some from near-burnout.
* Rust is extremely productive
I can accept that the tooling's good, community's nice and type system's a pleasure to use, sure. But people don't change so easily and such drastic changes in large code bases don't go right by default.
If all of what you said above were true, every C++ codebase would have been switched yesterday.
Well...my particular interest in these types of languages is primarily in the realm of soft real-time simulation, specifically various kinematic simulations.
Of the three, only Julia is garbage collected, and (unlike some other GC languages) it's fairly easy to not exercise the collector. I'm encouraged that will continue to be the case, since there's an organization using it for robotics, which is implicitly a hard real time use case.
Julia, Swift and Rust are all clearly general purpose languages. Swift is unabashedly general purpose, while Julia and Rust each have a primary niche - math/science and systems, respectively. All three use the excellent LLVM infrastructure.
Aside from determinism (which mainly requires pre-allocating nearly everything), my primary requirements are expressiveness/productivity, readability, and efficient runtime performance.
All three languages produce highly optimized code, and Rust probably has the edge as far as efficiency goes - but it clearly loses on the first two criteria, at least to Julia. If one needs access to machine level functionality in Julia, there's an extremely efficient C FFI, so mixing Rust and Julia (for instance) would be painless if needed.
https://github.com/dyu/ffi-overhead
It's a great time to be a software developer, and things will only get better as languages and tooling continue to improve!
If the application deployment scenario can handle typical GC workloads, then using a programming language with such support is more productive.
One example would be modern GUI toolkits.
I use it because it's easy to write code that I can come back to later and understand, and have confidence in.
My company has been shipping a service in rust for >1 year and its really nice knowing when the tests pass, and the app gets deployed it'll do exactly what it needs to in perpetuity. Once tests pass locally pushing to master doesn't require a second thought, if it ever does it means local tests should be updated.
While there is a non-trivial spinup learning to work in the language, and unlearning bad habits from other languages can be frustrating (especially coming from C). The performance, without losing correctness is wonderful.
IIRC, At one time, there was a "lazy_static!" that fit this use case? But maybe you can't do that here if what you need is the side-effect of the library call.
Serifs is the word you are looking for.
Hmm, from examining the font style in the stylesheet, and playing around it looks like Verdana is preferred, and then it falls back to Geneva, and then some default sans-serif.[1] Verdana has serifs though, and Geneva either doesn't or I don't have Geneva, so that seems an odd choice of preferences and fall backs.
1: The CSS is "font-family:Verdana, Geneva, sans-serif;"