So I recently started programming in Elm and also did some stuff in Rust. Honestly, it was mostly a hype-driven decision, but the journey was def...
For further actions, you may consider blocking this person and/or reporting abuse
This is a great post, and I agree that tagged unions and exhaustive 'match' really do seem to help with corner cases. And I also love the fact that both languages forbid
nulland require the use of anOption-like type to represent possibly-missing values.However, I found that Rust's borrow checker was mostly a struggle very early on, but that I quickly learned to design code in ways that made the borrow checker almost invisible on a day-to-day basis. For Rust, I think it's useful to distinguish between:
For me, the actual big limitation with Rust is that the third-party library support for "work" stuff is almost there but has the occasional corner case. I find that I produce a steady stream of minor PRs to Rust crates whenever I try to do something tricky in production. Happily, Rust library maintainers seem to be a pretty friendly bunch and they process most of my PRs quickly.
Just to add something that other maybe found useful:
IntelliJ has a very well made plugin for rust that gives you syntax highlight and allows you to resolve cargo dependencies, also it can run cargo tasks and other stuff related to the day by day work in Rust.
It's a pain to have this super big IDE only to use Rust, but it's an start.
Thanks for the article, really interesting food for thought. I especially liked the reference to "GOTO considered harmful, considered harmful". Seems ridiculous in hindsight.
I really like the ideas of functional languages. I wish people would come to realize that functional and object oriented programming are not opposites; they can form powerful alliances. Immutability and pure (side-effect free, idempotent) functions are extremely useful concepts. However, I do not necessarily need to go as far as Haskell to implement those (neither do I need to go as far as Java to do object orientation).
I have one major pain point with pretty much every functional langauge out there, be it Elm, Haskell, OCaml, you name it: The syntax. "Unreadable" does not even begin to describe it. Sure, the program just has 250 characters (not lines!) in total. But if I need 10 hours to figure out what it actually does, then how does this help anyone? It's about as far away from "literate programming" as you can possibly be. Elm and Rust are nightmares come alive in that regard as well, albeit each for different reasons. I can't help but get the feeling that those languages were not designed to be written, read or interpreted by humans. In that particular regard, they are no better (if not worse) than the assembly code they compile to.
After a couple of weeks of using this ML based syntax languages you will feel like you know them for years, it's not that hard, as Aramis mentioned, is a question of familiarity. Give it a try, it's a lot of fun, specially Elm on the web sites.
You are confusing readability with familiarity here, to the point that it is almost a little bit insulting to people who enjoy ML style syntax. :-)
I do agree though, that (academic) Haskell code can be hard to read: highly abstract, lots of cryptic operators, single letter module imports. But this is a separate issue, not to be equated with language syntax.
I've been working on a rust+elm project for some time now: A NES emulator written in rust with a debugger front-end written in Elm. Both languages are an absolute pleasure to work with. With elm in particular, I'm amazed at what I'm able to accomplish considering a web app of equal complexity written in any other browser-centric language/framework would have become a massive burden to maintain and add features to.
I really need to do a proper demo of this thing, but here's a crappy demo showing off the debugger front-end: youtu.be/5JlHSK6BeKI
Somehow Reason reminds me a bit of Elm.
Its code is always fully typed and it has variants (tagged unions) that are a nice solution for many problems I faced with front-end development (i.e. Error, Loading, Success).
Its integration with existing JavaScript seems to be more straight forward than Elm's.
Thank you for sharing !! 👍😎
Yes, the future is FP with languages like Elm, Rust and even new ones to come.
We are using Elm at my company and we and our users are very happy with it. Rust is also a lot more popular and powerful now. I'm looking forward to know which new generation languages will come soon.
About Rust with MSVC:
Rust's compiler backend is always LLVM. The only difference between the GNU and MSVC Rust compilers that you can download for Windows is the version of libc that your program is linked to, and which ABI they use for repr(C) structs and extern functions.
Thanks for the note. I'll remove that sentence.
Really interesting post, thanks! Just out of interest, why would you recommend using decimal types for representing currency? I’ve always found this to be problematic with rounding etc.
Decimal types differ from floating-point types in that they have a fixed precision (both before and after the decimal point), mimicking the way human clerks work with numbers. There are even regulations for this: in my country (Czech Republic), the law requires/suggests (IANAL) you to compute money-related operations (interest, fees, ...) with four decimal digit precision and then round the final number to two decimal digits.
This contrasts with floating point operations, that don't have fixed precision and cannot represent some values precisely. For example, subtracting 0.01 from a large number may yield the same number, which may be acceptable in physics simulation, but is not acceptable in finance.
The formatting of the post seems broken midway in. Hard to follow because of that.
Sorry I think that was an issue on our end. I fixed it.