6 ms·

Nim 1.4

278 points by narimiran 6y ago

Tiberium 6y ago
Great stuff! GC ORC is an amazing improvement over existing memory management models :) I hope to see more Nim projects adopt it!
Boxxed 6y ago
There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the user -- it's tough to prove a negative like this.
- nicoburns 6y ago
  Looks like it'a still an opt-in experimental option at this point rather than the default. Preaumably they'll fix these caveats before recommending it for general use.
  - ziotom78 6y ago
    If I recall correctly, I read that the intention is to eventually make ORC the default, not ARC. (ORC is like ARC, but it avoids problems with cycles.)
    - Tiberium 6y ago
      Yes, you're totally right! That's the exact reason ORC should eventually become the new default GC.
- Tiberium 6y ago
  Sorry if you got misled by the article - ORC is what you should use if your program has cycles. ORC deals with async just fine.
  - MaxBarraclough 6y ago
    Does ORC stand for something?
    - cb321 6y ago
      I could be wrong, but I believe the acronyms are: ARC = Automatic Reference Counting (NOTE: not Atomic) ORC = Optimized Reference Counting The loopy/circular character of the letter 'O' may be a secondary mnemonic since it collects cycles.
      - cb321 6y ago
        I meant "character" as in "nature" not as in the prog.lang "character type"..I just realized that in context this might be confusing. Lol.
- djur 6y ago
  I think you missed this detail: > ARC was first shipped with Nim 1.2... [ORC is] our main new feature for this release Seems like they should phrase it like "use ORC unless you know you don't have cycles" rather than "use ORC if you're not sure you have cycles", but that's a reasonable responsibility to take on if you're choosing to use an alternative garbage collector.
  - mumblemumble 6y ago
    I'd prefer no phrasing at all. Just pick one that will work well in all cases, and don't give me any footguns.
    - adamc 6y ago
      Yes. Or at least put them in the appendix.
    - judofyr 6y ago
      To clarify: By default Nim will still use the GC which doesn't have any "footguns". ARC and ORC are new features which have different trade-offs, and some limitations. You opt-in to using them if you're interested.
      - deleted 6y ago
        [deleted]
    - gameswithgo 6y ago
      A way of dealing with memory that works well in all cases! That would be great.
- leorize 6y ago
  I believe the phrasing might not be clear to everyone, so here's a reduced version: * Nim's current async implementation creates a lot of cycles in the graph, so ARC can't collect them. * ORC is then developed as ARC + cycle collector to solve this issue, and it has been a success. * This 1.4 release introduces ORC to everyone so that we can have mass testing for this new GC and eventually move torwards ORC as the default GC. TL;DR: ORC works with everything† and will be the new default GC in the future. Your old Nim code will continue to work, and will just get faster‡. † We are not sure that it's bug-free yet, which is why it's not the default for this release. ‡ Most of the time ORC speeds things up, but there are edge cases where it might slow things down. You're encouraged to test your code with --gc:orc against our default GC and report performance regressions.
  - treeform 6y ago
    Your explanation is very clear. Thanks.
- wffurr 6y ago
  Is there an msan/asan equivalent that can detect leaks in your test suite?
  - leorize 6y ago
    Yes, we use valgrind for the compiler and stdlib test suite. The testament tool supports this, however it's not in widespread use outside of the compiler and stdlib, so documentation is rather sparse. Since Nim uses the C compiler to generate executables, you should be able to use `--passC:-fsanitize=memory --passL:-fsanitize=memory` to enable msan. For maximum effectiveness the flags `-d:useMalloc --gc:orc` should also be used. `-d:useMalloc` tells Nim to allocate memory using libc's malloc instead of our TSLF implementation. This should provide adequate compatibility for use with external inspection tools. We do `--gc:orc` because this is one of the only GCs that support -d:useMalloc (the other being arc).
    - scns 6y ago
      Please put this in the docs, if it is not there already
- karmakaze 6y ago
  I'm not familiar with Nim. Does it also support weak references? A significant portion of the problems with cycles in ARC are parent references.
  - planetis 6y ago
    Weak references are possible with the .cursor pragma applied on local variables and object fields. This release introduces cursor inference too, enabled by default with --gc:arc|orc, but only for local variables.
- mcintyre1994 6y ago
  At an ELI5 level, does anyone know why Swift can have ARC and async but Nim's ARC doesn't work with async? Is it just implementation details of Nim's async specifically instead of anything more fundamental to ARC? Just asking out of curiosity.
  - treeform 6y ago
    Yes. There is nothing fundamental to nim's ARC working with nim's async. There are attempts on make nim's async cycle free.
  - dom96 6y ago
    Note that what we're referring to as "async" for Nim is actually "async await". AFAIK Swift doesn't support that, does it?
  - darthrupert 6y ago
    Swift doesn't claim hard realtime capabilities like Nim's ARC does.
PMunch 6y ago
Great to see that Nim grows ever faster and more stable. Been a fan of the language for quite a while now and while I miss the old days of new and exiting changes with every release it's much easier to target Nim now that it has become this stable. Great work all around!
sp33der89 6y ago
Congratulations! And thanks for all the progress on ARC/ORC. But I must say, even though I'm excited about ARC/ORC, I'm even more happy to see the nice list of bugfixes and quality standard library additions!!
untog 6y ago
I played around with Nim a little and was amazed at how small the executables were: 10s of KB for something simple. Even Rust spits out 100s of KB, or even >1MB by default. In the end I still went with Rust, simply because it's more popular, but my initial impression was that Nim is a really fun language to work in, and much much easier to pick up than Rust.
- anta40 6y ago
  "and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.
  - untog 6y ago
    Yes, I think for me Nim could be a great answer for when I want to throw together a quick script. Right now I'll often use JS/Node for that and I'm not going to switch to Rust because it'll take a lot longer to get a rough and ready script going.
    - cb321 6y ago
      Nim is indeed a great answer for this. Should you want to give that script a nice, traditional CLI then you can do so with very low effort using https://github.com/c-blake/cligen https://github.com/c-blake/cligen Should you want "script like" edit-test development cycle ergonomics you can use the TinyCC/tcc backend for compiles in ~200..300 milliseconds. Once it's how you like it you can compile with gcc & -d:danger for max performance in deployment.
    - treeform 6y ago
      I have so many little nim scripts all over the place.
      - cb321 6y ago
        Unmentioned so far is the NimScript mode `nim e`..For a portable sort of alternative to Bash scripting ("sort of" from the presently much longer start-up time...).
pshirshov 6y ago
> The reason is that only after the new(result, finalizer) call the compiler knows that it needs to generate a custom destructor for the CustomObject type, but when it compiled tricky the default destructor was used. I'm wondering why people underestimate graphs that much. It's lot easier to explicitly represent dependencies between your definitions as a graph and not just avoid such issues but also get rid of unnecessary passes. I did that in my compiler and it works great.
nepeckman 6y ago
Since Nim has hit the front page twice in the past day, let me just say: if you're at all curious about the language, try it out over the weekend. Nim isnt quite as simple as Zig (to compare to another compiled language with a smaller ecosystem), but the more advanced features stay out of the way until you need them. If you've worked with any static language, you probably know 80%-90% of what you need to write productive Nim code. The dev team has worked hard over the past year to improve documentation, and the website links to some great tutorials.
- ziml77 6y ago
  Maybe I'll give it another try. I might have gone too deep into the docs, but Nim seemed to get very complicated with all the {.annotation.} to remember
  - nepeckman 6y ago
    If you're just starting with the language, my recommendation would be to ignore the pragmas. None of them are necessary for basic functionality, and a lot of them are only useful for very specific optimizations. The most useful pragmas in my experience are the pragmas for FFI, async, and memory/side effect tracking.
- neverartful 6y ago
  "Nim isn't quite as simple as Zig" My experience is complete opposite. I find Nim to be very simple and Zig to be not simple. What's the problem with Zig? I find the documentation to be chaotic. I believe that this is largely due to the rapid pace of changes (including changes that break earlier code).
  - elcritch 6y ago
    That makes sense. I haven't tried Zig, but it's still pretty early in its history. That means a lot of syntax change, similar to Rust which is settling down, or Swift. Nim's been around long enough that it's settled it's syntax a while back. Before I started really digging into Nim, it seemed like it was always changing the language a lot (feature churn). However, most of those changes have been compiler support for different GC's and other backend languages, which don't generally break existing code. I've tried Nim code from 4 years ago, and its almost the exact same syntax. Sometimes stdlib names changed. I think syntax change is the part that gets people a lot in terms of daily "complexity". It actually reminds me of the feel of Python 2, before Python 3 that seems to add new syntax & language complexity every release. Well Python 2 but with a more solid language theory (e.g. everything can be a statement, etc). The trickiest part of day to day Nim are: var vs no-var, object vs ref object, and some iterator annoyances.
yitchelle 6y ago
I am intrigued by Nim. Anyone know of the motivation for Nim? I was not able to find that out in their website.
- pietroppeter 6y ago
  From this nice interview with Araq (language creator): http://157.245.209.254/andreas-rumpf-on-creating-and-growing-nim/ http://157.245.209.254/andreas-rumpf-on-creating-and-growing... > I started the Nim project after an unsuccessful search for a good systems programming language. Back then (2006) there were essentially two lines of systems programming languages: > The C (C, C++, Objective C) family of languages. > The Pascal (Pascal, Modula 2, Modula 3, Ada, Oberon) family of languages. > The C-family of languages has quirky syntax, grossly unsafe semantics and slow compilers but is overall quite flexible to use. This is mostly thanks to its meta-programming features like the preprocessor and, in C++'s case, to templates. > The Pascal family of languages has an unpleasant, overly verbose syntax but fast compilers. It also has stronger type systems and extensive runtime checks make it far safer to use. However, it lacks most of the metaprogramming capabilities that I wanted to see in a language. > For some reason, neither family looked at Lisp to take inspiration from its macro system, which is a very nice fit for systems programming as a macro system pushes complexity from runtime to compile-time. > And neither family looked much at the upcoming scripting languages like Python or Ruby which focussed on usability and making programmers more productive. Back then these attributes were ascribed to their usage of dynamic typing, but if you looked closely, most of their nice attributes were independent of dynamic typing. > So that's why I had to create Nim; there was a hole in the programming language landscape for a systems programming language that took Ada's strong type system and safety aspects, Lisp's metaprogramming system so that the Nim programmer can operate on the level of abstraction that suits the problem domain and a language that uses Python's readable but concise syntax.
  - pietroppeter 6y ago
    Also relevant this other interview (video), a bit more recent: https://www.youtube.com/watch?v=-9SGIB946lw https://www.youtube.com/watch?v=-9SGIB946lw
euan_torano 6y ago
Awesome to see 1.4 finally released, and to have a version that should hopefully build cleanly out of the box on OpenBSD and FreeBSD and mostly "just work"[1]. Next target is NetBSD[2] then DragonFly! 1. https://github.com/nim-lang/Nim/issues/14035 https://github.com/nim-lang/Nim/issues/14035 2. https://forum.nim-lang.org/t/6610 https://forum.nim-lang.org/t/6610
DannyB2 6y ago
An economic argument for GC instead of ARC/ORC. Commercial web application in Java. Java GC is concurrent, on other cpu cores than the cores processing customer requests. Modern GCs such as Red Hat's Shenandoah or Oracle's ZGC have 1 ms or lower pause times on heap sizes of terabytes (TB). Java 15 increased max heap size from 4 TB to 16 TB of memory. Now the argument. A thread running on a cpu core which processes an incoming request has to earn enough to pay the economic dollar cost of the other threads that do GC on other cpu cores. But that thread processing the client request spends ZERO cpu cycles on memory management. No reference counting. Malloc is extremely fast as long as memory is available. (GC on other cores ensures this.) During or even after that thread has serviced a client request, GC will (later) "dispose" of the garbage that was allocated when servicing the client request. Obviously, just from Java continuously occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right. That said, I find Nim very interesting, and this is not a rant about Nim. I am skeptical of an alternative to real GC until it is proven to work, in a heavily multi threaded environment. And there is that economic argument of servicing client requests with no cpu cycles spent on memory management -- until AFTER the client request was fully serviced.
- judofyr 6y ago
  > Obviously, just from Java occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right. I'm not sure if this argument holds. Java's high memory usage is frequently cited as a downside of Java. GUI applications written in Java have a reputation of being memory-hungry, and I know plenty of people struggling with memory usage of server application (e.g. ElasticSearch). You will also find C/C++ on the same popularity lists… That said, I do agree that a tracing GC is a better solution (for most programs) than reference counting these days. The improvements in the pause times by the Java GCs are really impressive, and the throughput is great. One example would be ESBuild: The author created a prototype in both Rust and Go, and found that the Go version was faster allegedly because Rust ended up spending a lot of time deallocating [source: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284].
  - 6y ago
xyproto 6y ago
I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.
- speps 6y ago
  Can you output WebAssembly/Emscripten project that uses SDL2?
  - nikki93 6y ago
    This seems quite possible from everything I've explored, and also is something I want to try soon. It's also interesting to use Nim through JS for a scripting layer for an application written in Nim; where they both communicate through shared data structures or something. Here's a repo I found: https://github.com/Jipok/Nim-SDL2-and-Emscripten https://github.com/Jipok/Nim-SDL2-and-Emscripten
  - treeform 6y ago
    Yes. People have done this.
- sergiotapia 6y ago
  Nim is my mistress. I work with Elixir and Javascript, but something about Nim is so pure and exact and precise. I love it. I'm hoping someone builds a great web framework with it, and a library like Ecto for better postgresql access. This language great potential to build faster software.
thelazydogsback 6y ago
NIM and Red (also on HN today) seem both seem to have an interesting and intersecting feature set. Anybody here used or heavily evaluated both that can comment?
- cb321 6y ago
  Rebol/Red is more like Python/Cython - able to be fast but falling back to an interpreter for dynamic things. As such there are probably more "performance footguns" (though any such thing is ultimately subjective based on programmer awareness). Nim feels more like what C++ (or Python) should always have been. Not sure if this helps. It's kind of a "big" question.
  - 9214 6y ago
    No, it's actually the other way around: Red and Rebol are interpreted by default, and Red has a bootstrapping AOT compiler capable of bridging it with Red/System (a C-like sub-language), which it turn targets machine code. However, since Red is highly dynamic, compiler cannot preserve semantics across the whole language, so it keeps some parts for the interpreter to process at run-time. And sometimes that's the only option, since code can be generated on-the-fly or pulled over the network: Red is homoiconic and has quite powerful meta-programming facilities on top of that.
- 9214 6y ago
  Nim and Red are quite different languages, both in terms of semantics and in terms of project's goals and scope. Perhaps you should elaborate on an intersection that you see between the two. I can speak only for Red: it takes its heritage in Lisp, Forth and Logo, has an embeded cross-platform GUI engine with a dedicated DSL for UI building, C-like sub-language for system level programming, OMeta-like PEG parser, and unique type system with literal forms for things like currencies, URLs, e-mail and dates with hashtags; all of that fitting in one-megabyte binary and valuing human-centered design above all.
nivviv 6y ago
A small perspective insight from a game developer: We (Beamdog) are using nim in production for Neverwinter Nights: Enhanced Edition, for the serverside parts of running the multiplayer infra. nim is uniquely good in providing an immense amount of value for very little effort. It gets _out of my way_ and makes it very easy to write a lot of code that mostly works really well, without having given me any serious traps and pits to fall into. No memleaks, no spurious crashes, no side-effect oopses, anything like that. It's C/++ interop has been a huge enabler for feature growth as well, as we can partly link in game code and it works fine. For example, our platform integrates seamlessly with native/openssl/dtls for game console connectivity. And it all works, and does so with good performance. It is all now a set of quite a few moving components (a message bus, various network terminators, TURN relays, state management, logging and metrics, a simple json api consumed both by game clients and web (https://nwn.beamdog.net https://nwn.beamdog.net), ...). We're still lagging behind and are on 1.0.8, but that is totally fine. It's tested and works, and there's no real incentive to move to 1.2 or 1.4 - yet! Usage for our game has expanded to provide a few open source supporting utilities (https://github.com/Beamdog/nwsync https://github.com/Beamdog/nwsync) and libraries (https://github.com/niv/neverwinter.nim/ https://github.com/niv/neverwinter.nim/) too. The good part about those is that they are cross-platform as well, and we can provide one-click binaries for users. OTOH, There's been a few rough edges and some issues along the way. Some platform snafus come to mind, but those have been early days - 0.17, etc. Some strange async bugs had been found and fixed quickly though. Good and bad, at least for me, nim has been a real joy to work with. If I had the chance to message my 3-years-younger, I'd just say "yea, keep going with that plan", as it turned out to save us a lot of development time. I suspect the features we've put in wouldn't have been possible in the timeframe we had, if it would have been all written in, say, C++.
- Abishek_Muthian 6y ago
  Interesting, thanks for sharing. May I ask, did you consider Go and decided against it for any reason considering your requirements of quick development, cross-platform, interoperability are all guaranteed features of Go which should have given better peace of mind considering a production application?
icey 6y ago
Nim is a lot of fun to write, and the language is small enough that you could build something fun / useful in a weekend. The community is also very responsive. Definitely worth checking out!
samuell 6y ago
It is nice with a lot of innovation now in the ahead-of-time compiled languages camp. What worries me is the fragmentation, and the fact that no one language seems to check all of the (subjective set of) boxes for a general purpose high-speed, ahead-of-time compiled language [0]. E.g, Crystal seems to be the only one supporting a modern concurrency story (similar to Go), but has a huge problem with compile times. Nim looks nice in many respects, but last I checked, they don't have anything like Go-like concurrency. Maybe not on everyone's wishlist, but as the world move toward flow everything/everywhere[1], I personally find this to be a problem. [0] https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__nzbCSFnnHicWrjxpW5l6-O3w/edit#gid=0 https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n... [1] https://www.amazon.com/Flow-Architectures-Streaming-Event-Driven-Integration/dp/1492075892/ https://www.amazon.com/Flow-Architectures-Streaming-Event-Dr...
- cb321 6y ago
  https://news.ycombinator.com/item?id=9640384 https://news.ycombinator.com/item?id=9640384
  - cb321 6y ago
    Also INim at the Nim-2020 conference for a REPL: https://www.youtube.com/watch?v=Qa_9vut4TzQ&list=PLxLdEZg8DRwTIEzUpfaIcBqhsj09mLWHx&index=4 https://www.youtube.com/watch?v=Qa_9vut4TzQ&list=PLxLdEZg8DR... In short, I think at least for the linked to table you mentioned, Nim does check all the boxes.
  - samuell 6y ago
    Thanks! This is interesting, although I'd be worried about how stable this is for the long term. Would be happy to have my worries annihilated of course :)
    - cb321 6y ago
      It depends how good/low level a programmer you are, but it's really not that hard to spin up your own impl. I did an (incomplete) Python multiprocessing like dealio in like 100 lines of code (https://github.com/c-blake/cligen/blob/master/cligen/procpool.nim https://github.com/c-blake/cligen/blob/master/cligen/procpoo...) just to make my `only.nim` run faster because libmagic/file are so CPU intensive. So, one way to annihilate your worries is to just roll your own.
historyremade 6y ago
Listen cowards of HN, Nim, Rust, Go etc all are try to replace King but failed. So don't reinvent the wheel please. I'd vote President Trump if he ban these shitty langs.
fataliss 6y ago
Maybe my lack of lower level language knowledge will show here, but how does that compare to Rust? I keep seeing and hearing about these new-ish languages Rust, Nim, Zig, etc. that all claim to be C/C++ perf lvl but better developper experience. Any of these is preferred for API/Web development? Does it yield much advantage over something like Elixir that already provides significant perf increase over a Python(Django-Flask)/RoR stack?
- steveklabnik 6y ago
  In my mind, and be aware of my bias here, these languages split up into three different categories: * Has a GC, but you can remove it. This is Nim and D. * Relies on pervasive refcounting. This is Nim if you choose that implementation, Swift. * Has no GC. This is Zig and Rust. (Though obviously you can use refcounting in these languages, but it is as a library.) While this focuses on a specific aspect of these langauges, I think it also represents their philosophies pretty well. Nim and D start from a "what if we had a GC" and then try to make things nicer down the stack. Rust and Zig are how nice can we go starting from nothing?" There are also additional factors that may or may not play in here, depending on what your needs are. Arguably, Rust is starting to break out of the "niche language" stage and move into the "significant projects and is sticking around" phase, whereas many of these other languages aren't quite there yet. This can matter with things like getting help, package support... some people love the open frontiers of new languages, others want something more mature. https://nimble.directory/ https://nimble.directory/ has 1,431 packages at the time of writing, https://crates.io/ https://crates.io/ has 48,197.
  - disruptek 6y ago
    Nim doesn't require that you use a gc; one of its many gc options is `none`, which is, as it sounds, no garbage collector at all.
    - steveklabnik 6y ago
      Right, that was the “you can remove it” part.
ejstembler 6y ago
Great! Where's the announcement on https://twitter.com/nim_lang https://twitter.com/nim_lang so I can retweet it?
- dom96 6y ago
  hehe, here you go https://twitter.com/nim_lang/status/1317192813042372609 https://twitter.com/nim_lang/status/1317192813042372609 :)
te 6y ago
Nim or Julia?
- ddragon 6y ago
  You can pick both, they are very different. Julia is a dynamic language looking for a compromise between interactivity and performance (from it's origin on R/Matlab), while Nim is one of the new batch of static languages that looks for the perfect balance between of easy of development and safety/speed. For example, if you want to do something more exploratory (like some research or data analysis) that can still easily scale up to HPC you can use Julia, if you want to create something reliable with small binaries and no start-up issues or use in more resource constrained environments you can use Nim.
  - cb321 6y ago
    Not that @ddragon exactly said you could not, but you can also use Nim for data science, such as https://mratsim.github.io/Arraymancer/ https://mratsim.github.io/Arraymancer/ or https://github.com/Vindaar/nimhdf5 https://github.com/Vindaar/nimhdf5 or many others and there is a REPL INim mentioned in another comment here. If you want everything "done for you already", Julia has more libraries and it is (for better or worse) more fundamentally dynamic.
- UMetaGOMS 6y ago
  As someone who doesn't do software development as part of routine day-to-day work but has played with both, I'd describe Julia as "Fortran for Python developers", while Nim feels like "C for Python developers". My interest in scientific applications pushes me towards Julia, but the user experience has so far been strictly worse than than Python, so I just don't bother with it as much as I might like to. On the other hand, I am drawn to experiment with Nim (and to some extent Rust as well) because they feel better constructed, having more professional feeling tools and approaches to packaging. The downside is that their core strengths are in use-cases which aren't so aligned with my interests. The strength of the Python packaging ecosystem makes me doubtful of the impact Julia can have. Meanwhile for Nim, it feels to me like awareness and adoption suffer a fair bit from competing with Rust for mindshare.
MrMan 6y ago
I am using nim this week on a data file scraping project. If you can Google and write python you can just start with nim and learn as you go, very easy. I am super bummed that there is (effectively) no debugging. I am too lazy to mess with VS code to get gdb working, it should just work already. Someday, I guess. Maybe jetbrains will save us. With real IDE support nim would sweep the nations.
- moigagoo 6y ago
  From my experience, there really is not that much need for debugging in the sense of adding breakpoints and attaching to a running process with Nim. Honestly, `debugEcho` suffices, give it a shot. I mean, you may need more debugging tools when your project gets large but since you're just starting with Nim, you can just relax and keep going.
  - MrMan 6y ago
    Relax is my strategy right now but I am a bear of little brain and spent years with Matlab stopped in the debugger while I went to lunch. Peering into data at will is something I can't easily give up. Debug trace was how I spent the stressful young years of my programming life and for data intensive, rather than logic intensive transactional code, I don't prefer tracing.
dom96 6y ago
I'm going to do a little bit of a shameless plug as a way to show off just what Nim is capable of. If you've ever played one of the many IO games, it might seem familiar to you. Basically I have used Nim to create a multiplayer game that can be played in the browser[1]. I'm planning to write up a more detailed post outlining the architecture of this. But suffice it to say, Stardust is written 100% in Nim. Both the servers and the client running in your browser is written in Nim. The client uses Nim's JS backend and the server Nim's C backend. The two share code to ensure the game simulation is the same across both. Communication happens over websockets. It's been a lot of fun working on this and I cannot imagine another language being as flexible as Nim to make something like this possible. I already have an Android client up and running too, it also is built from the same code and I plan to release it soon. 1 - https://stardust.dev/play https://stardust.dev/play
- mixmastamyk 6y ago
  > Android client up and running too, it also is built from the same code How does that work, and is it an alternative to dart/flutter?
  - dom96 6y ago
    I wouldn't say so. Since my game mostly just needs a canvas I make use of SDL2 to target Android (and plan to use it for iOS/desktop as well). I created a thin library which targets either HTML5 canvas (JS) or SDL2 (everything else): https://github.com/dom96/gamelight https://github.com/dom96/gamelight
- zacmps 6y ago
  Not to disparage Nim, but I can think of a number of other languages where this is possible: * JS, obviously * Rust * C/C++ * Anything else that can compile to WASM
  - dom96 6y ago
    Fair enough. I think then we get into how easy this is to do in these. For example, can you really target the web browser vs node from the same JS codebase by simply changing the compiler invokation?
tiffanyh 6y ago
Web development. I’ve said it before and I’ll say it again ... I wish more folks would use NIM for web development.
- moigagoo 6y ago
  100% agree. I'm developing an ORM [1] in my spare time specifically with the vision to make it easier to create web apps with Nim. Created a PoC with Jester in backend, Karax on the front, and Norm for model definition, and it turns out to be very much usable, accessing the same models from backend and frontend and all that. [1] https://norm.nim.town https://norm.nim.town
MrBuddyCasino 6y ago
So one of the biggest improvements to my day-to-day life as a programmer was having compiler-checked nullability in Kotlin. It is the most significant feature that makes programs more reliable and code more readable compared to Java. I never want to miss it again. Why did Nim decide to allow null pointers? They must have had a very good reason, given its young age?
- qmmmur 6y ago
  Interop I imagine.
- alehander42 6y ago
  nil checking is being worked on : it might be a part of 1.6
- cb321 6y ago
  Minor correction Re: "young age" - Nim dates back to 2006 with a first public release in 2008 and is older than Go and Go is older than Kotlin.
- mratsim 6y ago
  You need null pointers for system programming. That said you can already declare `type MyPtr = ptr int not nil` but the compiler is still clunky on proofs and needs a lot of help. it is planned to have a much better prover in the future and ultimately Z3 integration for such safety features: https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html

278 points by narimiran 6y ago

Great stuff! GC ORC is an amazing improvement over existing memory management models :) I hope to see more Nim projects adopt it!

Boxxed 6y ago

There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the user -- it's tough to prove a negative like this.

nicoburns 6y ago
Looks like it'a still an opt-in experimental option at this point rather than the default. Preaumably they'll fix these caveats before recommending it for general use.
- ziotom78 6y ago
  If I recall correctly, I read that the intention is to eventually make ORC the default, not ARC. (ORC is like ARC, but it avoids problems with cycles.)
  - Tiberium 6y ago
    Yes, you're totally right! That's the exact reason ORC should eventually become the new default GC.
Tiberium 6y ago
Sorry if you got misled by the article - ORC is what you should use if your program has cycles. ORC deals with async just fine.
- MaxBarraclough 6y ago
  Does ORC stand for something?
  - cb321 6y ago
    I could be wrong, but I believe the acronyms are: ARC = Automatic Reference Counting (NOTE: not Atomic) ORC = Optimized Reference Counting The loopy/circular character of the letter 'O' may be a secondary mnemonic since it collects cycles.
    - cb321 6y ago
      I meant "character" as in "nature" not as in the prog.lang "character type"..I just realized that in context this might be confusing. Lol.
djur 6y ago
I think you missed this detail: > ARC was first shipped with Nim 1.2... [ORC is] our main new feature for this release Seems like they should phrase it like "use ORC unless you know you don't have cycles" rather than "use ORC if you're not sure you have cycles", but that's a reasonable responsibility to take on if you're choosing to use an alternative garbage collector.
- mumblemumble 6y ago
  I'd prefer no phrasing at all. Just pick one that will work well in all cases, and don't give me any footguns.
  - adamc 6y ago
    Yes. Or at least put them in the appendix.
  - judofyr 6y ago
    To clarify: By default Nim will still use the GC which doesn't have any "footguns". ARC and ORC are new features which have different trade-offs, and some limitations. You opt-in to using them if you're interested.
    - deleted 6y ago
      [deleted]
  - gameswithgo 6y ago
    A way of dealing with memory that works well in all cases! That would be great.
leorize 6y ago
I believe the phrasing might not be clear to everyone, so here's a reduced version: * Nim's current async implementation creates a lot of cycles in the graph, so ARC can't collect them. * ORC is then developed as ARC + cycle collector to solve this issue, and it has been a success. * This 1.4 release introduces ORC to everyone so that we can have mass testing for this new GC and eventually move torwards ORC as the default GC. TL;DR: ORC works with everything† and will be the new default GC in the future. Your old Nim code will continue to work, and will just get faster‡. † We are not sure that it's bug-free yet, which is why it's not the default for this release. ‡ Most of the time ORC speeds things up, but there are edge cases where it might slow things down. You're encouraged to test your code with --gc:orc against our default GC and report performance regressions.
- treeform 6y ago
  Your explanation is very clear. Thanks.
wffurr 6y ago
Is there an msan/asan equivalent that can detect leaks in your test suite?
- leorize 6y ago
  Yes, we use valgrind for the compiler and stdlib test suite. The testament tool supports this, however it's not in widespread use outside of the compiler and stdlib, so documentation is rather sparse. Since Nim uses the C compiler to generate executables, you should be able to use `--passC:-fsanitize=memory --passL:-fsanitize=memory` to enable msan. For maximum effectiveness the flags `-d:useMalloc --gc:orc` should also be used. `-d:useMalloc` tells Nim to allocate memory using libc's malloc instead of our TSLF implementation. This should provide adequate compatibility for use with external inspection tools. We do `--gc:orc` because this is one of the only GCs that support -d:useMalloc (the other being arc).
  - scns 6y ago
    Please put this in the docs, if it is not there already
karmakaze 6y ago
I'm not familiar with Nim. Does it also support weak references? A significant portion of the problems with cycles in ARC are parent references.
- planetis 6y ago
  Weak references are possible with the .cursor pragma applied on local variables and object fields. This release introduces cursor inference too, enabled by default with --gc:arc|orc, but only for local variables.
mcintyre1994 6y ago
At an ELI5 level, does anyone know why Swift can have ARC and async but Nim's ARC doesn't work with async? Is it just implementation details of Nim's async specifically instead of anything more fundamental to ARC? Just asking out of curiosity.
- treeform 6y ago
  Yes. There is nothing fundamental to nim's ARC working with nim's async. There are attempts on make nim's async cycle free.
- dom96 6y ago
  Note that what we're referring to as "async" for Nim is actually "async await". AFAIK Swift doesn't support that, does it?
- darthrupert 6y ago
  Swift doesn't claim hard realtime capabilities like Nim's ARC does.

PMunch 6y ago

Great to see that Nim grows ever faster and more stable. Been a fan of the language for quite a while now and while I miss the old days of new and exiting changes with every release it's much easier to target Nim now that it has become this stable. Great work all around!

sp33der89 6y ago

Congratulations! And thanks for all the progress on ARC/ORC. But I must say, even though I'm excited about ARC/ORC, I'm even more happy to see the nice list of bugfixes and quality standard library additions!!

untog 6y ago

I played around with Nim a little and was amazed at how small the executables were: 10s of KB for something simple. Even Rust spits out 100s of KB, or even >1MB by default. In the end I still went with Rust, simply because it's more popular, but my initial impression was that Nim is a really fun language to work in, and much much easier to pick up than Rust.

anta40 6y ago
"and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.
- untog 6y ago
  Yes, I think for me Nim could be a great answer for when I want to throw together a quick script. Right now I'll often use JS/Node for that and I'm not going to switch to Rust because it'll take a lot longer to get a rough and ready script going.
  - cb321 6y ago
    Nim is indeed a great answer for this. Should you want to give that script a nice, traditional CLI then you can do so with very low effort using https://github.com/c-blake/cligen https://github.com/c-blake/cligen Should you want "script like" edit-test development cycle ergonomics you can use the TinyCC/tcc backend for compiles in ~200..300 milliseconds. Once it's how you like it you can compile with gcc & -d:danger for max performance in deployment.
  - treeform 6y ago
    I have so many little nim scripts all over the place.
    - cb321 6y ago
      Unmentioned so far is the NimScript mode `nim e`..For a portable sort of alternative to Bash scripting ("sort of" from the presently much longer start-up time...).

pshirshov 6y ago

> The reason is that only after the new(result, finalizer) call the compiler knows that it needs to generate a custom destructor for the CustomObject type, but when it compiled tricky the default destructor was used. I'm wondering why people underestimate graphs that much. It's lot easier to explicitly represent dependencies between your definitions as a graph and not just avoid such issues but also get rid of unnecessary passes. I did that in my compiler and it works great.

nepeckman 6y ago

Since Nim has hit the front page twice in the past day, let me just say: if you're at all curious about the language, try it out over the weekend. Nim isnt quite as simple as Zig (to compare to another compiled language with a smaller ecosystem), but the more advanced features stay out of the way until you need them. If you've worked with any static language, you probably know 80%-90% of what you need to write productive Nim code. The dev team has worked hard over the past year to improve documentation, and the website links to some great tutorials.

ziml77 6y ago
Maybe I'll give it another try. I might have gone too deep into the docs, but Nim seemed to get very complicated with all the {.annotation.} to remember
- nepeckman 6y ago
  If you're just starting with the language, my recommendation would be to ignore the pragmas. None of them are necessary for basic functionality, and a lot of them are only useful for very specific optimizations. The most useful pragmas in my experience are the pragmas for FFI, async, and memory/side effect tracking.
neverartful 6y ago
"Nim isn't quite as simple as Zig" My experience is complete opposite. I find Nim to be very simple and Zig to be not simple. What's the problem with Zig? I find the documentation to be chaotic. I believe that this is largely due to the rapid pace of changes (including changes that break earlier code).
- elcritch 6y ago
  That makes sense. I haven't tried Zig, but it's still pretty early in its history. That means a lot of syntax change, similar to Rust which is settling down, or Swift. Nim's been around long enough that it's settled it's syntax a while back. Before I started really digging into Nim, it seemed like it was always changing the language a lot (feature churn). However, most of those changes have been compiler support for different GC's and other backend languages, which don't generally break existing code. I've tried Nim code from 4 years ago, and its almost the exact same syntax. Sometimes stdlib names changed. I think syntax change is the part that gets people a lot in terms of daily "complexity". It actually reminds me of the feel of Python 2, before Python 3 that seems to add new syntax & language complexity every release. Well Python 2 but with a more solid language theory (e.g. everything can be a statement, etc). The trickiest part of day to day Nim are: var vs no-var, object vs ref object, and some iterator annoyances.

yitchelle 6y ago

I am intrigued by Nim. Anyone know of the motivation for Nim? I was not able to find that out in their website.

pietroppeter 6y ago
From this nice interview with Araq (language creator): http://157.245.209.254/andreas-rumpf-on-creating-and-growing-nim/ http://157.245.209.254/andreas-rumpf-on-creating-and-growing... > I started the Nim project after an unsuccessful search for a good systems programming language. Back then (2006) there were essentially two lines of systems programming languages: > The C (C, C++, Objective C) family of languages. > The Pascal (Pascal, Modula 2, Modula 3, Ada, Oberon) family of languages. > The C-family of languages has quirky syntax, grossly unsafe semantics and slow compilers but is overall quite flexible to use. This is mostly thanks to its meta-programming features like the preprocessor and, in C++'s case, to templates. > The Pascal family of languages has an unpleasant, overly verbose syntax but fast compilers. It also has stronger type systems and extensive runtime checks make it far safer to use. However, it lacks most of the metaprogramming capabilities that I wanted to see in a language. > For some reason, neither family looked at Lisp to take inspiration from its macro system, which is a very nice fit for systems programming as a macro system pushes complexity from runtime to compile-time. > And neither family looked much at the upcoming scripting languages like Python or Ruby which focussed on usability and making programmers more productive. Back then these attributes were ascribed to their usage of dynamic typing, but if you looked closely, most of their nice attributes were independent of dynamic typing. > So that's why I had to create Nim; there was a hole in the programming language landscape for a systems programming language that took Ada's strong type system and safety aspects, Lisp's metaprogramming system so that the Nim programmer can operate on the level of abstraction that suits the problem domain and a language that uses Python's readable but concise syntax.
- pietroppeter 6y ago
  Also relevant this other interview (video), a bit more recent: https://www.youtube.com/watch?v=-9SGIB946lw https://www.youtube.com/watch?v=-9SGIB946lw

euan_torano 6y ago

Awesome to see 1.4 finally released, and to have a version that should hopefully build cleanly out of the box on OpenBSD and FreeBSD and mostly "just work"[1]. Next target is NetBSD[2] then DragonFly! 1. https://github.com/nim-lang/Nim/issues/14035 https://github.com/nim-lang/Nim/issues/14035 2. https://forum.nim-lang.org/t/6610 https://forum.nim-lang.org/t/6610

DannyB2 6y ago

An economic argument for GC instead of ARC/ORC. Commercial web application in Java. Java GC is concurrent, on other cpu cores than the cores processing customer requests. Modern GCs such as Red Hat's Shenandoah or Oracle's ZGC have 1 ms or lower pause times on heap sizes of terabytes (TB). Java 15 increased max heap size from 4 TB to 16 TB of memory. Now the argument. A thread running on a cpu core which processes an incoming request has to earn enough to pay the economic dollar cost of the other threads that do GC on other cpu cores. But that thread processing the client request spends ZERO cpu cycles on memory management. No reference counting. Malloc is extremely fast as long as memory is available. (GC on other cores ensures this.) During or even after that thread has serviced a client request, GC will (later) "dispose" of the garbage that was allocated when servicing the client request. Obviously, just from Java continuously occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right. That said, I find Nim very interesting, and this is not a rant about Nim. I am skeptical of an alternative to real GC until it is proven to work, in a heavily multi threaded environment. And there is that economic argument of servicing client requests with no cpu cycles spent on memory management -- until AFTER the client request was fully serviced.

judofyr 6y ago
> Obviously, just from Java occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right. I'm not sure if this argument holds. Java's high memory usage is frequently cited as a downside of Java. GUI applications written in Java have a reputation of being memory-hungry, and I know plenty of people struggling with memory usage of server application (e.g. ElasticSearch). You will also find C/C++ on the same popularity lists… That said, I do agree that a tracing GC is a better solution (for most programs) than reference counting these days. The improvements in the pause times by the Java GCs are really impressive, and the throughput is great. One example would be ESBuild: The author created a prototype in both Rust and Go, and found that the Go version was faster allegedly because Rust ended up spending a lot of time deallocating [source: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284].
- 6y ago

xyproto 6y ago

I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.

speps 6y ago
Can you output WebAssembly/Emscripten project that uses SDL2?
- nikki93 6y ago
  This seems quite possible from everything I've explored, and also is something I want to try soon. It's also interesting to use Nim through JS for a scripting layer for an application written in Nim; where they both communicate through shared data structures or something. Here's a repo I found: https://github.com/Jipok/Nim-SDL2-and-Emscripten https://github.com/Jipok/Nim-SDL2-and-Emscripten
- treeform 6y ago
  Yes. People have done this.
sergiotapia 6y ago
Nim is my mistress. I work with Elixir and Javascript, but something about Nim is so pure and exact and precise. I love it. I'm hoping someone builds a great web framework with it, and a library like Ecto for better postgresql access. This language great potential to build faster software.

thelazydogsback 6y ago

NIM and Red (also on HN today) seem both seem to have an interesting and intersecting feature set. Anybody here used or heavily evaluated both that can comment?

cb321 6y ago
Rebol/Red is more like Python/Cython - able to be fast but falling back to an interpreter for dynamic things. As such there are probably more "performance footguns" (though any such thing is ultimately subjective based on programmer awareness). Nim feels more like what C++ (or Python) should always have been. Not sure if this helps. It's kind of a "big" question.
- 9214 6y ago
  No, it's actually the other way around: Red and Rebol are interpreted by default, and Red has a bootstrapping AOT compiler capable of bridging it with Red/System (a C-like sub-language), which it turn targets machine code. However, since Red is highly dynamic, compiler cannot preserve semantics across the whole language, so it keeps some parts for the interpreter to process at run-time. And sometimes that's the only option, since code can be generated on-the-fly or pulled over the network: Red is homoiconic and has quite powerful meta-programming facilities on top of that.
9214 6y ago
Nim and Red are quite different languages, both in terms of semantics and in terms of project's goals and scope. Perhaps you should elaborate on an intersection that you see between the two. I can speak only for Red: it takes its heritage in Lisp, Forth and Logo, has an embeded cross-platform GUI engine with a dedicated DSL for UI building, C-like sub-language for system level programming, OMeta-like PEG parser, and unique type system with literal forms for things like currencies, URLs, e-mail and dates with hashtags; all of that fitting in one-megabyte binary and valuing human-centered design above all.

nivviv 6y ago

A small perspective insight from a game developer: We (Beamdog) are using nim in production for Neverwinter Nights: Enhanced Edition, for the serverside parts of running the multiplayer infra. nim is uniquely good in providing an immense amount of value for very little effort. It gets _out of my way_ and makes it very easy to write a lot of code that mostly works really well, without having given me any serious traps and pits to fall into. No memleaks, no spurious crashes, no side-effect oopses, anything like that. It's C/++ interop has been a huge enabler for feature growth as well, as we can partly link in game code and it works fine. For example, our platform integrates seamlessly with native/openssl/dtls for game console connectivity. And it all works, and does so with good performance. It is all now a set of quite a few moving components (a message bus, various network terminators, TURN relays, state management, logging and metrics, a simple json api consumed both by game clients and web (https://nwn.beamdog.net https://nwn.beamdog.net), ...). We're still lagging behind and are on 1.0.8, but that is totally fine. It's tested and works, and there's no real incentive to move to 1.2 or 1.4 - yet! Usage for our game has expanded to provide a few open source supporting utilities (https://github.com/Beamdog/nwsync https://github.com/Beamdog/nwsync) and libraries (https://github.com/niv/neverwinter.nim/ https://github.com/niv/neverwinter.nim/) too. The good part about those is that they are cross-platform as well, and we can provide one-click binaries for users. OTOH, There's been a few rough edges and some issues along the way. Some platform snafus come to mind, but those have been early days - 0.17, etc. Some strange async bugs had been found and fixed quickly though. Good and bad, at least for me, nim has been a real joy to work with. If I had the chance to message my 3-years-younger, I'd just say "yea, keep going with that plan", as it turned out to save us a lot of development time. I suspect the features we've put in wouldn't have been possible in the timeframe we had, if it would have been all written in, say, C++.

Abishek_Muthian 6y ago
Interesting, thanks for sharing. May I ask, did you consider Go and decided against it for any reason considering your requirements of quick development, cross-platform, interoperability are all guaranteed features of Go which should have given better peace of mind considering a production application?

icey 6y ago

Nim is a lot of fun to write, and the language is small enough that you could build something fun / useful in a weekend. The community is also very responsive. Definitely worth checking out!

samuell 6y ago

It is nice with a lot of innovation now in the ahead-of-time compiled languages camp. What worries me is the fragmentation, and the fact that no one language seems to check all of the (subjective set of) boxes for a general purpose high-speed, ahead-of-time compiled language [0]. E.g, Crystal seems to be the only one supporting a modern concurrency story (similar to Go), but has a huge problem with compile times. Nim looks nice in many respects, but last I checked, they don't have anything like Go-like concurrency. Maybe not on everyone's wishlist, but as the world move toward flow everything/everywhere[1], I personally find this to be a problem. [0] https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__nzbCSFnnHicWrjxpW5l6-O3w/edit#gid=0 https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n... [1] https://www.amazon.com/Flow-Architectures-Streaming-Event-Driven-Integration/dp/1492075892/ https://www.amazon.com/Flow-Architectures-Streaming-Event-Dr...

cb321 6y ago
https://news.ycombinator.com/item?id=9640384 https://news.ycombinator.com/item?id=9640384
- cb321 6y ago
  Also INim at the Nim-2020 conference for a REPL: https://www.youtube.com/watch?v=Qa_9vut4TzQ&list=PLxLdEZg8DRwTIEzUpfaIcBqhsj09mLWHx&index=4 https://www.youtube.com/watch?v=Qa_9vut4TzQ&list=PLxLdEZg8DR... In short, I think at least for the linked to table you mentioned, Nim does check all the boxes.
- samuell 6y ago
  Thanks! This is interesting, although I'd be worried about how stable this is for the long term. Would be happy to have my worries annihilated of course :)
  - cb321 6y ago
    It depends how good/low level a programmer you are, but it's really not that hard to spin up your own impl. I did an (incomplete) Python multiprocessing like dealio in like 100 lines of code (https://github.com/c-blake/cligen/blob/master/cligen/procpool.nim https://github.com/c-blake/cligen/blob/master/cligen/procpoo...) just to make my `only.nim` run faster because libmagic/file are so CPU intensive. So, one way to annihilate your worries is to just roll your own.

historyremade 6y ago

Listen cowards of HN, Nim, Rust, Go etc all are try to replace King but failed. So don't reinvent the wheel please. I'd vote President Trump if he ban these shitty langs.

fataliss 6y ago

Maybe my lack of lower level language knowledge will show here, but how does that compare to Rust? I keep seeing and hearing about these new-ish languages Rust, Nim, Zig, etc. that all claim to be C/C++ perf lvl but better developper experience. Any of these is preferred for API/Web development? Does it yield much advantage over something like Elixir that already provides significant perf increase over a Python(Django-Flask)/RoR stack?

steveklabnik 6y ago
In my mind, and be aware of my bias here, these languages split up into three different categories: * Has a GC, but you can remove it. This is Nim and D. * Relies on pervasive refcounting. This is Nim if you choose that implementation, Swift. * Has no GC. This is Zig and Rust. (Though obviously you can use refcounting in these languages, but it is as a library.) While this focuses on a specific aspect of these langauges, I think it also represents their philosophies pretty well. Nim and D start from a "what if we had a GC" and then try to make things nicer down the stack. Rust and Zig are how nice can we go starting from nothing?" There are also additional factors that may or may not play in here, depending on what your needs are. Arguably, Rust is starting to break out of the "niche language" stage and move into the "significant projects and is sticking around" phase, whereas many of these other languages aren't quite there yet. This can matter with things like getting help, package support... some people love the open frontiers of new languages, others want something more mature. https://nimble.directory/ https://nimble.directory/ has 1,431 packages at the time of writing, https://crates.io/ https://crates.io/ has 48,197.
- disruptek 6y ago
  Nim doesn't require that you use a gc; one of its many gc options is `none`, which is, as it sounds, no garbage collector at all.
  - steveklabnik 6y ago
    Right, that was the “you can remove it” part.

ejstembler 6y ago

Great! Where's the announcement on https://twitter.com/nim_lang https://twitter.com/nim_lang so I can retweet it?

dom96 6y ago
hehe, here you go https://twitter.com/nim_lang/status/1317192813042372609 https://twitter.com/nim_lang/status/1317192813042372609 :)

te 6y ago

Nim or Julia?

ddragon 6y ago
You can pick both, they are very different. Julia is a dynamic language looking for a compromise between interactivity and performance (from it's origin on R/Matlab), while Nim is one of the new batch of static languages that looks for the perfect balance between of easy of development and safety/speed. For example, if you want to do something more exploratory (like some research or data analysis) that can still easily scale up to HPC you can use Julia, if you want to create something reliable with small binaries and no start-up issues or use in more resource constrained environments you can use Nim.
- cb321 6y ago
  Not that @ddragon exactly said you could not, but you can also use Nim for data science, such as https://mratsim.github.io/Arraymancer/ https://mratsim.github.io/Arraymancer/ or https://github.com/Vindaar/nimhdf5 https://github.com/Vindaar/nimhdf5 or many others and there is a REPL INim mentioned in another comment here. If you want everything "done for you already", Julia has more libraries and it is (for better or worse) more fundamentally dynamic.
UMetaGOMS 6y ago
As someone who doesn't do software development as part of routine day-to-day work but has played with both, I'd describe Julia as "Fortran for Python developers", while Nim feels like "C for Python developers". My interest in scientific applications pushes me towards Julia, but the user experience has so far been strictly worse than than Python, so I just don't bother with it as much as I might like to. On the other hand, I am drawn to experiment with Nim (and to some extent Rust as well) because they feel better constructed, having more professional feeling tools and approaches to packaging. The downside is that their core strengths are in use-cases which aren't so aligned with my interests. The strength of the Python packaging ecosystem makes me doubtful of the impact Julia can have. Meanwhile for Nim, it feels to me like awareness and adoption suffer a fair bit from competing with Rust for mindshare.

MrMan 6y ago

I am using nim this week on a data file scraping project. If you can Google and write python you can just start with nim and learn as you go, very easy. I am super bummed that there is (effectively) no debugging. I am too lazy to mess with VS code to get gdb working, it should just work already. Someday, I guess. Maybe jetbrains will save us. With real IDE support nim would sweep the nations.

moigagoo 6y ago
From my experience, there really is not that much need for debugging in the sense of adding breakpoints and attaching to a running process with Nim. Honestly, `debugEcho` suffices, give it a shot. I mean, you may need more debugging tools when your project gets large but since you're just starting with Nim, you can just relax and keep going.
- MrMan 6y ago
  Relax is my strategy right now but I am a bear of little brain and spent years with Matlab stopped in the debugger while I went to lunch. Peering into data at will is something I can't easily give up. Debug trace was how I spent the stressful young years of my programming life and for data intensive, rather than logic intensive transactional code, I don't prefer tracing.

dom96 6y ago

I'm going to do a little bit of a shameless plug as a way to show off just what Nim is capable of. If you've ever played one of the many IO games, it might seem familiar to you. Basically I have used Nim to create a multiplayer game that can be played in the browser[1]. I'm planning to write up a more detailed post outlining the architecture of this. But suffice it to say, Stardust is written 100% in Nim. Both the servers and the client running in your browser is written in Nim. The client uses Nim's JS backend and the server Nim's C backend. The two share code to ensure the game simulation is the same across both. Communication happens over websockets. It's been a lot of fun working on this and I cannot imagine another language being as flexible as Nim to make something like this possible. I already have an Android client up and running too, it also is built from the same code and I plan to release it soon. 1 - https://stardust.dev/play https://stardust.dev/play

mixmastamyk 6y ago
> Android client up and running too, it also is built from the same code How does that work, and is it an alternative to dart/flutter?
- dom96 6y ago
  I wouldn't say so. Since my game mostly just needs a canvas I make use of SDL2 to target Android (and plan to use it for iOS/desktop as well). I created a thin library which targets either HTML5 canvas (JS) or SDL2 (everything else): https://github.com/dom96/gamelight https://github.com/dom96/gamelight
zacmps 6y ago
Not to disparage Nim, but I can think of a number of other languages where this is possible: * JS, obviously * Rust * C/C++ * Anything else that can compile to WASM
- dom96 6y ago
  Fair enough. I think then we get into how easy this is to do in these. For example, can you really target the web browser vs node from the same JS codebase by simply changing the compiler invokation?

tiffanyh 6y ago

Web development. I’ve said it before and I’ll say it again ... I wish more folks would use NIM for web development.

moigagoo 6y ago
100% agree. I'm developing an ORM [1] in my spare time specifically with the vision to make it easier to create web apps with Nim. Created a PoC with Jester in backend, Karax on the front, and Norm for model definition, and it turns out to be very much usable, accessing the same models from backend and frontend and all that. [1] https://norm.nim.town https://norm.nim.town

MrBuddyCasino 6y ago

So one of the biggest improvements to my day-to-day life as a programmer was having compiler-checked nullability in Kotlin. It is the most significant feature that makes programs more reliable and code more readable compared to Java. I never want to miss it again. Why did Nim decide to allow null pointers? They must have had a very good reason, given its young age?

qmmmur 6y ago
Interop I imagine.
alehander42 6y ago
nil checking is being worked on : it might be a part of 1.6
cb321 6y ago
Minor correction Re: "young age" - Nim dates back to 2006 with a first public release in 2008 and is older than Go and Go is older than Kotlin.
mratsim 6y ago
You need null pointers for system programming. That said you can already declare `type MyPtr = ptr int not nil` but the compiler is still clunky on proofs and needs a lot of help. it is planned to have a much better prover in the future and ultimately Z3 integration for such safety features: https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html