I have done non-trivial things both in Rust and Nim. For big projects Rust seems a little more robust, but for medium and small projects Nim is an order of magnitude faster to develop for. There are still many rough edges, but it's exactly the tradeoffs I would personally pick for my one person small business making tools for artists. So far I have been using Rust and it's alright, but looking very much into Nim to see if I can replace Rust because of the high cognitive load to keep all of the Rust stuff in my head, as I don't really need safety.
Shout out to https://github.com/StefanSalewski/gintro which was super simple to build a simple GUI tool. With Rust I have no idea what to use after trying 5 different libraries.
The downside of Nim seems to be highly unpredictable performance in my experience. With Rust it's much easier to control. This might be a deal-breaker unless I can find some solution to it. Maybe it's just using it more than two weeks and learning the ropes.
> looking very much into Nim to see if I can replace Rust because of the high cognitive load to keep all of the Rust stuff in my head, as I don't really need safety.
Personally I find that Rust has less cognitive load, because so much of what you'd generally worry about in other languages is covered by language features in Rust: static typing, algebraic data types, etc
I'm sometimes a bit confused when people say that Rust has less cognitive load. I assume that's compared to something like C or C++, right?
I've used Rust and (imperative-style) Scala a lot, and I have to say, Scala is way easier since it doesn't have to deal with the borrow checker, but it still has an amazing type system.
Nim is statically typed and has algebraic data types, so I imagine it's also as easy as Scala, easier than Rust.
I like Rust well enough, but thinking about memory management is a reasonably large effort that I generally don't have to make in most languages. Rust, in not having a GC, strictly adds to that load compared to most languages out there. The exceptions are languages like C, C++, and assembler, and there I agree that Rust seems to make things a fair bit easier.
(Though, disclaimer, I never got around to learning modern C++, which I gather is a huge improvement over the style of C++ I do know.)
I'd be willing to accept, though, that Rust's lack of full-blown OO features, and its strict controls on mutation, often makes things easier in large shared codebases. Perhaps not letting people do some particularly wild things that I'm used to seeing in Java and C# at my day job. I'm not in a position to have a worthwhile opinion on that claim, though.
Imagine if someone said "I've used Python and Scala and Python is way easier since I don't have to deal with a type system". That's where people are coming from.
The borrow checker isn't a hindrance, it's an aid. Rust gives me syntax to describe lifetimes and a tool to check that syntax.
Yes, but if you have immutability and a garbage collector (and can afford to use some extra memory overhead), the borrow checker and lifetimes aren't really all that necessary to bother with.
Well, one thing that makes Rust harder is tooling. I don't seem to get around its code completion, at least in VSCode, and the docs, while mostly good, are hard to understand sometimes
I personally don't like that "structures with methods" way of doing things in Rust/Go but maybe that's just about getting accustomed
I agree but I tool functional programming course in college. It was hard! Someone who may not have invested enough in leaning basics of FP, I can totally see why Rust feels like a hard language. During the prototyping phase, I also avoid lifetimes and other esoteric features and often use unhealthy amount of Arc and Rc.
Nothing beats Cargo and company and loves compiler messages. Have used NIM as python replacement, and while language is great and nim batteries are decent, the ecosystem is not there. But who would use nim as python replacement!?
How would functional programming help with Rust? I am fluent in both, and having map and reduce in the Iterator trait does not make Rust anything like a functional language.
IMO Rust is what you'd get if you took a functional lang designer and forced them at gunpoint to create a procedural systems lang. It's not functional, but you can tell it was largely inspired by ideas from the paradigm -- immutable by default, expression-centric to an extent, features like Option<T> and Result<T> available, etc.
It's certainly a language that encourages programming in a functional flavor, even if the lang itself isn't functional.
The things that make rust “functional” are features like a type system that supports sum and product types and functions as typed values that can be passed around. It really is a functional language (in the original ML sense of the word) but with another orthogonal type system bolted on (borrow checker).
It’s missing some features like higher kinded types but it’s functional nonetheless.
I’m interested to hear what your definition of functional is - it’s always interesting because it’s such a vague term, really.
I recently tried Nim for the first time, and although is simpler, the model with values vs refs was a little more complicated than needed imo, and the 'easy C interactivity' wasn't as simple as with, let's say, Zig, where you'd simply do `@cImport`.
It's still fun though, and I appreciate the minimal visual noise while writing it.
Shout out to https://github.com/StefanSalewski/gintro which was super simple to build a simple GUI tool. With Rust I have no idea what to use after trying 5 different libraries.
The downside of Nim seems to be highly unpredictable performance in my experience. With Rust it's much easier to control. This might be a deal-breaker unless I can find some solution to it. Maybe it's just using it more than two weeks and learning the ropes.