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

81–90 of 121 posts

Re: Nim version 2.0.0 release candidate

#81

Post by xigoi »

v3ss0n wrote: post #48
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.

My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different. That's the real problem

Rarely a problem. Why would you have two procedures named do_me and dome with the exact same signature?

Re: Nim version 2.0.0 release candidate

#82

Post by xigoi »

igetspam wrote: post #42
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 never explored nim but was was just about to follow the link, you have effectively convinced me to not bother. I can imagine the arguments for case insensitivity (not agree with them but I could live with them for certain tradeoffs), I can't find a place in my brain where "underscore insensitivity" could have existed as a concept before reading those words.

Just treat Nim as style-sensitive and you'll probably never run into a problem with it. Seriously.

Re: Nim version 2.0.0 release candidate

#83

Post by xigoi »

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.

Why?

Re: Nim version 2.0.0 release candidate

#85

Post by cb321 »

TylerE wrote: post #79
geenat wrote: post #56

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…

Macros shouldn’t have any performance implications. The whole point is that they happen at compile time.

He did mention "quick compile times" as a draw and macros can slow down compile times/that kind of performance, but sure run-time performance of compiled code should be unimpacted.

EDIT: FWIW, compile-times impact mostly just depends on what he wants to do. The macro evaluator not that slow a virtual machine. Simple substitution macros tend to run quite fast. But it's also easy (with loops!) to generate a large pile of Nim code that generates a ginormous pile of C code that the backend might have to chew on for quite a while.

Re: Nim version 2.0.0 release candidate

#86

Post by darthrupert »

isofruit wrote: post #64
darthrupert wrote: post #52

Earlier quoted context omitted.

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.

Python vs Ruby seemed like a real fight for a while, especially when there was Rails and python did not really have anything equivalent.

Re: Nim version 2.0.0 release candidate

#87

Post by leetnewb »

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?

Nim 1.0 was released 2019. Python3 was released 2008, Go 1.0 2012, Typescript 1.0 2014, Rust 1.0 2015, Kotlin 1.0 2016.

It might be premature to judge Nim's popularity, respective timelines considered. At the same time language options are probably nicer in 2022 compared to 2010, so it will be harder to take off.

Re: Nim version 2.0.0 release candidate

#89

Post by cb321 »

darthrupert wrote: post #86
isofruit wrote: post #64

Earlier quoted context omitted.

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.

Python vs Ruby seemed like a real fight for a while, especially when there was Rails and python did not really have anything equivalent.

Python languished as an obscure niche language from its inception in the late 80s until at least 2000. I recall discussing it with friends all during the 90s to blank stares and shaking heads. Rapid adoption (of, well, anything) is a network effects game. In the very early 2000s Python really took off (basically Python 2.x).

It surely helped that well known companies like Google (pre-IPO, "ad free & proud of it" back then) started openly saying they used it, but like many network effect things, it's probably hard to pin down any one "cause" (but easy to fool yourself into thinking you have, e.g. Google also said they used Perl). The Numeric module existed, but data science was not very strong until Travis united the numarray/Numeric things into NumPy. [1]

https://en.wikipedia.org/wiki/History_of_Python has more details, but it does not have a nice plot/chart of "How weirdly do your software friends look at you when you bring up Python..." which has, shall we say, a "data collection problem". :-) Proxies for such data might be interesting case studies in the sociology of programming languages, though.

[1] https://en.wikipedia.org/wiki/NumPy

Re: Nim version 2.0.0 release candidate

#90

Post by isofruit »

pyinstallwoes wrote: post #88

Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?

I only know a hand full of languages so make of that what you will. I came from a python background and hadn't learned a compiled language before, so I wanted to experiment. Tried Rust for quite a while, but found the syntax not clicking with me though a lot of ideas seemed intriguing (pattern matching and Result types). Didn't want to try C/C++ because I wasn't that hard into figuring out how memory works and at the same time was pretty shocked at how C considers types.

That only leaves go after that, which I heard about around the same time as nim. I started out with nim and I liked it enough so I stuck with it.

Why I use it over other languages? I feel like I can express myself in english readable sentences (which gives it the python vibe for me) and at the same time I have static typing, a really nice type system in general and very little chance of crap like nullpointers occurring.

My first ah-ha moment was pretty much 3 hours in when I noticed I could already already write simple stuff and only needed to consult the std lib docs here and there. The second was when I reimplemented a webserver backend that I previously had in Django (not for practical reasons, just to see how fast it could go even very little optimization) and found it performing roughly 2-5 times faster (measured by looking at request response time), despite having optimized Django's ORM to as few queries as physically possible to get the data I needed. (For reference: That's quite surprising given a decent chunk of that time is literally just network latency)

Post reply on HN