Live data from Hacker News

Nim 1.0

nim-lang.org

11–20 of 308 posts

Re: Nim 1.0

#11

> Type identifiers should be in PascalCase [1] I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent. [1] https://nim-lang.org/docs/nep1.html#introduction-naming-conv...

In C# the lowercased ones are keywords, some of which map to built in types. For example "string" is a keyword that always means the type String (System.String). The word name "String" could be a type that some nefarious person added to your current namespace

Re: Nim 1.0

#12
I was going to make a rant about sentimental versioning, but instead congratulations for reaching version 1.0

Re: Nim 1.0

#13
post #7

see also: https://nim-lang.org/araq/v1.html

It's interesting to hear the constraints the language developer wanted from the beginning (20k lines, macro system drives most of the language development) and the various compromises they had to make along the way. > Furthermore, we don't really know yet how to leverage a macro system in order to give us extensibility on the type system level, so Nim's core needed generics and constraints for generics. I'm curious t…

I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that has always seemed notable to me is that it seems to defer type checking of generic code until it is instantiated (this is what happens in C++), so these functions will all typecheck until you actually try to use them:

  proc foo[T](): float32 =
    result = "foo" + 4
  
  proc bar[T](n: T, m: T): T =
    result = n(m)(n)
In Rust, such functions would require some sort of explicit constraints on `T`, so it's more-or-less guaranteed to be instantiable (ignoring the issue of polymorphic recursion) and you don't get some error pointing to code internal to the function when the user applies types that don't work.

Re: Nim 1.0

#14
post #8

Congratulations Nim team! :D I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on. This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's s…

I’d add Swift and Julia to that list as well, and arguably Typescript too.

Re: Nim 1.0

#15

> Type identifiers should be in PascalCase [1] I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent. [1] https://nim-lang.org/docs/nep1.html#introduction-naming-conv...

I think it does set the built-in types apart for being built it. Also tradition?

Re: Nim 1.0

#16

> Type identifiers should be in PascalCase [1] I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent. [1] https://nim-lang.org/docs/nep1.html#introduction-naming-conv...

I like it. It lets the domain-specific types stand out.

Re: Nim 1.0

#17
post #8

Congratulations Nim team! :D I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on. This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's s…

Fortran has had pure functions and subroutines since well before any of the cool languages. Not that I recommend it in particular.

Re: Nim 1.0

#18
post #9
post #8

Congratulations Nim team! :D I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on. This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's s…

And it turns out Crystal 0.31 [1] is released! And it is ( or should be ) closing to 1.0 release as well, once Windows Support and MultiThreading matures. May be 2020? On the list of languages I only know the first few up to Zig, will need to check out the others. There is also one noticeable missing and that is Elixir. [1] https://crystal-lang.org/2019/09/23/crystal-0.31.0-released....

Curious why you're adding Elixir in this list ? It operates is in a completely different space than nim / zig, as far as I know (Not statically checked, heavy but powerful runtime, much "higher level" abstractions, etc...)

Not to prevent you from trying it, of course - to each and everyone their own...

Re: Nim 1.0

#19
I love nim! Wrote a several-thousand-line side project in it in 2015 and have rewritten it several times over, partially to improve the project itself, but also to keep up with language changes during the various alpha-releases. Did a little evaluation of Rust along the way, but decided my money was going to continue to be on nim. -- Congrats to the team, and thank you so much for making it happen!

Re: Nim 1.0

#20
Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?
Post reply on HN