Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

201–210 of 271 posts

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

#201
post #94

Earlier quoted context omitted.

> 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 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.

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

#202

Earlier quoted context omitted.

Oh boy, that is so not true. Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, and a nightmare in Rust. At least if you want the same level of performance and a similar modeling of the data

Rust lifetimes are just the lifetimes of the memory, exactly the same as C. The only difference is you simply need to (sometimes) tell Rust where the memory for a reference comes from explicitly, where as in C you don't (but in C if you get it wrong your program will segfault, unlike Rust, or worse it might not...sometimes).

Well yes, lifetimes also exist in C, but it is only in Rust that they are compiler checked

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

#203

Earlier quoted context omitted.

If you were clever enough to write it safely in C I can guarantee you'd be clever enough to write it in Rust.

Oh boy, that is so not true. Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, and a nightmare in Rust. At least if you want the same level of performance and a similar modeling of the data

Um, lifetimes are not a made up concept of rust to be in your way. It helps you understand issues that would be real and undetected in your C app.

Your C app would work by happy accident and you would not notice until later when data is corrupted in another part of your program. This is the rest of us wanted to leave C/C++.

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

#205

Earlier quoted context omitted.

The easy pattern of graph structures is handled by the easy implementation of adjacency lists, which is how you should have been implementing it in other languages too. The specific incompatibility is with the naïve hand-implementations of these structures; the specific thing Rust does not optimize for is toy code.

You know nothing of what I'm programming. You don't know when, whether, or how my program accesses or deletes data. You don't know what domain I'm in, whether I'm on a team, or what our priorities must be. And yet, you proclaim that your approach is how I should always do it in any language, in any situation. It strikes me as particularly convenient, seeing as that's the only approach that the borrow checker can reas…

No need to take it personal. I don't think the "you" OP used referred to you specifically.

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

#206

> OCaml, Haskell, F#, and other weirdos: I personally can't do it. I tend to not like functional programming languages. I want to, but my brain lacks the plasticity to relearn everything. Why would you find OCaml hard to learn if you know Nim? Isn't Nim a functional programming language as well? Also, how is Nim for writing real-time games that run via JavaScript where you want to avoid garbage collection pauses?

Same way you avoid them directly in JS. I don’t think Nim claims it’s easy to do.

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

#207

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 Rust on the job.

The decision to learn a programming language comes down to three options:

- Popularity

- You are paid to learn

- You are passionate about it, and you don't expect to collaborate with anyone.

Number 3 is the reason why I am learning Nim.

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

#208

I tend to be a C with objects (compiled with a C++ compiler) type of person because I think things like the base string, memory blob, etc types in C should have the ability to have bounds checking built in at compile time if the programmer chooses. Simply fixing the few things "wrong" with C I tend to think gets you 95% of the way to a heavier weight environment like java/etc. So, I can't help but feel that all these…

> So, I can't help but feel that all these languages are trying to solve that last couple percent, and paying a huge price in perf or programmer productivity to do it

I'm the first to admit that Rust has a steep learning curve. But now that I'm proficient in it, and as a long time C++ programmer, Rust is easily 2x more productive for me, and WAY more enjoyable. For large/complex codebases, the gap is even bigger IMO. But yeah, it takes a lot to get over that initial hump. It really helps to have a mentor for the first couple months.

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

#210

Earlier quoted context omitted.

Memory things, sure. There is the whole concurrency/parallelism thing, though.

Pony is a great example of fearless concurrency without the borrow checker's difficulties.

It's a shame how seldom this language comes up in discussions, I toyed around with a few years back and it was wonderful even back then.

Happy to see that it's getting frequent commits, would love to see it become more popular.

Post reply on HN