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,…
Choosing Nim out of a crowded market for systems programming languages
201–210 of 271 posts
Re: Choosing Nim out of a crowded market for systems programming languages
#202Earlier 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).
Re: Choosing Nim out of a crowded market for systems programming languages
#203Earlier 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
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
#204Hmm.. wonder why Pascal isn't on the list
Re: Choosing Nim out of a crowded market for systems programming languages
#205Earlier 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…
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?
Re: Choosing Nim out of a crowded market for systems programming languages
#207I'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.
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
#208I 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…
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
#209Chef‘s kiss.
Re: Choosing Nim out of a crowded market for systems programming languages
#210Earlier 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.
Happy to see that it's getting frequent commits, would love to see it become more popular.