Choosing Nim out of a crowded market for systems programming languages

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!?

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 personally don't like that "structures with methods" way of doing things in Rust/Go but maybe that's just about getting accustomed

The most popular rust gui library at the time of writing seems to be egui with 489k downloads.

I've no doubt that doubly linked lists are an awkward hassle to implement in Rust. But the same is true in functional languages, and you never hear people criticizing, e.g., Haskell over this. I have a couple guesses as to why that is, but I'm guessing the main one is that Rust being touted as a C replacement results in people assuming that Rust should be amenable to the same kind of (for lack of a better way to put it) hyper-imperative approach to problem solving that C basically forces upon people.

But I'm also pretty sure that I've never, in my 30 years of programming, used a doubly linked list in anger in a language that wasn't C. (Maybe Pascal?) I have never used Rust in anger, either, but, based on my little bit of dabbling, it seems like yet another language where I would be likely to choose any number of different data structures first. I certainly wouldn't be implementing my own in any case. These days, implementing doubly linked lists from scratch seems to be very nearly the sole province of C programmers and undergraduates.

https://cglab.ca/~abeinges/blah/too-many-lists/book/README.h...

Choosing something which us not C++ may be a long-term goal by itself.

I completely agree that if you want to be a career programmer, focus on solving problems for business. But it can be done in any language nowadays.

I meant as a systems programming language. To replace C or C++ or such.

Though do note that (academic discussions notwithstanding) refcounting is not what people usually mean by GC in these contexts. Having to put up with refcounting is one thing (people already do it manually anyway), but having to put up with a generational or other complex GC is quite something else.

Is this your perception, or are you actually seeing this being encouraged by the Rust community?

> This is an interesting take.

I personally don’t agree with OP’s take on Rust at all, but I respect their decision to use whatever language works best.

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.

Best of luck on your learning journey!

    type
      Foo = ref object
      Bar = Foo not nil
    
    var bar: Bar = nil # error: type mismatch
    echo bar.a

That said, I can understand how it may not be for everyone. I love it, but there are some data structures you just have to code differently, and until you spend time thinking about how to do that, it would seem like wasted time you wouldn't get back.

My personality may also be a fit: I'm very much a measure twice, cut once kind of person. I tend write my algorithms in pseudo code and sketch my data structures on paper before I touch the keyboard, so even in my "get it done" language I don't immediately just start coding always.

So you think. It doesn't matter how smart you think you are, statistically speaking you're not smarter than a compiler.

Ha, sorry - I just really love Rust and want others to at least try it. I passed on it for _years_ because I thought like the OP (I used to code in Scala - I personally find THAT takes cognitive load to remember all the features. Rust feels small to me in comparison). Rust made me LOVE to code again and I just think there must be others out there who would feel the same if they just tried it.

> Some people don't like Rust and that's okay.

Agreed, I'm sure it isn't for everyone.

It took you average movie time to learn whole entirety of language? Wow!

And without sarcasm, yes, sometimes it is the case.

I enjoyed learning Nim syntax through exercism.io (not affiliated, just really enjoy it as a tool), but I'll be honest that I have no clue if it will become an ungoverned mess or thrive.

1.) Moves / borrowing / memory model 2.) Adopting a more functional style [to support 1.)]

My observation is that a lot of people /really/ want Rust to be imperative and treat it very imperatively they fight the borrow checker way more than if they adopt the idiomatic norms of Rust. There are some edge case data structures that can be a little painful and require some specialized knowledge, but once you are into Rust I don't even think it is unpleasant for side projects and general purpose hacking, but to get there it demands a higher level of mastery than most languages, but when you get there it can feel extremely productive.

I also regularly run into utterly infuriating bugs while trying to accomplish what I thought would be simple things. Don't expect to be able to get anything useful done using iterators. They're zero-cost only if you don't value your own time.

On the other hand, all of Rust's docs are a joy and I haven't run into many technical problems so far.

I kept hearing the comparisons to Python so I thought it'd be interesting to pick up but the syntax and naming was so counter to Python that that expectation made me immediately bounce off of it.

My main language is Python, to that I'd like to add a compiled, native code, fast-ish, statically typed language with good Python interop. That takes away JVM and .net languages and leaves, roughly, C++, Rust, Nim, maybe Go. I take Go off because I don't like it. I also can't stand modern C++. What does it leave me with?

They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and (in my experience) they have less superfluous refactoring sessions due to the overly conservative nature of the borrow checker. I like how Matt Welsh put it in https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...:

> What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again.

Perhaps you're instead speaking of a specific situation or kind of program where the borrow checker happens to be no harder than any other language?

At my job, I'm writing in Go. I fairly sure I could easily port the C code to that. It would probably run a bit slower, but the algorithm and data structures would be readable, and extendable.

So: it depends.

And the "?" operator is way more ergonomic for throwing actual errors up a level than all the boilerplate in Go.

The pattern matching with `match` `if let` and `let else` are pretty easy to use to unwrap Result and Option enums.

And then the "anyhow" or "thiserror" crates make it all more ergonomic.

The end result is something is much more readable than all the error handling in Go, while still being at least as safe if not more safe.

Plus you wind up playing with Monads without needing to know what the hell an endofunctor is.

And there's no null/nil, while Options have to be explicit and if you squint (because of the presbyopia) they look kinda like the nillable stuff in C# 8.0

While it is possible to "catch" a panic in Rust, this is not an error-handling strategy, it is a correctness fallback. The intent is that, if you're writing a Rust library that exposes a C ABI, you halt the panic at the boundary of your library, because there is no standardized cross-language unwinding scheme and so unwinding across an FFI boundary would be UB. It's not there for error handling (and it can't be, not only because the API is deliberately designed to discourage it, but also because Rust programs can be compiled in a mode where panics abort instead of unwind).

> Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end.

This is a bit inaccurate. You can absolutely do things like divide by zero in a Swift function that isn't marked as `try`, which will crash the program. This is the same behavior that is expected of panics in Rust.

Rust's memory safety protects against data races. AFAIK, Swift does not.

> Swift also is much more principled when it come to certain things like exceptions. Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics, Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end.

Generally in Rust, a panic means the program has entered a state that is unexpected by the programmer. One example is an unexpected index out of bounds error.

For cases where an error is an expected program state, like a web request or input validation, it's recommended to use `Option` or `Result` instead. Rust will force you to handle the error case.

Yes, any function can panic, and any caller can catch panics, but panics are not the primary "exception" analogue in Rust. Panics are only for fatal errors.

I don't know anything about Swift, but from a quick search I see something called "Fatal Errors", which I assume act a similar way.

Now to address the points in your gist.

> lauded the Borrow Checker for discouraging people from using the borrow checker! This results in less performant code much of the time.

The borrow checker is much improved with non-lexical lifetimes which makes it far easier to deal with.

> The escape hatch of macros and build-time source generation has allowed Rust to sweep some of its usability issues under the rug (Just use a macro!). Swift strives to support all of the use cases developer have in the language itself

I have no idea how you could, for instance, implement something like `serde` without macros or reflection without building it into the language. Other common uses, like `lazy_static`, have been replaced with better APIs that don't use macros at all. Building these things into the language or standard library without enough experimentation beforehand can be problematic, as `lazy_static` shows.

Rust's development is more open than Swift. It doesn't have the luxury of a single owner that can dictate THE WAY to do things, because it must support use cases from web servers to embedded MCUs. Macros and other forms of build-time execution provide that flexibility.

> Coarse Imports

Personally, I think Rust's module system and imports area the best I've ever used. As I said, I've never used Swift. Are all of the standard library functions in a single namespace?

I imagine that this makes implementing things like refactoring much easier.

> First party IDE > > Say what you want about Xcode

Xcode is MacOS exclusive.

> With the current state of RLS, developers often forsake modern IDE features even though reliable code completion, refactoring tools and diagnostics greatly benefit developers.

RLS is now deprecated, and rust-analyzer is fantastic.

> Out-of-the-box debugging experience

I haven't ever tried interactive debugging with Rust, so I can't comment.

> One of the more powerful uses of a type system is to have functions perform different processing based on the type of its arguments.

I think one of the fundamental difference of today is that this should be handled by traits, not by standalone functions.

> In Rust, this is achived via the From and Into mechanic. The first unfortunate consequence of this is that you often have to create a new type and trait pair per argument you want to be polymorphic.

I don't think this is a common pattern at all. Generally you'd just implement the trait for each type and put the different behaviors in the trait impl, rather than in the function using an enum.

> you can effectively only ever have one generic implementation of your custom into Into… for a trait, since otherwise the type checker complains there can at some point in the future be a collison.

This is only true for types outside your crate.

> In Rust, you cannot create trait objects out of certain types of traits. Often, you could use trait objects for this type of thing, but I haven't figured out a way to do this with more complex constraints. For instance:

    trait Bar {}
    trait Baz {}
    trait Foo {
        // This is invalid
        fn foo(t: &(Bar + Baz)) -> ();
    }

    trait Foo: Bar + Baz {
        fn foo(&self);
    }

> Making it generic disallows using Foo as a trait object:

    trait Foo {
        fn foo<T: Bar + Baz>(t: T) -> ();
    }
    // This is invalid
    fn do_work(f: &Foo) -> () { … }

    trait Foo<T: Bar + Baz> {
        fn foo(&self, t: T);
    }

They are a work in progress, available in nightly: https://github.com/rust-lang/rust/issues/53667

But they do require an extra level of parens in some cases, though I think that's insignificant.

> Guard Statements

Rust has these now as "let ... else" statements.

    let Pattern(binding) = thing else { ... };

This was covered above: use Result or Option instead. Panics are not exceptions.

And as for unwrap, yeah you just have to know that it will panic. It's just a thing you have to know about the language, like `try`.

> Rethrows

Transpose is stable now. But generally for that case I'd do this instead:

    let y = Some(1).ok_or(Error)?.and_then(|i| {
        if i > 3 {
            Err(Error)
        } else {
            Ok(i + 1)
        }
    })?;

I prefer the lack of a ternary, since, as you show, an if can do the same thing.

> String Interpolation

You can include variable names inline now. And they're not C-style at all.

> Named arguments

Personally, I've never felt the lack. Especially with the inline hints from rust-analyzer.

> Default arguments

I actually prefer how Rust does not have function overloading. This includes default arguments and optional arguments.

> Function-level polymorphism

And the above also applies to this.

> This is also useful for operators (in Swift, + is a polymorphic function)

This is implemented with traits in Rust.

> Alternatively, you could use use:

    use MyDescriptiveEnum as E;
    match e {
        E::Foo => …,
        E::Bar => …,
    }

    use MyDescriptiveEnum::*;
    match e {
        Foo => …,
        Bar => …,
    }

Rust enums have this for primitive numeric types, but others do not.

> Rust's enum and struct initializers all use different syntax. In Swift, there is a single syntax

Sure, they both use parens, but they are still different syntaxes.

> Trailing Closures

I don't like this. Seems like a special case for little to no reason.

> Default Closure Arguments

Same as the above.

> Extensions, Type Inference for Associated Types

I agree these could be useful improvements.

If Nim does not get a general purpose, batteries included web framework it will never reach escape velocity and will be left in obscurity despite all of the incredibly difficult and marvelous work Araq and the team has done.

I want them to succeed. I love the language!

Companies rarely pay for totally rewrites. Nim compiles to C and offers safety that can work on top of codebases without a re-write.

I honestly haven't found this to be the case. There is a constant denial that some people might find Rust difficult (with a very strong implication that if they do, it's because of inferiority on their part), and extreme thin-skinnedness towards even the possibility that Rust might not be for everyone. Indeed, a bluff assertion that it is for everyone is part of its official tagline. The community keeps up a surface politeness, but it always looks to me that it achieves this by keeping a tight lid on dissent (or appearance thereof).

Beyond Rust, Apple has swift, Google is working on "Carbon," and there's a ton of active work on improving the safety of C++. The future is exciting, but there is a lot more than just Rust in it.

On the other side, Delphi is still being enhanced and FPC tries to be compatible with it, so there are not stuck in 1982.

It's free, fast (enough), and exceptionally easy. If you need a supported system then even Delphi is back to being (not totally un)reasonably priced once you consider that they only charge when you begin earning from it. Their threshold is very low, but by the time you reach it you've tested your idea and got sales.

As for Pascal standards, I'm not entirely sure why there would need to be a recent one. Standards bodies have their place, but their activity is pretty much never something I ever give a thought to when deciding on software tooling.

It would be a stretch to say they demonstrated that it’s better to enforce a standard.

Black, itself, changed rules many times within a 1-year period to the point our own CI would fail on existing code that previously passed.

yes, having languages establish an immutable standard for tabs vs spaces has clearly ended all debate over them.

  let traversed-distance := yard-length;

  let traversed-distance := yard - length;