[HN Gopher] NimConf 2021
___________________________________________________________________
NimConf 2021
Author : pietroppeter
Score : 106 points
Date : 2021-06-23 14:15 UTC (8 hours ago)
(HTM) web link (conf.nim-lang.org)
(TXT) w3m dump (conf.nim-lang.org)
| massung wrote:
| 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?
| planetis wrote:
| > 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.
| irq-1 wrote:
| Anonymous tuples: echo (3,5,7) let
| (x, y) = ( "X", "Y" ) echo x, y (3, 5,
| 7) XY
| pietroppeter wrote:
| You can return a generic tuple and you do not need to know the
| names when using a returned tuple: https://play.nim-
| lang.org/#ix=3qTu
| matthiaswh wrote:
| 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.
| uryga wrote:
| > https://play.nim-lang.org/#ix=2lK1
|
| which part of the link shows using tuples? i can't really see
| anything tuple-like really
| komuher wrote:
| Man still waiting for nim to get more traction such a wonderful
| language
| geodel wrote:
| Yes, seems others are also waiting for Nim to get more traction
| before they start using it.
| bckr wrote:
| 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.
| jyapayne wrote:
| It's already been done! https://github.com/Pebaz/nimporter
| crispyalmond wrote:
| Something like this? https://github.com/yglukhov/nimpy
| bckr wrote:
| 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? :)
| crispyalmond wrote:
| Ah yes, I misread your intent. That would be very nice to
| have. There is this breakdown of features[0] present in
| Nim compared to Python which might be helpful when doing
| this.
|
| [0] https://github.com/nim-lang/Nim/wiki/Nim-for-Python-
| Programm...
| jamesgeck0 wrote:
| 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.
| atom_arranger wrote:
| I like Nim's "missing postfix syntax". You can get the
| feel of OOP when calling procedures without really using
| OOP.
|
| https://nim-lang.org/docs/manual.html#procedures-method-
| call...
| matthiaswh wrote:
| 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.
| sp33der89 wrote:
| 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.
| bckr wrote:
| 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.
| 0-_-0 wrote:
| 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
| pietroppeter wrote:
| 13 talks for about 7h30' of content (from 11 UTC to 20 UTC with
| 1h30' of breaks). very much looking forward to it!
| pjmlp wrote:
| Looking forward to it.
| whalesalad wrote:
| This is cool - I have been meaning to pick up Nim.
| tomrod wrote:
| 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).
| samhh wrote:
| I've had a great experience learning Haskell with Exercism.
| Also unaffiliated.
| tomrod wrote:
| 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.
| treeform wrote:
| That's a lot more talks this year. Can't wait!
| pietroppeter wrote:
| 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/
___________________________________________________________________
(page generated 2021-06-23 23:03 UTC)