Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

Post reply on HN
Print view View original

181–190 of 271 posts

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

#181

Post by hbogert »

BenFrantzDale wrote: post #45
LAC-Tech wrote: post #11

Earlier quoted context omitted.

The issue with D is it still feels unpolished. Every time I try it - which is maybe once a year or so - the experience still feels weird and edge casey. The idea that a GC is somehow a hindrance to language adoption doesn't make any sense to me at all. Doesn't stop people loving Go. But go has slick tooling.

I had one experience with Go. It was slow because the GC kept kicking in. So we won’t use Go again in favor of time-tested C++. GC is a major reason we are using C++ over Go. In my mind it’s a half-speed language. I’m also very put off by Rob Pike’s “Look, we replaced C++!” attitude when he somehow doesn’t seem to grok zero-cost abstractions. C++ has plenty of issues, but it doesn’t have GC and it goes further, provi…

Rob pike said they intended to replace c++, that didn't happen to his own accord.

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

#182

Post by cropcirclbureau »

moldavi wrote: post #169
mumblemumble wrote: post #160

Earlier quoted context omitted.

The doubly linked list thing strikes me as more of an illustration of cultural differences between C programmers an the rest of the world than as a straightforward criticism of Rust. 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, b…

It's not just doubly linked lists. They're just a basic example of borrow checking not being able to handle a lot of easy patterns that are perfectly safe in other languages.

Perfectly safe at the expense of a garbage collector. You can still do pointer soup and int handle based lists as you can do in any other low-level language with the same caveats. Rust is punching up from the manual memory management, zero-cost abstraction plane and competing with the garbage collected langs. It's still at it's core a tool for writing low level code.

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

#183

Post by culi »

127 wrote: post #41

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

> With Rust I have no idea what to use after trying 5 different libraries.

Seems like GTK is the pretty clear frontrunner?

https://www.areweguiyet.com/

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

#184

Post by moldavi »

cropcirclbureau wrote: post #182
moldavi wrote: post #169

Earlier quoted context omitted.

It's not just doubly linked lists. They're just a basic example of borrow checking not being able to handle a lot of easy patterns that are perfectly safe in other languages.

Perfectly safe at the expense of a garbage collector. You can still do pointer soup and int handle based lists as you can do in any other low-level language with the same caveats. Rust is punching up from the manual memory management, zero-cost abstraction plane and competing with the garbage collected langs. It's still at it's core a tool for writing low level code.

GP was confused about why the doubly linked list case was so important, so I enlightened, it's an example of an entire class of the borrow checker's problems.

Your response isn't really relevant in that context, and instead escalates to a much larger debate, so best I not engage. Appreciate the thought though =)

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

#185

Post by StillBored »

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 languages are trying to solve that last couple percent, and paying a huge price in perf or programmer productivity to do it, at the cost of basically close to 0% bugs actually being reduced. Particularly when compared with C++ and Ada when used in a rigorous development environment.

Nim seems like the kind of thing (a veneer over C) I would want, along with an easy of interfacing to the rest of a C based project, but I always just tend to end up reaching for C with classes, when I need to get something done yesterday, and it needs to fit in a few K, or push the metal to the limit. Largely because I trust I won't get myself in a corner with it.

(PS: I too tried rust and tossed it as not ready, and not really solving the right problem. I don't tend to have memory concurrency bugs in either C or C++ because I don't try to be clever, instead defaulting to simple ownership models wrapped in C++ classes, or fully containing locking/etc in a single function that does all the work of both locking and unlocking the data structure in question and reading/updating it through a single entry/exit).

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

#186

Post by wiseowise »

weatherlite wrote: post #179
fsloth wrote: 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.

> You think things are looking better in JS/Python world?

Yes.

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

#187

Post by lenkite »

winrid wrote: post #65
_dain_ wrote: post #34

Earlier quoted context omitted.

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…

Yeah, I wrote an equivalent service in Java and Nim, and I just couldn't get Nim to perform as well as Java, and it wasn't even easy to write. Random segfaults, depending on memory manager used, random libraries requiring different memory managers, ORC being talked about a lot despite causing random segfaults, and so on. I really want to love Nim.

Author's take on Java is really funny.

"..the JVM's largesse isn't aging particularly well. It will die with my generation's retirement."

I call this fundamental blindness considering the JVM is improving dramatically year after year - now even supports lightweight concurrency like Go in 2022.

Java will still be alive and kicking when no one alive even remembers Nim.

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

#188

Post by anta40 »

TylerE wrote: post #156
anta40 wrote: post #154

Hmm.. wonder why Pascal isn't on the list

Because it’s 2022 not 1982? There hasn’t been a new Pascal standard in 34 years.

Not sure about the current state of ISO Pascal, at least there's no ISO D or Rust, either. D and Rust are defined by the official implementations.

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

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

#189

Post by platinumrad »

estebank wrote: post #168
francasso wrote: post #135

Earlier quoted context omitted.

I think you are overestimating the expressive power of lifetime annotations in rust, and how smart the borrow checker is

Anything you can express in C, you can in Rust. When it comes to pointer tricks you might have to use unsafe, but that is part of the language.

If only 50% of the community didn't think it was their job to scream at complete strangers for using that part of the language.

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

#190

Post by wiseowise »

ilovecaching wrote: post #33
bitexploder wrote: post #27

Earlier quoted context omitted.

That assumes a whole lot about their goals. If everyone sticks with C++ we would never have nice things like Zig/Nim/Rust that are advancing the conversation about how we should be doing systems programming tasks with code. C++ is quite influences by a lot of this. Like, let emm hack and learn. Also I think Nim is a very productive language to be hacking in and much easier to get going with than C++.

That take detracts from the amazing work people have done over the decades to research and implement improvements to C and C++. We can innovate without throwing things away, even if it may seem boring to the uninitiated.

> That take detracts from the amazing work people have done over the decades to research and implement improvements to C and C++.

What kind of argument is that?

> We can innovate without throwing things away, even if it may seem boring to the uninitiated.

You can’t innovate without breaking backwards compatibility. C++ is an evolutionary dead end that collapses under its own complexity, deal with it.

Post reply on HN