12 ms·

Nim in 2018: A short recap

201 points by tokai 8y ago

richardwhiuk 8y ago
This article doesn't really reflect the promise of it's title for me. It just feels like a list of what happened, rather than a summary of how Nim progressed in 2018...
- noir_lord 8y ago
  https://m.youtube.com/watch?v=xUsAKstP-AQ https://m.youtube.com/watch?v=xUsAKstP-AQ was mentioned in the article, text version would be nice but has more details.
StreamBright 8y ago
1400 issues open on Github? Isn't that a bit too high to be manageable?
- UntypedOpinions 8y ago
  Ansible has 3900+ issues and 1700+ open pull requests on Github...
  - jazoom 8y ago
    So you're suggesting Ansible's issue count is also unmanageable?
    - UntypedOpinions 8y ago
      I am merely suggesting popular open source projects can have a really large number of issues.
    - coldtea 8y ago
      No, he's suggesting thousands of open issues on successful projects are common...
- coldtea 8y ago
  Issues have a status one presumes -- 1000 "requests for new features" or minor BS complains don't matter as critical issues.
- gameswithgo 8y ago
  Rust has 4,500 dotnet core libs 2,600 donet coreclr has 2,000 Golang has 4000
- stabbles 8y ago
  Julia has 2400 open issues and 660 open PRs (http://kristofferc.github.io/post/julia_issue/ http://kristofferc.github.io/post/julia_issue/ 2017)
  - nudpiedo 8y ago
    but the size of Julia is much larger and it serves a purpose/focused market (nim aims to be a solution for everything and it is a master of none).
    - tokai 8y ago
      What do you mean? Julia is a general-purpose language too.
- porker 8y ago
  > Isn't that a bit too high to be manageable? Yes. See many past conversations on why Github Issues become unmanageable. Labels help to segment, but aren't enough. I find the number of 'open' issues a demotivator (bordering on depressing) for my projects, or when I look to work on others; even if most aren't issues but support questions/feature requests/on hold. If not triaged well, digging through to find the real bugs takes effort. Github tried with 'Projects' but I haven't seen many (any?) projects using them successfully. For individual workflows they seem to work well. Big projects have fallen back on milestones.
- nudpiedo 8y ago
  I think that's understandable, in spite of being a young niche/language the community oversells it continuously on larger communities (like HN) but it is that much polished. The promise: pythonic, cross compilable, fast solution for everything with readable macros. And in my opinion it is not like that, see my comment on the top level.
  - alehander42 8y ago
    You're right: there are a lot of bugs and this should be improved! However, some of those are subjective opinions: a lot of people do see it as pythonic in syntax, even not if pythonic in other decisions. It is cross compilable and fast and one can write readable macros and create readable DSL-s with it. All other similar languages have even bigger issue counts: this is a shallow metric to base a conclusion on.
- mratsim 8y ago
  Actually plenty of issues are RFCs and feature requests. We have a new RFC repos to brings a bit more sanity to the bug tracker: https://github.com/nim-lang/RFCs/issues https://github.com/nim-lang/RFCs/issues
- therockhead 8y ago
  Was looking at Flutter recently and it has over 4000 issues.
  - plopz 8y ago
    They can always just go the React Native route and blindly close them all. Problem solved.
ausjke 8y ago
More and more new languages are coming out these days. Language is not just about a compiler and a better syntax, it is a huge ecosystem too, which either means a successful community(e.g. Python) or backed up by big guys(Google, Facebook,etc) Life is short, for product development I am stuck with C, Python, Java, HTML/CSS/JS, SQL, that's about it and they're already more than I need and more than I can handle. Other than these obvious ones I may learn a little rust and dart in 2019, rust in particular seems interesting as a great fit to write standalone utilities.
- tokai 8y ago
  Nim is older than Go.
  - ausjke 8y ago
    Yes, but Go got Google at its back, and it made a huge difference. You either have a successful community, or a big entity, otherwise it's hard to have an ecosystem that is good enough for serious usage
    - FraaJad 8y ago
      So, why use Go then? Java and C# will beat in every metric you have listed here.
      - remilouf 8y ago
        Maybe not on the “life is short” metric. It is insanely fast to write production grade code in Go :)
        nimmer 8y ago
        Not really, Go is way more verbose than Python and Nim and the latter provides static typing.
        8y ago
zinclozenge 8y ago
Are algebraic data types and pattern matching possible in Nim? Googling shows that there are libraries (https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty for example) but basically amounts to deferring their implementation by way of the macro system/metaprogramming.
- beagle3 8y ago
  The pattern matching story has not reached a conclusion, though it is getting there slowly. But that’s an important Nim philosophy - do not put into the language things if you can efficiently and nice-syntaxly implement them in a library. Once pattern matching is sufficiently mature - if it is too slow as a macro library, or the syntax too cumbersome - it will likely find its way to a core language feature. But if it’s good enough, it will stay a library (possibly, but not necessarily, part of the standard library); why burden the language?
- alehander42 8y ago
  Algebraic data types are everywhere in Nim code: they are just called case objects(and they do have some differences compared to e.g. haskell, but often they are used in a similar way) There is also https://github.com/krux02/ast-pattern-matching https://github.com/krux02/ast-pattern-matching (optimized for usage in macros / metaprogramming) Yes: they all use the macro system, but this is a good thin IMO: it's better to leave the core language simpler and to build such abstractions on top of it.
alehander42 8y ago
More and more new stuff is happening in the ecosystem: a lot of newer crypto/utility/math libs from the status-im people NimTorch: a new Nim ML framework improvements in the other ML libs( Arraymancer, Neo etc) high level wrappers / DSL-s for a lot of existing libs/api-s web dev libs/DSL-s pattern matching libraries and a lot more that i am probably forgetting
azhenley 8y ago
Glad to see Nim on HN again. For those of you who haven't tried the language out, I highly recommend it. I have even been suggesting it to students who want to get out the mainstream language bubble (C++, JavaScript, Python, etc.) so that they can learn something different. They have really liked it!
nudpiedo 8y ago
I stopped trying Nim in 2017 when I found out that the only worth feature were the macros. Red flags I saw: * A return variable within procedures that works in the same fashion as an assembly routine with a registry * Mutable strings * Mutable everything * Hate speech against functional concepts in the community (with all the related biases that this brings) * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. * no clear consistent design direction * too many pragmas * too many pascal syntax mixed with other language syntaxes * no module namespacing * modules worked not much better than C libraries... (I am generalizing) * poor ecosystem made out of incomplete mutable libraries * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. After I realized about python was easily beating Nim in spead and readability only with the standard library without any optimisation on python's side (and Nim being fully compiled), my interest on Nim went down to 0. I thought there were other places were I thought I could better invest my time. Did something from that list changed? is there any reason to look at Nim again in 2019? did someone here had a better or different experience than mine? EDIT: format, reworded sentences, expanded opinions
- Nimitz14 8y ago
  > python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. I'm not a fan of Nim because types go after the variable. But the fact that you did not consider that you may have messed something up and just thought "yeah totally, a language built to compete with C++ is slower than python", really discredits your entire post.
  - nudpiedo 8y ago
    I do not go often for ad-hominem... but your nickname has "Nim" within it and python's IO and runtime is programmed in C which discredits nothing since we are not scoring anything, really
  - hellofunk 8y ago
    That’s quite a trivial reason to dislike a language! There are quite a few languages, including some very popular ones, like Kotlin, where the type comes after the variable.
mcdermott 8y ago
I've been toying with Nim over the past few months and really like it and hope its adoption picks up post 1.0. I've been using Python for 10+ several years and Go for the past two years and returning to them after a good Nim coding session always feels a little depressing. My favorite feature is the Uniform Function Call Syntax (UFCS).

201 points by tokai 8y ago

This article doesn't really reflect the promise of it's title for me. It just feels like a list of what happened, rather than a summary of how Nim progressed in 2018...

noir_lord 8y ago
https://m.youtube.com/watch?v=xUsAKstP-AQ https://m.youtube.com/watch?v=xUsAKstP-AQ was mentioned in the article, text version would be nice but has more details.

StreamBright 8y ago

1400 issues open on Github? Isn't that a bit too high to be manageable?

UntypedOpinions 8y ago
Ansible has 3900+ issues and 1700+ open pull requests on Github...
- jazoom 8y ago
  So you're suggesting Ansible's issue count is also unmanageable?
  - UntypedOpinions 8y ago
    I am merely suggesting popular open source projects can have a really large number of issues.
  - coldtea 8y ago
    No, he's suggesting thousands of open issues on successful projects are common...
coldtea 8y ago
Issues have a status one presumes -- 1000 "requests for new features" or minor BS complains don't matter as critical issues.
gameswithgo 8y ago
Rust has 4,500 dotnet core libs 2,600 donet coreclr has 2,000 Golang has 4000
stabbles 8y ago
Julia has 2400 open issues and 660 open PRs (http://kristofferc.github.io/post/julia_issue/ http://kristofferc.github.io/post/julia_issue/ 2017)
- nudpiedo 8y ago
  but the size of Julia is much larger and it serves a purpose/focused market (nim aims to be a solution for everything and it is a master of none).
  - tokai 8y ago
    What do you mean? Julia is a general-purpose language too.
porker 8y ago
> Isn't that a bit too high to be manageable? Yes. See many past conversations on why Github Issues become unmanageable. Labels help to segment, but aren't enough. I find the number of 'open' issues a demotivator (bordering on depressing) for my projects, or when I look to work on others; even if most aren't issues but support questions/feature requests/on hold. If not triaged well, digging through to find the real bugs takes effort. Github tried with 'Projects' but I haven't seen many (any?) projects using them successfully. For individual workflows they seem to work well. Big projects have fallen back on milestones.
nudpiedo 8y ago
I think that's understandable, in spite of being a young niche/language the community oversells it continuously on larger communities (like HN) but it is that much polished. The promise: pythonic, cross compilable, fast solution for everything with readable macros. And in my opinion it is not like that, see my comment on the top level.
- alehander42 8y ago
  You're right: there are a lot of bugs and this should be improved! However, some of those are subjective opinions: a lot of people do see it as pythonic in syntax, even not if pythonic in other decisions. It is cross compilable and fast and one can write readable macros and create readable DSL-s with it. All other similar languages have even bigger issue counts: this is a shallow metric to base a conclusion on.
mratsim 8y ago
Actually plenty of issues are RFCs and feature requests. We have a new RFC repos to brings a bit more sanity to the bug tracker: https://github.com/nim-lang/RFCs/issues https://github.com/nim-lang/RFCs/issues
therockhead 8y ago
Was looking at Flutter recently and it has over 4000 issues.
- plopz 8y ago
  They can always just go the React Native route and blindly close them all. Problem solved.

ausjke 8y ago

More and more new languages are coming out these days. Language is not just about a compiler and a better syntax, it is a huge ecosystem too, which either means a successful community(e.g. Python) or backed up by big guys(Google, Facebook,etc) Life is short, for product development I am stuck with C, Python, Java, HTML/CSS/JS, SQL, that's about it and they're already more than I need and more than I can handle. Other than these obvious ones I may learn a little rust and dart in 2019, rust in particular seems interesting as a great fit to write standalone utilities.

tokai 8y ago
Nim is older than Go.
- ausjke 8y ago
  Yes, but Go got Google at its back, and it made a huge difference. You either have a successful community, or a big entity, otherwise it's hard to have an ecosystem that is good enough for serious usage
  - FraaJad 8y ago
    So, why use Go then? Java and C# will beat in every metric you have listed here.
    - remilouf 8y ago
      Maybe not on the “life is short” metric. It is insanely fast to write production grade code in Go :)
      - nimmer 8y ago
        Not really, Go is way more verbose than Python and Nim and the latter provides static typing.
        8y ago

zinclozenge 8y ago

Are algebraic data types and pattern matching possible in Nim? Googling shows that there are libraries (https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty for example) but basically amounts to deferring their implementation by way of the macro system/metaprogramming.

beagle3 8y ago
The pattern matching story has not reached a conclusion, though it is getting there slowly. But that’s an important Nim philosophy - do not put into the language things if you can efficiently and nice-syntaxly implement them in a library. Once pattern matching is sufficiently mature - if it is too slow as a macro library, or the syntax too cumbersome - it will likely find its way to a core language feature. But if it’s good enough, it will stay a library (possibly, but not necessarily, part of the standard library); why burden the language?
alehander42 8y ago
Algebraic data types are everywhere in Nim code: they are just called case objects(and they do have some differences compared to e.g. haskell, but often they are used in a similar way) There is also https://github.com/krux02/ast-pattern-matching https://github.com/krux02/ast-pattern-matching (optimized for usage in macros / metaprogramming) Yes: they all use the macro system, but this is a good thin IMO: it's better to leave the core language simpler and to build such abstractions on top of it.

alehander42 8y ago

More and more new stuff is happening in the ecosystem: a lot of newer crypto/utility/math libs from the status-im people NimTorch: a new Nim ML framework improvements in the other ML libs( Arraymancer, Neo etc) high level wrappers / DSL-s for a lot of existing libs/api-s web dev libs/DSL-s pattern matching libraries and a lot more that i am probably forgetting

azhenley 8y ago

Glad to see Nim on HN again. For those of you who haven't tried the language out, I highly recommend it. I have even been suggesting it to students who want to get out the mainstream language bubble (C++, JavaScript, Python, etc.) so that they can learn something different. They have really liked it!

nudpiedo 8y ago

I stopped trying Nim in 2017 when I found out that the only worth feature were the macros. Red flags I saw: * A return variable within procedures that works in the same fashion as an assembly routine with a registry * Mutable strings * Mutable everything * Hate speech against functional concepts in the community (with all the related biases that this brings) * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. * no clear consistent design direction * too many pragmas * too many pascal syntax mixed with other language syntaxes * no module namespacing * modules worked not much better than C libraries... (I am generalizing) * poor ecosystem made out of incomplete mutable libraries * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. After I realized about python was easily beating Nim in spead and readability only with the standard library without any optimisation on python's side (and Nim being fully compiled), my interest on Nim went down to 0. I thought there were other places were I thought I could better invest my time. Did something from that list changed? is there any reason to look at Nim again in 2019? did someone here had a better or different experience than mine? EDIT: format, reworded sentences, expanded opinions

Nimitz14 8y ago
> python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. I'm not a fan of Nim because types go after the variable. But the fact that you did not consider that you may have messed something up and just thought "yeah totally, a language built to compete with C++ is slower than python", really discredits your entire post.
- nudpiedo 8y ago
  I do not go often for ad-hominem... but your nickname has "Nim" within it and python's IO and runtime is programmed in C which discredits nothing since we are not scoring anything, really
- hellofunk 8y ago
  That’s quite a trivial reason to dislike a language! There are quite a few languages, including some very popular ones, like Kotlin, where the type comes after the variable.

mcdermott 8y ago

I've been toying with Nim over the past few months and really like it and hope its adoption picks up post 1.0. I've been using Python for 10+ several years and Go for the past two years and returning to them after a good Nim coding session always feels a little depressing. My favorite feature is the Uniform Function Call Syntax (UFCS).