[HN Gopher] Nim 1.2
___________________________________________________________________
Nim 1.2
Author : narimiran
Score : 276 points
Date : 2020-04-03 16:09 UTC (6 hours ago)
(HTM) web link (nim-lang.org)
(TXT) w3m dump (nim-lang.org)
| war1025 wrote:
| Irrelevant, but I spent the entire day reading this headline as
| NVim, i.e. Neovim.
|
| These comments make a lot more sense now.
| intrepidhero wrote:
| I've been doing the nim track on exercism.io (no affiliation,
| just a user) for the last two weeks. The mentors on the track
| have been fantastic. If you're looking for a "solve a problem and
| get some external feedback" approach to learning the language
| it's pretty good.
| mikebelanger wrote:
| Ah neat - thanks for sharing. I'm gonna try that out.
| jjtheblunt wrote:
| "exercism.io" is such a great name!
| zelphirkalt wrote:
| Personally I stopped using exercism, when it started to require
| me to work for Google for free and would not let me log in, if
| I did not. It's not an ethical platform, unfortunately.
| duxup wrote:
| >it started to require me to work for Google for free
|
| How did that work?
| zelphirkalt wrote:
| Recaptcha and tracking.
| ampdepolymerase wrote:
| Would you pay monthly if they removed it?
| zelphirkalt wrote:
| Perhaps I would. I've supported many projects in the
| past, so I think, if it was really good and did not
| violate my privacy, there is a fair chance I would.
| mikebelanger wrote:
| What do you mean by 'work for Google for free?' I don't see
| that being required anywhere on the site.
| afiori wrote:
| Probably it is a reference to the reCapcha hell Google may
| drop you into if you are deemed "suspicious"
| dom96 wrote:
| By far my favourite feature of this release, dark mode in docs:
| https://nim-lang.org/docs/lib.html
| treeform wrote:
| I feel like dark mode is a sign that people care. I think it's
| a user feature that is easy to do, but not done often. Mostly
| done by people who care. It brings so much polish to the
| experience.
| leadingthenet wrote:
| It can be done poorly as well, like in Facebook / Google apps
| on Apple devices. They feel very unintegrated into the rest
| of the OS.
| rattray wrote:
| It's not necessarily _that_ easy to do, especially depending
| on how your CSS was implemented (eg; do you use variables for
| all your colors, and do they have a sane, consistent,
| reversible brightness scale?)
|
| However, I certainly agree with your "you do this because you
| _care_" sentiment.
|
| Source: implemented dark mode for an application where the
| "sane css colors using variables" property was true.
| mikebelanger wrote:
| Dude! I didn't even notice that. If you've ever had to look
| something up late at night - dark mode is a godsend.
| k__ wrote:
| Can't find anything dark mode related on that page
| kick wrote:
| There's a large button. It loads before the text does. When
| the text loads, you'll see in big letters, right next to the
| button, _Dark Mode_ , italicization and all. If you click on
| the button, suddenly you get a very blue-purple dark mode
| experience.
| k__ wrote:
| Doesn't work on mobile.
| sergiotapia wrote:
| If you would like to see some simple to parse Nim code and get a
| feel for what a "1 month of experience during weekends" Nim looks
| like, check out my project:
|
| https://github.com/sergiotapia/torrentinim
|
| Nim is a very interesting language, with a lot of upsides. It
| just needs that killer framework to get the ball rolling and
| allow devs to solve business needs quickly. Once that's done I
| think Nim will grow a lot! Tiny binaries, static binaries, fast,
| low memory usage, macros, compiles to C.
| icedchai wrote:
| I'm going to check it out this weekend... I'm very intrigued by
| what I see.
| MaxBarraclough wrote:
| It uses a rather primitive garbage-collector though, right?
| dom96 wrote:
| Primitive in what sense? Nim has a soft real-time garbage
| collector which doesn't sound primitive to me. Actually Nim
| supports more than one GC including boehm so you really have
| a lot of choice here.
| sp33der89 wrote:
| It really doesn't! It's GC story is pretty great, because you
| can choose out of several GC's, one of them being good for
| real-time systems: https://nim-lang.org/docs/gc.html
|
| Recent versions also use this fancy thing:
| http://www.gii.upv.es/tlsf/
| MaxBarraclough wrote:
| 'TLSF' sounds very interesting, I'll have to keep an eye on
| that project. What are the reference-counting options for
| though, given the absence of weak references? Under what
| circumstances is it acceptable to permit memory-leaks in
| case of cycles? Short-lived processes (i.e. arena-based
| memory management)?
|
| When I say 'primitive GC', I mean Boehm, which is obviously
| decades behind the state of the art, but easy to get off
| the ground. GNU Guile uses it, for instance. Serious
| garbage collectors are tremendously complex, and are
| something less popular languages unfortunately tend to
| lack. I believe even D is miles behind Java.
|
| Can't say I know much about Go's GC.
|
| _Edit_ Oops I misread, TLSF isn 't a GC, it's an
| allocator. It sounds then like Nim doesn't have a proper
| real-time solution, does it? _useRealtimeGC_ is actually a
| leaky reference-counting system?
| rayman22201 wrote:
| As others have said, Nim has plugabble garbage collectors,
| some are quite advanced.
|
| In addition there is active work on a swift like reference
| counting, lifetime based memory management option. This will
| be suitable for hard real-time use cases.
| jjtheblunt wrote:
| Isn't it announced here in this release : --gc:arc and
| linked explanatory video
| https://www.youtube.com/watch?v=yA32Wxl59wo ?
| rayman22201 wrote:
| yup! That is the one :-)
| treeform wrote:
| Neat project!
| jakear wrote:
| > If you were relying on some edge case and/or buggy behaviour
| which is now fixed, try if --useVersion:1.0 gives you back the
| results you expect to see. If that doesn't work and you need the
| old behaviour, please open an issue in our bug tracker and we
| will try to make it work in future bugfix releases
|
| So useVersion doesn't simply checkout the old codebase, but they
| still promise to maintain all prior version's bugs? Seems like a
| losing battle to me... why not just tell people relying on
| version 1.0 behaviour to use version 1.0 and create tooling to
| make sure switching between versions is easy (a. la. nvm)?
| _0ffh wrote:
| My impression was that using "choosenim" switching between
| versions is easy already, but I might be missing something.
| rayman22201 wrote:
| choosenim is still supported :-)
|
| The idea is more like the gcc -std flag (gcc -std=gnu++11 for
| example). to emulate certain versions to ease upgrading.
| jakear wrote:
| Do you think the gcc -std flag would exist if every
| distribution of gcc included a command to easily download
| alternate versions and swap them out depending on project
| configuration? -std seems more like a bandaid around a
| difficult install/config than a feature, in my opinion.
|
| Obviously nim is free to make implement whatever options
| they want, but it seems to me like every second spent
| triaging/fixing/etc bugs about not properly maintaining
| broken things (not to mention the end user time spent
| experiencing them and debugging them!) is time that could
| be better spent improving the language.
| yellowapple wrote:
| A newer GCC will likely have better optimizations, better
| safety checks, or what have you that would benefit old
| codebases using older versions of C's syntax. Similar
| deal with a newer Clang/LLVM, for that matter.
|
| That is, if we had a GCC version manager that worked the
| same way things like choosenim or rustup or pyenv or rvm
| or what have you work, I can guarantee you GCC will ship
| with an -std flag, because you can bet someone needs to
| compile a C89 codebase and wants the latest and greatest
| compiler smarts to do it. Same deal for Clang, or Visual
| Studio, or `zig cc`, or whatever.
|
| Great example of this (that I just had to deal with this
| week, lol) is Wine, which mandates C89-compliant code,
| and yet absolutely benefits from any compiler
| optimization improvements introduced with newer versions
| of GCC.
| rayman22201 wrote:
| Depends on your organization more than tooling. Even if
| you have the tool, your orgs security policy may not
| allow using it.
|
| You may not have an environment that allows switching
| compiler versions for other reasons.
|
| Even Rust has a similar concept that allows gating of
| features like this. They call it "editions".
| tomsmeding wrote:
| Yes, the -std flag would definitely still exist: the
| thing being changed by that flag is a lot of stuff in the
| parser, some stuff in the standard library, and some
| semantics bits further towards the backend, but at some
| point the versions converge and go through the same
| optimisation pipeline. A pipeline that definitely has
| seen improvements in more recent versions, so it's
| totally worth it to use a new compiler with an old
| language standard on old code: it might very well produce
| a faster executable. Just using an older compiler would
| also revert back to the old performance.
|
| Additionally, a C/C++ compiler in an older standard mode
| would disable certain features, of course, but not
| completely: it's still able to give diagnistics in the
| vein of "this thing isn't valid with the current version
| setting, but it _would_ be valid in C++17 ", for example.
| That's useful to a programmer.
| marvy wrote:
| Also useful in the other direction: your code works now,
| but in C++17 that's a keyword so you'll have to rename
| it.
| predators372 wrote:
| Oooo, wow collect looks so much cleaner. I can't wait to get home
| and play with it!
| adwww wrote:
| > I can't wait to get home and play with it
|
| A. Where are you that you are not already at home??
|
| And B. I wonder how many people are using nim at work, and what
| sort of workplaces that might be?
| ilaksh wrote:
| B.
|
| https://github.com/nim-lang/Nim/wiki/Companies-using-Nim
| totalperspectiv wrote:
| Very excited to see gc:arc make it into stable.
| sergiotapia wrote:
| For the layman Nim dev, would you say "always use gc:arc" is a
| safe bet?
| narimiran wrote:
| > would you say "always use gc:arc" is a safe bet?
|
| This is the first release to offer `--gc:arc` so there are
| still some rough edges, but I would follow @treeform's and
| @rayman22201's advice from sibling comments: give it a try,
| it might work for you without any problems, and if not -
| report it.
|
| The long-term plan is to make it the default.
| rayman22201 wrote:
| I would say gc:arc beta quality. Very usable for many
| programs, but needs more battle hardening. Please try it and
| send bug reports if you find them! That's how we improve!
| dom96 wrote:
| Definitely not. --gc:arc is still experimental.
| treeform wrote:
| I would still try out --gc:arc on your programs. For mine
| it just runs without issue. But keep in mind if you do have
| issues you might have to create a bug report and wait for a
| fix. You would not reply on --gc:arc working. But it's fun
| to play around with. It's real now.
| [deleted]
| iffycan wrote:
| Among other great additions, I like the addition of
| compilesettings [1], which will give programs more visibility
| into how they were compiled.
|
| [1] https://nim-lang.org/docs/compilesettings.html
| hartator wrote:
| Very bullish on Nim. It's Python with C-level performance.
| iimblack wrote:
| Dup is very interesting to me. Does that mean that in Nim all
| functions will be impure by default, and that it's considered
| idiomatic to modify the input? I guess it's nice that they're
| trying to make behavior consistent. It just seems like the
| opposite of the recent directions I've seen other languages take.
| jrhurst wrote:
| I haven't played with nim for a few months, but only parameters
| with var will get mutated. I suspect you want to use someone
| else's cursed function and don't want to poison your blessed
| code
| iimblack wrote:
| I see. I know nothing about Nim but I do see in their example
| they used var when declaring the function. This way seems
| like it's hidden to the consumer of the function but
| hopefully editor tooling helps with this.
| juki wrote:
| You have to declare the variable as `var` as well, eg.
| var arr1 = [4, 2, 3, 6] sort arr1 #
| Doesn't work let arr2 = [4, 2, 3, 6] sort
| arr2
|
| You'll get a warning about the latter from the compiler
| (and nimsuggest for editors).
| treeform wrote:
| Mutating in place is often times faster and is more
| straightforward.
|
| I do feel Nim embraces mutation more than other recent
| languages.
| eindiran wrote:
| Yeah, the 'discard' keyword is a pretty cool way to note that
| you're using a procedure only for its side effects.
| iimblack wrote:
| I'm not arguing either way, just noting that it's counter to
| what I've seen recently in other languages.
| alberth wrote:
| I really with more people used NIM for web development. It really
| seems like the best of all worlds (e.g. perf, developer
| ergonomics, productivity, etc).
| nathancahill wrote:
| I've been building and deploying Nim web apps for clients over
| the past couple years. The language is just getting better and
| better and the library environment is filling out nicely too
| (not to subtract from the stdlib, it's very complete too). It's
| been a really great experience.
|
| Also: available to hire if anyone is looking to work with Nim.
| alberth wrote:
| Are you using Jester or another framework?
| nathancahill wrote:
| Largely building microservices with the stdlib. Generating
| html frontends with htmlgen. Using karax for more dynamic
| frontends.
| nepeckman wrote:
| I'm planning on trying out the new Prologue framework. Seems
| promising from the readme! https://github.com/planety/prologue
| camccar wrote:
| I'll never understand what people see in prologue
| rattray wrote:
| What do you recommend instead for web development with Nim?
| pjmlp wrote:
| As fan of Wirthian languages and GC enabled systems languages
| it looks nice to me, but it is still miles away of the tooling
| experience available to Java and .NET developers, and yes, you
| can make use of AOT or JIT caches with them.
|
| But the more the merrier, so I look forward to its bright
| future.
| The_rationalist wrote:
| What advantage does it bring that Kotlin hasn't?
| atemerev wrote:
| No JVM.
| winter_blue wrote:
| Look up _Kotlin Native_. It doesn 't use a JVM (and
| compiles to native via LLVM).
|
| There's also Kotlin JS, which targets the JS ecosystem, and
| comes with tools that let you import TypeScript type
| definitions into Kotlin, so you can easily interact with
| third-party JS modules.
|
| A pure Kotlin library could easily be used on JS, JVM, and
| native/LLVM seamlessly. Which is pretty impressive. All
| your non-platform-dependent logic could be placed in a
| decoupled shared pure Kotlin library. Which avoid code
| duplication that is so common when you need web + iOS +
| Android client apps. (And the Intel Multi-OS Engine could
| be used to write your iOS app in Kotlin.)
| atemerev wrote:
| I have nothing against Kotlin, it is a fine language, a
| pleasure to work with. Nim, however, has different
| priorities (utmost simplicity, native compilation, near-C
| performance, opt-out automatic memory management,
| excellent FFI capabilities, best in class macros).
| felipeccastro wrote:
| Having only played a little with both (Kotlin and Nim), I
| enjoy Kotlin syntax but overall it feels as heavy as Java
| (need to setup an IDE for even getting started, choose and
| understand some package manager, slow compile times, etc.)
|
| Nim feels as lightweight as Go, but with great syntax. The
| main thing holding me back now is the lack of libraries, but
| it's definitely on my radar.
| vips7L wrote:
| Isn't an ide just a choice? You don't have to use intellij.
| There are vscode plugins.
|
| Don't you also need to understand the go package manager or
| Nim's? I don't see how this is different than learning
| Gradle.
| kitotik wrote:
| Better than having to choose an IDE, is to not have to
| choose an IDE.
|
| It's pretty liberating to put some text in a single file,
| pass that file to a compiler, and have a single
| executable binary.
|
| A devolved workflow I know.
| 7thaccount wrote:
| Devolved, but still superior in some ways.
| polotics wrote:
| Instant startup time
| The_rationalist wrote:
| Kotlin support AOT so moot point
| vips7L wrote:
| Not really. Kotlin/native is still super experimental and
| graal isn't exactly that easy either.
| The_rationalist wrote:
| And somehow Nim has more support? This is a double
| standard non-sens. Btw you can address the startup time
| (which is reasonable btw, and x2 faster since kotlin
| 1.4-m1) without aot with tools like
| http://martiansoftware.com/nailgun/
| vips7L wrote:
| I'm just saying that currently it's not trivial to
| compile a kotlin/jvm project to native. Once you start
| using dependencies things start to get really hairy. It's
| not as easy as `go build`.
|
| I myself am hoping that either kotlin or Scala can finish
| their native compilers or Graal can make compiling jvm
| bytecode trivial.
| andybak wrote:
| How would the dynamism and expressivity of something like
| Django port to Nim? I love the whole declarative paradigm of
| the Django forms and models API. Is Nim good at this kind of
| DSL-ish plasticity?
| alehander42 wrote:
| i'd say so: i think many rails/django concepts are translate-
| able to metaprogramming in nim, not always with the same
| idioms, but usually there is a way to do it, and you can
| typecheck some things
| PMunch wrote:
| Extremely well I'd say. Nim has a very powerful macro system,
| and DSLs are very common across various modules. Haven't used
| Django myself, but something like Jester
| (https://github.com/dom96/jester) or Karax
| (https://github.com/pragmagic/karax) is a good place to start
| if you want to do web development in Nim.
| treeform wrote:
| I feel DSL-ish ways of Nim are so much more advanced then
| python.
|
| I have written UI DSLs in Nim, as well as SQL DSLs. Only
| LISPy languages come close to the level of DSL you can do.
| TylerE wrote:
| Poorly. Nim is not an object-oriented language.
|
| You could certainly write an expressive web framework in nim,
| but a django/rails sort of paradigm is not the way.
| wmock wrote:
| As someone who's heard of Nim, can someone who's used it tell me
| a little bit more about its benefits and how it compares to other
| common languages like JavaScript, Python, etc?
| rayman22201 wrote:
| The major features are: Python like syntax, Lisp like macro
| system, potential for C like performance (YMMV of course).
|
| This is my person opinion here: Nim is part of the "new
| generation of system programming languages" from the last
| decade or so. Some other examples in this category include Zig,
| D lang, Go lang, Swift, Rust, etc...
|
| The whole idea is to provide "modern high level" language
| features and ergonomics while still producing efficient low
| level code.
|
| For Pythonistas, The familiar syntax is attractive to Python
| programmers looking for a more performant language (data
| science is a prime example.)
|
| Nim is also attractive to lispers looking to move to a more
| traditional Algol or C like language while still keeping much
| of power and flexibility that they are used to from macros.
| rattray wrote:
| Does Nim have an ORM or querybuilder as good as SQLAlchemy yet?
| nepeckman wrote:
| The collect macro is awesome, and way more idiomatic Nim than
| list comprehensions. Nim continues to hit the sweet spot between
| performance and developer ergonomics.
___________________________________________________________________
(page generated 2020-04-03 23:00 UTC)