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

51–60 of 121 posts

Re: Nim version 2.0.0 release candidate

#51

Post by darthrupert »

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.

I had this gripe about it as well, but then I learned that you can force style in your own projects with a switch.

Re: Nim version 2.0.0 release candidate

#52

Post by darthrupert »

cauthon wrote: post #33
mrichman wrote: post #32

I haven't heard of Nim until now. I've been a Go programmer for years now, and I see a lot of potential. I wonder why Nim hasn't taken off. What's the catch?

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.

Re: Nim version 2.0.0 release candidate

#53

Post by haxscramper »

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.

This is not really true, most of the times the discussion goes like this

Q: "Why haven't you implemented feature X -- python has it, so nim should too"

A: "Nim is not python, it is a different language, not all things implemented there are good, so we don't implement everything"

So this is not "against python" it is against specific attitude towards nim where people think it should be a python clone instead of a separate language

Re: Nim version 2.0.0 release candidate

#54

Post by haxscramper »

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.

As someone who has been writing nim for many years now, using grep, rg, and various other search tools I can say that I've never had any issues with finding things I wanted. This is just one of those imagined issues that your realize doesn't exist when you actually try to do it.

Re: Nim version 2.0.0 release candidate

#55

Post by lostdog »

haxscramper wrote: post #54
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.

As someone who has been writing nim for many years now, using grep, rg, and various other search tools I can say that I've never had any issues with finding things I wanted. This is just one of those imagined issues that your realize doesn't exist when you actually try to do it.

Thank you, I have tried it, and it was frustrating.

Re: Nim version 2.0.0 release candidate

#56

Post by geenat »

Default values and named parameters, thank you! Golang has neglected both of these. Both seemingly rare yet highly productive features to be found in a compiled language.

Love the quick compile times and go-like single binary compilation.

Case-insensitivity seems very cool for interoperability. Total underappreciated gem.

My only hangup is the syntax feels wordy, but it's leagues better compared to Rust or Go in that regard. A bit concerned about the performance cost of using macros to cut down on the wordiness (I would do this).

Otherwise great to see a 2.0 and always keeping a close eye on the Nim ecosystem as I would definitely consider adopting it.

Re: Nim version 2.0.0 release candidate

#57

Post by planetis »

matthiaswh wrote: post #12
derbOac wrote: post #10

I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.

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

> It's apparent from the RFC discussion that there is no consensus on the topic.

That's your take? I can see a couple of actual nim users complaining, the rest are some randos that tried to derail any productive discussion with "I have an old C library that uses three different styles for init, how would I bind it to Nim?" and although a bunch of workarounds exist, they were too loud and stubborn. For me it showed that most nimmers prefer style insensitivity as an option, although they don't use it in the same project.

Re: Nim version 2.0.0 release candidate

#58

Post by adalacelove »

satvikpendem wrote: post #36
zozbot234 wrote: post #16

Earlier quoted context omitted.

Is syntax really that big of an obstacle to learning a first programming language? The semantics of a C-like language like Nim could hardly be more different to Python's, they're pretty much at opposite ends in the stack.

> Is syntax really that big of an obstacle to learning a first programming language? Of course. Compare, at the extremes, languages like APL or Brainfuck to something like Python or Scratch. Syntax is a huge factor in people wanting to learn to code or not.

Those languages have actually very different semantics too. I would say lisp is a better example of the importance of syntax.

People obsess (wrongly) about superficial details in my opinion.

Re: Nim version 2.0.0 release candidate

#59

Post by isofruit »

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.

Agree to disagree. I don't want to force my users to use snake-case just because I use camel-case and vice versa.

There's options to turn it off, options to turn it into a warning when you have style issues so you can make them consistent and it prevents similar names that shouldn't exist in the first place by causing compiler errors (if you have is_ok you should not have isOk in the same scope, what are you doing). It is just not a big deal, at all. And as stated, it is not hard to ensure consistency within your codebase by heeding compiler warnings/errors.

Re: Nim version 2.0.0 release candidate

#60

Post by isofruit »

aquova wrote: post #27
derbOac wrote: post #10

I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.

It's one of those things that, as a Nim hobbyist programmer, I think is a neat feature to have, but I could see being a big hesitation for use in professional environments.

Given that you tend to use linters in those environments as well and that you can turn it off anyway, I'd disagree on that one. There are other factors that would make me hesitate in a professional environment much more, such as community size and talentpool.
Post reply on HN