Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

211–220 of 271 posts

Re: Choosing Nim out of a crowded market for systems programming languages

#211
post #56

Earlier quoted context omitted.

Ugh, as a C++ programmer - for the love of god don't choose the language for career stability. Both the language and the ecosystem is horrible. Choose it if you need it work in the domain of your choosing. For me it happens to be the case. If you want to choose a career language go for any of the other TIOBE usual suspects. I completely agree that if you want to be a career programmer, focus on solving problems for b…

What's wrong with C++ stability? You think things are looking better in JS/Python world? They both changed tons and the knowledge you accumulate constantly needs to be tweaked and relearned.

I perhaps used words in a confused combination. There are two connotations to stability here - 1. language and ecosystem standardization and 2. having a stable and predictable career. C++ has both a plenty (2. if you find your niche and then you are nigh irreplaceable, but not perhaps at FAANG rates).

Your knowledge never gets old, basically in C++.

The problem with C++ is that it is a horrible language in several ways. I guess the root cause is that it's basically a sugared C preprocessor with an infinite amount of special rules and special cases, that attempts to retain backward compatibility while adding new features. If my domain did not need it I would not write it. But it does, so I do.

My advice not to choose C++ because of career stability meant - "It's a bloody awful thing! Don't choose it if you have options unless you absolutely want to!"

Re: Choosing Nim out of a crowded market for systems programming languages

#212

Earlier quoted context omitted.

> The Rust community is however, an excellent community to be part of. 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 ever…

I've experienced this as well. Any disagreement always comes down to "you just haven't used it enough". I let myself take that gaslighting for years before I decided to just not go to the Rust servers any more. And then when you question any of the classic Rust axioms (such as safety or speed being only desirable rather than an absolute commandment) a lot of them tend to get rather hostile. It's not a pleasant crowd…

Sorry to hear that. I certainly don't think Rust is ideal for every use case. And it is definitely hard to learn. I think people get a bit too zealous promoting it, simply because it has solved a lot of painful problems that many of us have battled with for decades in C++/C land.

Re: Choosing Nim out of a crowded market for systems programming languages

#213
post #34
post #8

Earlier quoted context omitted.

Nim is also easier to learn - if you know Python and any conventional statically typed language, it's a walk in the park. I was producing fast, working code in a couple of hours. Learn Rust for your job, Nim for your side projects.

I'm learning Rust now, I can say Nim is much harder. Maybe the language itself is simpler, but the documentation is just not very good. Very unpolished and amateurish. I actually forked out fifty quid for Araq's "Mastering Nim" book; it is atrocious. Spelling and grammatical errors on every page. The very first code example did not compile. I also regularly run into utterly infuriating bugs while trying to accomplish…

Did we read the same book? I find Mastering Nim a pretty excellent reference. (And you have to install the pixels library :-P)

The online documentation, certainly, could be better. I sometimes find standard library documentation lacking in examples, and compiler documentation is currently undergoing a massive refactoring effort on a couple of fronts. But the manual (https://nim-lang.github.io/Nim/manual.html) isn't half bad.

Re: Choosing Nim out of a crowded market for systems programming languages

#214

Earlier quoted context omitted.

Can we please not do this? It's fine to give a different viewpoint, but it's surprisingly common that whenever someone says anything bad about Rust, a Rust user comes in to say that they just haven't used it enough. It's like saying "If you don't like my favorite movie, you just haven't watched it enough."

It's not even the right category of criticism. The author talks about 'mathematical purity' which is something Rust sneers at. Spend just a little while with Rust and you can see that when the language is getting in your way, the driving direction it is pushing you in is towards code that will be maintainable . Which is still not about getting shit done, and is still a valid axis to prefer Go's rapid development cycl…

I kinda agree, it's weird to me how people make a big deal about the borrow checker as if it's an evil spirit gatekeeping your code.

And if you wanna go fast instead of writing maintainable code you surely can with stuff like unwrap(), clone(), Copy.

In a way I think most people expect to pick up Rust more easily because they have expertise in other languages and are surprised when Rust feels like learning to code again, basically turning some ingrained assumptions upside down.

It really is not the kind of language where you can glaze over the introduction chapter and churn a TODO app in the same afternoon in my opinion.

Re: Choosing Nim out of a crowded market for systems programming languages

#215
post #148
post #30

> [..] 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 am curious about the safety, though. This minimal example causes a segfault: type Foo = ref object a: int var foo: Foo = nil echo foo.a which wouldn't be simply possible to type in safe Rust.

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
Discussion about not nil by default is here: https://github.com/nim-lang/Nim/issues/6638

Re: Choosing Nim out of a crowded market for systems programming languages

#216

Nim desperately needs a real web framework (batteries included) and a proper ORM and it will take off like wildfire. Python on steroids.

There is this attempt at a batteries included web framework: https://github.com/jfilby/nexus

Re: Choosing Nim out of a crowded market for systems programming languages

#217

What’s the LSP and linter/formatter story these days? Last time I tried it the lsp was miles behind what I am used to from TypeScript land in vscode. I have gotten sooo used to all the auto completion, helpful error tooltips and auto imports and formatting on save that it felt tedious not to have that in a similar capacity. Maybe I was just doing things wrong and it’s been a while. In general I am super intrigued by…

It's alright when it doesn't crash. But it frequently crashes. Tooling is definitely a weakness of Nim (although it's improving).

More specifically: right now auto completion is excellent, implicit type annotations are excellent, error tooltips on save work, broader rename/refactor support is limited/nonexistent, formatting on save is fine, auto imports don't exist (and probably shouldn't given that it's typical to use unqualified namespaces).

Re: Choosing Nim out of a crowded market for systems programming languages

#218
post #201

Earlier quoted context omitted.

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,…

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 and Result available, etc.

It's certainly a language that encourages programming in a functional flavor, even if the lang itself isn't functional.

Re: Choosing Nim out of a crowded market for systems programming languages

#219
post #176

Earlier quoted context omitted.

> code up to error handling in professionally written code Lol, if you knew how much python code runs the world without even checking for exceptions, or with a try/except/pass ... and the world keeps on spinning. "professionally written code" made me chuckle

Yeah I'm done with the trolls here.

I never understood the pearl clutching going on when people hear that Rust has different constructs for handling errors and control flow and if/else stuff is kinda an antipattern.

Same kind of people that would hold dear GOTO statements in my opinion.

Re: Choosing Nim out of a crowded market for systems programming languages

#220

I'm choosing between learning Nim or Rust. Nim frankly looks like the nicer of the two, but also less marketable and with smaller community. Suck to say but it's true.

I honestly don't think your options should be between Nim and Rust. Nim has a very small community, and almost nobody is hiring for Nim experience. Going through Nim's forum, I think most developers tend to work on Nim projects alone. If marketability is your priority, learn the popular languages like java, c, c++, golang etc. Even people hiring Rust developers usually have some leeway to hire someone who can learn R…

[deleted]
Post reply on HN