[HN Gopher] NimConf 2020 - Live now until 20:45 UTC [video]
___________________________________________________________________
NimConf 2020 - Live now until 20:45 UTC [video]
Author : dom96
Score : 106 points
Date : 2020-06-20 17:05 UTC (5 hours ago)
(HTM) web link (conf.nim-lang.org)
(TXT) w3m dump (conf.nim-lang.org)
| mratsim wrote:
| And just when "Why Figma Wins" is #1 on HN, we have Figma
| integration in Nim via Fidget:
|
| - https://github.com/treeform/fidget
|
| - https://www.youtube.com/watch?v=IB8Yt2dqZbo&list=PLxLdEZg8DR...
|
| - https://news.ycombinator.com/item?id=23584954
|
| - https://kwokchain.com/2020/06/19/why-figma-wins/
| planetis wrote:
| I am hyped about the last talk "Introducing Enu, 3D live-coding
| in Nim", can't find any information about it online. Seems like a
| genuine reveal!
| planetis wrote:
| It was really cool actually, makes use of the nim godot
| bindings to create a sandbox game with the nim compiler running
| as a service and run NimScript (a subset of Nim, basically the
| ffi missing) inside a live 3D environment!
|
| Hope to see it expand further!
| deckarep wrote:
| Ok honest question I got really excited about Nim when I looked
| into it about 1 year ago.
|
| But I started looking at community projects on Github and found
| nothing except for Nimlang itself. This is not meant to be
| critical of what I think is an impressive language...just more of
| a question of where are Nim open source projects to be found?
| [deleted]
| mratsim wrote:
| I think the best is to go there:
|
| - https://nimble.directory/
|
| - https://github.com/Willyboar/awesome-nim
|
| - https://github.com/nim-lang/Nim/wiki/Curated-Packages
|
| What kind of packages are you looking for?
|
| This also logs what is requested and what is being worked on by
| the community.
|
| https://github.com/nim-lang/needed-libraries/issues
| planetis wrote:
| I'm pretty sure a year ago there were hundreds of projects
| using nim in github. Just use a custom query:
| https://github.com/search?l=Nim&q=nim&type=Repositories
| ggregoire wrote:
| I got really excited about Nim 1 or 2 weeks ago and what
| worried me a bit is the number of questions on StackOverflow.
| In the "new question" section, the most recent one was from
| hours ago, the second one from 1 or 2 days ago, the third one
| from the previous week. It could just mean that the language is
| straightforward and the documentation perfect. But it's still a
| good metric to measure the popularity of a language. Also, it
| makes me wonder, if I need to find "how to do X", would I find
| an existing answer? If I need to ask a question, would someone
| answer?
|
| (still excited about Nim anyway, seems like the perfect
| replacement for Python at my job)
| mratsim wrote:
| Personally I don't want to deal with StackOverflow elitism,
| "closed duplicate", "you don't know what you want to do, what
| you want to do is this", etc.
| planetis wrote:
| I was thinking the same, that StackOverflow has failed to
| attract nim users that are able to answer the questions,
| but afraid to sound too radical didn't express it. Myself
| included won't login to stackoverflow, since i can't __even
| __post an answer! Instead I help in the Nim forums.
| planetis wrote:
| People use irc #nim (bridged with gitter, discord, matrix) to
| post simple questions or hangout. For more complex matters
| forum.nim-lang.org is used. All are pretty active. Github
| issues included ;) which gives you a good idea of how many
| people are using Nim.
| sidkshatriya wrote:
| I am ... confused by Nim a bit. Nim on the surface has a dream
| set of features: python like syntax, strong types, compilation to
| C, good garbage collection, good metaprogramming...
|
| OTOH there seems to be a rapid accumulation of features. The
| language wants implement the "next shiny thing" (e.g. ownership
| ala rust) or at least that is how it appears to me from the
| outside.
|
| For those people using Nim -- how do you cope with the ever
| increasing scope of the language? Isn't there a possibility that
| things aren't going to be well baked/abandoned?
|
| I like the philosophy of evolving your language slowly and
| consolidating before adding newer and newer features.
|
| Do you think the pace of change in Nim is OK?
| kbd wrote:
| > OTOH there seems to be a rapid accumulation of features...
|
| I think you're stretching your narrative a bit. They're working
| on a new GC algorithm that (if you watch Rumpf's very
| interesting presentation[1] on it from today) is a significant
| performance improvement over their current GC.
|
| What features are you referring to regarding the "ever
| increasing scope of the language"?
|
| [1] https://www.youtube.com/watch?v=aUJcYTnPWCg
| pansa2 wrote:
| > > OTOH there seems to be a rapid accumulation of
| features...
|
| > I think you're stretching your narrative a bit. They're
| working on a new GC algorithm...
|
| The thing is, according to the documentation [0], Nim already
| has _six_ different garbage collectors.
|
| [0] https://nim-lang.org/docs/gc.html
| gmfawcett wrote:
| Many languages have pluggable GCs. Modern Java VMs have at
| least four (serial, parallel, CMS, G1). As long as they are
| interchangeable, it's not really a language design issue.
| kbd wrote:
| Do those represent a "rapid accumulation of features" that
| create an "ever-increasing scope of the language" as the OP
| claims, or are they just tuning options? Keep in mind the
| Nim team didn't create the Boehm or Go garbage collectors,
| and the new arc/orc are the same, with orc having a cycle
| detector. If anything, it's a testament to the design and
| stability of the language that the GC algorithm is
| swappable.
|
| Edit: for comparison, Java has four different GC algorithms
| to choose from[1] with a whole lot of options for
| tuning[2]:
|
| [1] https://www.baeldung.com/jvm-garbage-collectors
|
| [2]
| https://www.oracle.com/java/technologies/javase/vmoptions-
| js...
| sidkshatriya wrote:
| It is an impression (possibly an unfounded/unfair one) and
| the whole point of my question is for others to give me their
| opinions.
|
| Nim is certainly a feature-full language. Look at the left
| sidebar on https://nim-lang.org/docs/manual.html and you will
| see a lot of things listed! I wonder how many of those
| features work well with others, how many work partially and
| how many are somewhat abandoned.
|
| I'm looking to add Nim to my arsenal in the future. I'm
| positive on the language -- please don't misunderstand. I
| just wanted some opinions!
| planetis wrote:
| Everything that is new or was causing problems, moved under
| expiremental https://nim-
| lang.org/docs/manual_experimental.html These are the
| features you are describing, the ones needing more
| refinement.
| planetis wrote:
| stuff like concepts and code reordering are planned to
| eventually became stable. Nowadays everything is decided
| in the RFCs repo https://github.com/nim-lang/RFCs/issues
| before a PR hits the main repo.
| kbd wrote:
| > Look at the left sidebar...
|
| Look at the Go language manual for comparison[1]. Go is
| simple (some would argue, simplistic) and there's a lot
| there too. Programming languages are complex beasts.
| "Number of things in the sidebar of the manual" is a poor
| way to judge a programming language.
|
| > I like the philosophy of evolving your language slowly
| and consolidating before adding newer and newer features.
|
| The Nim book[2] came out in 2017 and the language has
| maintained compatibility with it through their 1.0 release.
| Nim seems pretty stable and "well baked" to me.
|
| One of the awesome things about Nim is that many features
| in the language can be implemented through macros. (AFAIK
| their async/await feature is implemented in Nim itself
| through macros.) So, I get the impression that Nim has a
| very solid core and builds things on top of that core. The
| fact that they can implement Rust-style move/borrow
| semantics without significantly changing the language is a
| really _good_ sign to me of the language 's power/design.
|
| Personally, I wish Nim was what we were all using instead
| of Go. Nim has all the strong typing features (like
| generics) that Go is still working on, while also having
| the equivalent of goroutines and channels (though I haven't
| played with those in Nim myself yet), pleasant syntax,
| strong metaprogramming features, very strong operator
| overloading that helps make it suited for domains like data
| science, can generate a static binary, and on and on. I'd
| strongly recommend everyone take a look :)
|
| I'm personally psyched that a repl (INim) is being worked
| on (and works now), because a good repl is something I
| really value in a language. There's a short presentation
| about it from today's conference as well[3]. The fact that
| the author keeps mentioning IPython gives me great hope for
| it.
|
| Edit: in fact, upon rewatching, that INim video would be a
| great sales pitch for the language for you, as the author
| details his trip through a bunch of different well-known
| languages and why Nim meets the sweet spot of everything
| he's looking for.
|
| [1] https://golang.org/ref/spec
|
| [2] https://www.manning.com/books/nim-in-action
|
| [3] https://youtu.be/Qa_9vut4TzQ
| arc776 wrote:
| > Nim on the surface has a dream set of features
|
| It's "too good to be true" is for real. The lack of friction
| when developing in Nim is what makes it so fun to code in
| (IMO). Metaprogramming in particular is just great in Nim and
| give you a lot of scope for doing things that would otherwise
| require new language features.
|
| > how do you cope with the ever increasing scope of the
| language?
|
| I've been using Nim pretty intensively for several years. From
| my perspective the language design has been very stable, even
| since before 1.0. I don't feel like the scope is expanding, and
| I don't think it really needs to either because the core
| language is built to be expanded with metaprogramming.
|
| None of my code breaks when updating versions (and I do a lot
| of heavy metaprogramming). Nothing seems to be abandoned, only
| refined, and there's a big effort towards backwards
| compatability so breaking changes are exceedingly rare. The
| only one I only remember was some time ago when seq (the
| variable sized list type a la C++ vector) became not nil, so I
| had to replace `if list != nil` with `if list.len > 0`, so a
| good change IMO.
|
| Most of the new things have been mechanical under the hood
| improvements and ownership is one of those. As I understand it,
| when using gc refs, you'll get free extra speed, better
| multithreadding, and better compile-time checks. No code needs
| to be changed, and when it's considered ready it will replace
| the previous GC, and you can add extra annotations for
| performance. It's refinement of the GC using ownership rules
| rather than a whole new set of rules for your program.
|
| The stdlib is very stable (at least from my experience), and
| again great effort is spent on backwards compatability. Stdlib
| focus is on being small and "essential", so there's a high bar
| for stuff getting into it, and probably why it's rare for
| anything to change API there.
|
| So personally the pace of change has been great - basically my
| code's just got free speed boosts when it's already fast enough
| :)
| codetrotter wrote:
| > Metaprogramming in particular is just great in Nim and give
| you a lot of scope for doing things that would otherwise
| require new language features.
|
| Metaprogramming is v alluring to me, but I've been wondering,
| people that write code super heavy on the metaprogramming,
| doesn't revisiting code and debugging become much more
| taxing?
| mratsim wrote:
| You have multiple ways to print the macros either as AST
| tree or even Nim code that can be copy-pasted to replace
| the macro:
|
| - dumpTree
|
| - lisprRepr
|
| - treeRepr
|
| - toStrLit
|
| This means that for debugging you can generate your code.
| Replace the macro by regular code temporarily and
| understand what's wrong and then fix the macros.
|
| I don't think I have a single library without macro but I
| try to keep them as reasonable as you can. But sometimes
| you need to give a Python feel (for example to provide a
| Numpy interface for a multidimensional array library) or
| you have to do code transformation (implementing async or
| multithreading as a library or autovectorizing high-
| performance computing code or implementing a GPU or Audio
| DSL) and there is no way around macros.
| planetis wrote:
| I have written a lot of metaprogramming myself, like 5/10
| of my repos are macro libraries. And I share your concern.
| Even the manual advices people to use the least "powerful"
| tool for the job. These are proc/func<template<macro.
|
| Macros are prefered for creating dsl like
| https://github.com/treeform/fidget or
| https://github.com/pragmagic/karax
|
| Otherwise the advice is to use them when they "pull their
| weight". The reason is they're a lot harder to write and
| even "design" them right (how they function, what code they
| write, etc) takes a lot of effort. And in most cases the
| simpler "tools" will fit your needs.
| Isomorpheus wrote:
| Why does Nim have "nil"?
| gmfawcett wrote:
| To represent a null pointer. Nim is a systems language (or
| at least can be used as one), and you need null/nil when
| working at that level.
|
| Even Haskell has null pointers, if you know where to look:
|
| https://hackage.haskell.org/package/base-4.14.0.0/docs/Fore
| i...
| anaphor wrote:
| A lot of the things you mention are pretty self-contained (you
| have to enable specific compiler flags), or they're implemented
| using the macro system or templates, and so in theory at least
| it's not bloating the compiler.
|
| Compared to something like Haskell (GHC), I think Nim is pretty
| lightweight and not too bloated.
| Willyboar wrote:
| Great talks so far. More coming...
| mratsim wrote:
| Even as a speaker, I'm surprised by how wide the use cases are
| being found for Nim:
|
| - DSL for real-time audio processing
|
| - Embedded programming with light switch
|
| - Creating GBA games!
|
| - Compiling to Android without Android Studio
|
| - Game dev in 30min
|
| - Promising REPL
| treeform wrote:
| The talk about the new garbage collector by the Nim's creator
| Andreas Rumpf, is a must watch:
| https://www.youtube.com/watch?v=aUJcYTnPWCg&list=PLxLdEZg8DR...
| Willyboar wrote:
| Personally I am waiting yours.
| ddlsmurf wrote:
| Very surprisingly wide range of subjects so far.
| Tiberium wrote:
| Talks are really nice, from embedded to web programming :) I'm
| watching till the very start and will probably watch till the
| very end. Nice to see so much people using Nim, it's certainly
| gaining popularity.
| impbox wrote:
| So many interesting talks, DSP, games, deep internals, embedded
| stuff. I did a quick talk on making games in it. Hopefully do a
| Nim Games Miniconf in the future seeing as there was a lot of
| interest.
| arc776 wrote:
| > Nim Games Miniconf
|
| I'd be interested in that! From my perspective Nim is ideal as
| an indie gamedev language since it's so fast to
| iterate/prototype with and get good performance, and has mega
| easy FFI to C/C++/JS to reuse anything in those ecosystems.
| dom96 wrote:
| At time of writing, we've had 9 talk premieres so far. You can
| watch them using this playlist[1] or watch the latest talk
| premiere live here[2].
|
| 1 -
| https://www.youtube.com/playlist?list=PLxLdEZg8DRwTIEzUpfaIc...
|
| 2 -
| https://www.youtube.com/watch?v=NOAI2wH9Cf0&list=PLxLdEZg8DR...
| elcritch wrote:
| Fun talks so far! The esp8266 one is a good example of running
| Nim on embedded targets. I've been happy with Nim in iterating on
| a hardware product with an esp32, despite being more of an
| embedded Linux guy. Hoping to expand it out once async is ARC
| ready. If others are interested in esp32 support, I was able to
| create an initial PR to target for the ESP-IDF, which is a fork
| of FreeRTOS and LwIP. It supports much of the basic POSIX api's,
| including `select` which is crucial for efficient servers.
| Freertos tasks and inter-task queues need Nim-ified, but I'm not
| an expert in FreeRTOS. :/ The Nim library code is surprisingly
| easy to hack on!
| GeorgeTirebiter wrote:
| I'd love to be able to easily write Nim with the esp32 as
| target; please, say more!
| elcritch wrote:
| Can do! I've got the basic OS target as `freertos`, so in
| theory any FreeRTOS device could work! FreeRTOS has a decent
| amount of POSIX API's but you'll want the `newlib` and/or
| `devfs` extra components for `select` (or using uart's with
| socket api's). The other big piece is `LwIP`, which has
| slightly different structs for IP addresses than standard
| *NIXes. Between FreeRTOS/LwIP you could cover a lot of
| embedded development and chips...
|
| Here's an example esp-idf project with a README describing
| the build and setup: https://github.com/elcritch/esp32_nim_ne
| t_example/blob/maste...
|
| Here's the Nim Forum thread, if you want to chime in and
| discuss/help out! https://forum.nim-lang.org/t/6345
|
| It's pretty rough, but it surprisingly stable. Nim wraps
| enough OS level concepts you could easily use Nim only
| wrappers without needing specific RTOS idea's except when you
| want. Wrapping vTask's with Nim's thread api would be
| awesome. I don't know FreeRTOS hardly at all though.
|
| When Nim's async works with ARC, I wonder if it'd be possible
| to port LwIP or rewrite it in Nim. LwIP seems somewhat buggy.
| :-)
| filleokus wrote:
| Is there any usage of Nim in "production"? How is the performance
| of the compiled code (and also the compiler)?
|
| (NB: I love a fun new language to play with as much as the next
| guy, just curious)
| mratsim wrote:
| As the resident Nim optimizer, if you can reach some
| performance in C, you can reach it in Nim.
|
| With some work you can even reach the performance of code which
| is 95% assembly and has been tuned for years (i.e. matrix
| multiplication):
|
| - Reaching C Quake code speed in Nim: https://forum.nim-
| lang.org/t/5124#32241
|
| - Reaching and going beyond OpenBLAS + OpenMP performance
| (almost pure Assembly):
| https://github.com/mratsim/weave/issues/68#issuecomment-5717...
|
| - Faster than C++ on Raytracing bench:
| https://github.com/mratsim/weave/tree/9f0c384f/demos/raytrac...
|
| - Faster than C++ on another Raytracing implementation:
| https://github.com/mratsim/trace-of-radiance/tree/v0.2.0
|
| Also Nim is easy to integrate with Intel VTune, Apple
| Instruments and perf. You have full control on the data layout,
| prefetching and the same control as C over cache and memory
| usage if you so wish it (i.e. the GC is not a hindrance, you
| have easy escape hatches).
| planetis wrote:
| Short answer yes. See: https://github.com/nim-
| lang/Nim/wiki/Companies-using-Nim
|
| People usually announce this stuff in the forum before this
| page is edited so you might want to search there as well.
| Isomorpheus wrote:
| 2/12 of those are dead links
___________________________________________________________________
(page generated 2020-06-20 23:00 UTC)