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

Nim version 2.0.0 release candidate

nim-lang.org

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Nim version 2.0.0 release candidate

#61

Post by planetis »

v3ss0n wrote: post #47
synergy20 wrote: post #14

among nim, zig and rust, I'm most likely to learn nim, it has been there for a while and it is solid and has so many good stuff in it, it just needs more 'marketing'. in particular, python really should help its popularity as their syntax are similar and both are very expressive.

Nim community is pretty much against python developers. The founder is vocal about that.

No one is against Python developers, you're clearly exaggerating, I would ask for a source but we both know it doesn't exist. What people try to convey the whole time to people coming from python, which I was years ago, is that nim is not compiled python. It's a totally different language. I am sorry that message sometimes gets lost in translation but I don't know what would be clearer than this recent thread.

https://forum.nim-lang.org/t/9737

Re: Nim version 2.0.0 release candidate

#62

Post by isofruit »

tryptophan wrote: post #26
Symmetry wrote: post #11

Earlier quoted context omitted.

I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.

It is a strange feature but it does have a good underlying idea. Why would having two functions, named makeFile and make_file in the same program ever be a good idea? Think of it as less of a language syntax feature and more of a code style enforcement paradigm. Good lsp support makes it mostly fine imo.

Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`.

Not being forced into other people's style choices is a really nice boon to me.

Re: Nim version 2.0.0 release candidate

#63

Post by isofruit »

throwaway_au_1 wrote: post #31
lostdog wrote: post #30

Earlier quoted context omitted.

Anyone who wants to use grep will just keep ignoring nim. Case insensitivity is pretty silly, and underscore insensitivy is just really silly. The way that modern languages force a single style is great, and it's a big strike against nim, which is an otherwise nice language.

Ironically they reject tabs and require space indentation. Something something the complexity of supporting both. Yet we have style insensitivity..

To be fair, you can tell your IDE to just turn tabs into spaces and call it a day, that's an issue for all of 5 minutes.

What you can't do is tell your IDE to interpret camel-case as snake-case if you want (or vice versa), just because this package you really need uses camel-case and you want to use snake-case.

Re: Nim version 2.0.0 release candidate

#64

Post by isofruit »

darthrupert wrote: post #52
cauthon wrote: post #33

Earlier quoted context omitted.

A contributing factor may be lack of a major sponsor bootstrapping the user base. Go had Google, Rust had Mozilla, Nim was/is largely indie.

Like the most popular language per Tiobe, python.

To be fair, python back then didn't have great competitors in its space. I guess Perl, but from what I still remember from Perl before I dropped it like a hot potato a couple days in, it wasn't particularly great.

Nim does.

Re: Nim version 2.0.0 release candidate

#65

Post by diimdeep »

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms.

It is like TypeScript to JS in C/C++ world.

Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

Re: Nim version 2.0.0 release candidate

#66

Post by planetis »

lostdog wrote: post #30
matthiaswh wrote: post #12

Earlier quoted context omitted.

It's apparent from the RFC discussion that there is no consensus on the topic. With little (proven) tangible benefit of making the change, and a large potential for backlash within the small existing community, I'm not certain it's worth the risk for Nim to make this move. https://github.com/nim-lang/RFCs/issues/456

Anyone who wants to use grep will just keep ignoring nim. Case insensitivity is pretty silly, and underscore insensitivy is just really silly. The way that modern languages force a single style is great, and it's a big strike against nim, which is an otherwise nice language.

Its not an actual issue, it is the projected experience of another language and/or IDE/ tooling. Fyi the newest GitHub ignore case. But I have been using grep with nim code daily and it was not an issue.

Re: Nim version 2.0.0 release candidate

#67

Post by isofruit »

v3ss0n wrote: post #47
synergy20 wrote: post #14

among nim, zig and rust, I'm most likely to learn nim, it has been there for a while and it is solid and has so many good stuff in it, it just needs more 'marketing'. in particular, python really should help its popularity as their syntax are similar and both are very expressive.

Nim community is pretty much against python developers. The founder is vocal about that.

Given I used to be a python dev myself before I picked up nim and since then have helped out a fair bit of python-folks picking up nim, I'm not sure what that's based on.

The fact that nim doesn't have exactly the same stdlib defined as python (though there's a package for that)? That Araq has said that nim isn't a variation of python?

Re: Nim version 2.0.0 release candidate

#68

Post by elcritch »

diimdeep wrote: post #65

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

The distinction between compilation and transpiling is a bit imprecise, but yes. But oddly the basic C that Nim compiles to is fairly resilient and stable. I'd actually expect the Nim compiler to bitrot way less than languages based on LLVM, which have a very short half life.

So Nim's approach has some challenges, but surprisingly has less moving parts than you'd think. I'd be confident I could get the current Nim compiler up and running in 5, or 10 years with minimal effort.

However, there was a lot of effort to get things like pointers and strings in the stdlib to play nicely across the NimVM, JS, and C backends. Theres some gross details there. But in the end its beautiful.

Re: Nim version 2.0.0 release candidate

#69

Post by elcritch »

wyldfire wrote: post #15
rayiner wrote: post #9

Nim’s arc and sink/lent annotations seem a lot simpler than Rust’s owned pointers and region annotations. Has anybody had the opportunity to compare the costs and benefits?

> Has anybody had the opportunity to compare the costs and benefits? Heap allocators are very significant cost over stack. Nim's designed for different use cases. Rust statically checks memory usage, and provides Arc for use cases that can only be modeled dynamically.

Nim has good stack value support too. Heap vs stack is just treated as more an optimization thing. Rust's borrow checker is most useful for heap memory, not stack.

For stack based values Nim's 'var' and 'openArray[T]' are roughly equivalent to simple implicit lifetimes. I don't know the proper parlance vs more complicated lifetime situations like "capturing" a lifetime.

Its not too different to C++ references either. Sounds like D will also check for similar "lifetime" violations soon as well.

The real difference is heap memory. There Rust's lifetimes allow you to give ownership away. Nim's var parameters can't do that, but instead it gives you fast and cheap non-atomic ref counting. Rusts way does encourage slightly faster code on average at the expense of more effort on programmers.

Whether Rust or Nim, allocations are expensive. Though in my experience Nim's allocator is amazing. It can sometimes be faster to use ref's than stack values.

Re: Nim version 2.0.0 release candidate

#70

Post by elcritch »

throwaway_au_1 wrote: post #31
lostdog wrote: post #30

Earlier quoted context omitted.

Anyone who wants to use grep will just keep ignoring nim. Case insensitivity is pretty silly, and underscore insensitivy is just really silly. The way that modern languages force a single style is great, and it's a big strike against nim, which is an otherwise nice language.

Ironically they reject tabs and require space indentation. Something something the complexity of supporting both. Yet we have style insensitivity..

That actually makes whitespace syntax in Nim much better. Can't recall the number of times I copied Python code snippets and had to track down lurking tabs.
Post reply on HN