> [..] I decided that I need a safe, fast, and statically typed language that can be compiled and targeted to both mobile and desktop environments, as well as being made available to scripting languages via FFI.
And you eliminated Rust because.. it’s too complicated? It meets these requirements to the letter! Since this is a greenfield effort, would it really be too expensive to invest some time to learn it?
Anyways, I wish OP the best with Nim. I’ve always found it to be an interesting language.
The authors reasoning makes sense to me. Rust is powerful but also complicated and tends to encourage playing "language golf" as often as solving actual problems.
> there isn't a lot of reason to defer to Rust as an obvious choice outside of the usual focus on memory safety that dominates public opinion. As someone who actually hates to code for coding's sake and wants to Get Sh!t Done, Rust is just antithetical to my relationship with computers.
Nim made me enjoy programming again, largely for these reasons. When I was younger I enjoyed mastering languages like C++ or learning complicated generics systems, but now I enjoy just building useful things with minimal fuss. I don't care as much about type soundness of my CTFE, just that I can parse a file at compile time to do something useful. Sure its on my to ensure my files are stable, but thats just part of programming.
> I don't want to have to think about the language, and that's all Rust wants you to think about. I see a lot of people attracted to Rust where there is no shortage of funding and developer focus tends to be competitive, often leaning towards academic purity over solving pressing customer facing problems. These aren't luxuries I have and, to be frank, is not the profile of developer that one should hire for in an early stage startup. Nim gets out of the way, and stays out of the way.
“language golf” will sour me to a language/community very quickly. I especially despise implicits, as they make source code utterly unreadable without the help of tools.
> would it really be too expensive to invest some time to learn it?
I guess it depends on who you are. I find the complexity of Rust, and the community's cultural acceptance of said complexity, oozes out into every library to make every new thing you try to do seem like another incredibly hard slog.
I had one try at Rust a couple of years ago, and gave up. I had another one in the first half of this year, this time intending it for a (personal/hobby) cli app. But again, just found it dispiriting. I wasn't baulking at a single tutorial. I read all the Rust book (and worked through about half of it in detail). I read Jim Blandy's book. Lots of tutorials etc. I went through all of Rustlings. And wrote the first phase of my cli app (it's trivial but fairly robust and I use it daily). I still found it damned hard to get anything done in Rust.
I haven't quite given up (mainly out of stubbornness and having some time on my hands), and plan to take up the 2nd phase of my one Rust app. But anyone who finds Rust to be tractable by just 'investing some time to learn it' is living in a different world from mine.
OP in particular seems like someone who is familiar with a variety of languages, hence my comment. In addition, given that their requirements lined up with what Rust is good at, the time investment would be worth it.
When it comes to learning Rust in general, I think the difficulty and amount of time required depends on one’s background and overall learning style. If you are the type of person who wants to fully understand why things are the way they are before moving on, the process may likely slow down further. I think Rust is the kind of language where accepting things as they are at first will help you learn quicker. You can always circle back to dig in later.
For me personally, it took a couple of tries to “get” Rust. It definitely wasn’t straightforward to learn, but it wasn’t insanely complex either. Again, I think background and learning style contribute here.
Your response seemed to fall into a category common amongst Rust enthusiasts, which is to assume anyone resistant to the lure is ipso facto lazy or misguided. Your own question was a hint at laziness. I have no idea how much effort the writer put into evaluating Rust. I doubt you do either.
I don't know why some of us find Rust difficult. Perhaps it just is, or isn't, or is for some people and not for others, or perhaps we are just thick. My suspicion is that there are more people who do than seem apparent, because they tend to get shut down by the very decorous implications of laziness or stupidity that are so characteristic of the Rust community.
Well I didn't see another way to gloss your question:
> would it really be too expensive to invest some time to learn it?
I'm entirely happy to take your word that I've misinterpreted the question. Back-and-forth in comments about intended meaning is rarely useful. So my apologies.
But the general attitude in the Rust community (of which I have no idea whether or not you're a part) absolutely is "Rust is not hard, and if you find it so, that's a measure of your dysfunction, not a description of the language".
The context for that question is important: OP had a set of requirements and Rust seemed to meet them. I’d personally consider investing time to learn technology X if I found out it met my requirements. This is not a Rust-specific thing.
I agree that Rust is not simple to learn. There is a definite learning curve involved, especially at the start. I hope your experience with the community and the language improves going forward.
(1) is a one-time investment and allows you to take advantage of compiler guarantees. (2) is what every other language does for FFI anyways. In Rust, you could have a lightweight wrapper around the C API, but you would lose out on some benefits.
OP said performance was critical, so why would they use a GC language?
Reference and pointer types (annotated with `ref` and `ptr` respectively) are nillable. The compiler can provide null safety guarantees by annotating types with `not nil`: https://nim-lang.github.io/Nim/manual_experimental.html#not-.... So then your example would look like the following, and fail to compile.
type
Foo = ref object
Bar = Foo not nil
var bar: Bar = nil # error: type mismatch
echo bar.a
Hi, article author, here. Down in one of your other replies, you state:
> The context for that question is important: OP had a set of requirements and Rust seemed to meet them.
The context as I presented it is perhaps unfairly narrow, and I've glossed over some of the non-technical requirements that constrain my choices. Time-to-market and funding levels are hyper critical - these are hard limits that have less riding on me-as-IC being the sole determinant of a positive outcome, and more on being able to hire the first team members should I meet my funding goals in 2023. Here in the EU, hiring rust devs is ultra-competitive, expensive, and open positions tend to sit unfilled for longer periods of time. There is a mercenary like attitude among experienced crypto developers that makes it difficult to recruit for projects. A developer who is good with rust and knows crypto well doesn't need you for a job - they're probably already looking for funding or considering a co-founder position with a biz person that's already snared a wealthy benefactor for advisory and seed funding. This makes building a founding team (vs a team of co-founders) very difficult in the space.
On the flip side, I can teach a good JVM / golang / python / NodeJS developer how to iterate in nim a lot faster than bringing them up to speed as a proficient rust developer.
My top considerations were among "productive" compiled languages: go, crystal, swift, even investigating mruby. These languages have considerably less cognitive surface-area in banging out pedestrian and proprietary IP code in a 7:1 ratio (not scientific, obvs). First, you need to quickly produce MVP and v1.0 products. Secondly, the follow-on to that is being able to support fast iteration to launch and prune features. This latter aspect is much more important than the zero-to-MVP phase, since the clock isn't really running until you're actively marketing a project and it's gaining (or losing) users. Rust is just not a good choice for the entire code base. It is, however, a great-to-good choice for low-level dependencies. Given it's flexibility, I think Nim can be both. We'll see.
There are two documents that haunt my thoughts over the course of decades being in tech startups. One of them is Paul Graham's "Beating the Averages". The other is Akin's Laws of Spacecraft Design.
One of Paul's reasons for using Lisp at Viaweb was, paraphrasing here for brevity, that choosing the defaults of your competitors is going to yield an average result, which will put you out of business. In my industry vertical, I do think that Golang is more that default than is rust. The evidence seems to point toward Go based teams being better at burning through VC (tongue firmly in cheek ;-) ), and that Rust is superior at embedding working technology whose code-paths touch every customer, every day.
My sincere hope is that Nim hits the sweet spot in the middle while eeking out some of the competitive advantages that Graham talks about. As the idiom goes, you takes your money, and you makes your bets.
And you eliminated Rust because.. it’s too complicated? It meets these requirements to the letter! Since this is a greenfield effort, would it really be too expensive to invest some time to learn it?
Anyways, I wish OP the best with Nim. I’ve always found it to be an interesting language.