32 comments

[ 2.9 ms ] story [ 52.5 ms ] thread
13 talks for about 7h30' of content (from 11 UTC to 20 UTC with 1h30' of breaks). very much looking forward to it!
That's a lot more talks this year. Can't wait!
that was my impression too, but checking against last year we actually had 16 talks over a timespan of 10 hours including breaks (this year they are 13 over 9 hours with same breaks): https://conf.nim-lang.org/2020/
Man still waiting for nim to get more traction such a wonderful language
Yes, seems others are also waiting for Nim to get more traction before they start using it.
I fantasize about creating an auto-translator to make any Python package available as a Nim library. Then anyone who thinks "I need Python but faster" would have an easier time trying it out.

But first I should probably leaen Nim! Have just been admiring from afar.

From the Readme, Nimpy is a language integration tool that lets you call Python from Nim. It also links to Nimporter which allows you to import Nim code as a Python package.

What I'm describing would be the inverse of Nimporter, allowing you to import Python code as a Nim library (without making Python calls). That way, you get the performance of Nim but the years of Python package development. "Transpiler" might be a better word?

I've never worked on anything so difficult so I'm really just spitballing. But... wouldn't it be cool? :)

My experience learning Nim is that it's more fiddly and less elegant than Python. The OOP syntax in particular could be streamlined a lot (the Nim by Example macro code demonstrates this). In addition to learning the basic syntax, there are a fair amount of features implemented as pragmas; there's some important things like {.base.} mixed into this sort of junk drawer of stuff. They often felt sort of like an afterthought to me.
I totally believe that. I guess what I really want is high-performance Python. On the other hand, Nim has some years to go before it's mature.
Nim is first and foremost a procedural language like Go, if you use it as a better Go you'll have a great time, if you try to make Nim more OOP you can use libraries like: https://github.com/bluenote10/oop_utils to make it easier.

Besides that Nim uses UFCS, you can mimic 90% of your OOP needs without using pragmas or methods or anything like that.

Most of the perceived "fiddly" parts of Nim are due to it being statically typed and compiled, in my experience.

Nim intentionally gives you very spartan objects. It is by no means an OOP-first or even an OOP-heavy language. The object type is little more than a storage container for named values, and should be treated as such. There is no magic like what you get with Python objects.

I've said it before, but the frequently thrown around, "it's just like Python but typed and compiled" has probably been a net negative for the language. It is syntatically similar, but once you get beyond those initial appearances it is a very, very different beast. So if you try to write Pythonesque Nim, you're not going to have a good time with it. It's no different than trying to write JavaScript like Python - they're just different languages that don't work the same way.

The macro chapter in Nim by Example is a good tutorial for writing a macro, but I don't know that it's a big improvement. For the most part, it just allows you to remove the `self: ObjectType` from methods that act on an object. I guess that's okay? But even Python makes you include the `self` in class methods.

It's already been done! https://github.com/Pebaz/nimporter
see my response to another comment. I think Nimporter is for bringing Nim code into Python, basically by making calls from one language to another. I'm talking about a Python to Nim transpiler, so that the functionality of Python is brought into the performance and under the control of Nim.

Tell me if I'm wrong.

I have enjoyed learning nim. I use exercism.io for this type of stuff, and the nim exercises are helpful! https://exercism.io/tracks/nim (I have no connection to exercism except as a user).
I've had a great experience learning Haskell with Exercism. Also unaffiliated.
It's been a great experience.

I have no idea how they are funded. I think employers would be willing to subscribe to uplift skills.

Last I worked with Nim, the most frustrating aspects of it were how it implemented tuples and multi-threading.

Tuples are really more akin to records, which name their fields. Because of that, I found many things quite difficult to do since I couldn't just return and work with a generic tuple type; read: (int, string) doesn't equal (int, string) because one is forced to name the elements and magically know the names of elements as well from returned tuples.

And multi-threading was just a mishmash of ideas, none seemed "blessed" or really 1.0 worthy (as of 1.0).

Those two issues aside, I really liked Nim when I tried it. Maybe the issues above aren't issues any more and I should take another look?

I believe the only time you have to name a tuple is when you define a tuple type. You can otherwise easily work with "anonymous" tuple fields.

https://play.nim-lang.org/#ix=2lK1

Tuples with anonymous fields are equivalent to those with named fields as long as the types and values match. Two tuples with differently named fields will not be equivalent even if their values are.

> magically know the names of elements as well from returned tuples.

This is not magic, is it? No more so than knowing the return type.

Anonymous tuples:

    echo (3,5,7)
    let (x, y) = ( "X", "Y" )
    echo x, y
    
    (3, 5, 7)
    XY
> Maybe the issues above aren't issues any more and I should take another look?

Yes and no. With destructors we are finally able to use multihreading without resorting to raw pointers. However its very wip. I am making a lib if you like to try it out https://github.com/planetis-m/sync and give some feedback.

If you begin using tuples with named fields, they will technically be of a different type than anon tuples. To keep it simple, just use anon tuples consistently everywhere.

I have some notes on tuples in Nim: https://scripter.co/notes/nim/#tuples

This is cool - I have been meaning to pick up Nim.
The second talk is "Making a Platformer in NICO with Nim". NICO [0] is the Nim version of the PICO-8 [1] "fantasy console" framework (potentially faster because it uses a compiled language instead of LUA the PICO-8 is based on). Its focus is making simple games, which is a great way to learn a new language (wink wink)!

[0]: https://github.com/ftsf/nico

[1]: https://www.lexaloffle.com/pico-8.php

Looking forward to it.
Asking here (@dang) but not really expecting an answer, would be nice to receive one though.

I suspect this thread (apart from a title edit which removed date of event, weird but ok) was flagged in some way: early on it started ranking very low given points and time of submission, currently it shows at the end of Nim searches in algolia (by default ranked by points).

I submitted being careful not to advertise the submission on Nim channel to limit artificial growth by fans and possibly avoid the flagging mechanisms (unsuccessfully). If it were to die off without interest, fine, somebody else would submit again or maybe people are just not interested. Instead it got points but went very early on away from top page. This means people were interested but the post had artificially limited visibility. It also means a repost is not encouraged.

I believe this is a legitimate submission advertising and stimulating discussion from larger HN community on a Nim (a language on which HN crowd has expressed interest) event that happens once a year (and there has been very limited submissions on Nim subjects in the last months).

Is there something else a normal user should know to avoid stuff being flagged while trying to genuinely share something without trying to trick HN in any way? Or is there something specific in this post that warranted flagging?

I am personally very fond on Nim on HN since this is how I discovered about Nim, but this stuff happening makes me less eager to submit stuff (Nim related or otherwise on this site).

It's true - I did not see this submission until I searched for it, after learning about the event from nim blog.
I'm looking forward to fidget2, immediate mode GUI. I think this could be a 'killer app' to bring small nim apps closer to a (non technical) end user.