24 ms·

Nim 1.0

785 points by treeform 7y ago

pietroppeter 7y ago
see also: https://nim-lang.org/araq/v1.html https://nim-lang.org/araq/v1.html
- treeform 7y ago
  see also change-log: https://github.com/nim-lang/Nim/blob/5b43c98897ee7eb9f8ded8ceb7623f6caa23bace/changelogs/changelog_1_0_0.md https://github.com/nim-lang/Nim/blob/5b43c98897ee7eb9f8ded8c...
- dmix 7y ago
  It's interesting to hear the constraints the language developer wanted from the beginning (20k lines, macro system drives most of the language development) and the various compromises they had to make along the way. > Furthermore, we don't really know yet how to leverage a macro system in order to give us extensibility on the type system level, so Nim's core needed generics and constraints for generics. I'm curious to dig into Nim and it's type system. I'm not familiar with Pascal style typing, I wonder how it compares with Rusts type system?
  - maxdamantus 7y ago
    I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that has always seemed notable to me is that it seems to defer type checking of generic code until it is instantiated (this is what happens in C++), so these functions will all typecheck until you actually try to use them: proc foo[T](): float32 = result = "foo" + 4 proc bar[T](n: T, m: T): T = result = n(m)(n) In Rust, such functions would require some sort of explicit constraints on `T`, so it's more-or-less guaranteed to be instantiable (ignoring the issue of polymorphic recursion) and you don't get some error pointing to code internal to the function when the user applies types that don't work.
    - Arnavion 7y ago
      >it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work. Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require with trait bounds). But if `foo` does use the concept `template<Incrementable T>`, then a call like `foo(S{})` will raise an error at the callsite, not at the `t++` line.
      - maxdamantus 7y ago
        Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types"). EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Looking into it now, Nim apparently has experimental support for the same feature: https://nim-lang.org/docs/manual_experimental.html#concepts https://nim-lang.org/docs/manual_experimental.html#concepts
        maxdamantus 7y ago
        > EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract). I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.
perturbation 7y ago
Congrats guys!!! This has been much-anticipated and I'm very excited. I personally wish that the owned reference stuff (https://nim-lang.org/araq/ownedrefs.html https://nim-lang.org/araq/ownedrefs.html) had been part of 1.0, but I think that at some point shipping 1.0 >> everything else. I've been following (and evangelizing) Nim for a while, this will make it easier to do so.
- treeform 7y ago
  I don't think the owned reference part will change the language drastically. For people that want to write kernels, games or real time code it would be great. Nim's GC is super configurable already. Yeah owned reference would be better but its already pretty good.
- Clyybber 7y ago
  It is part of 1.0, but you have to enable it using the "--newruntime" build switch.
- ptx 7y ago
  I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption? If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption? If an admin user object can suddenly start pointing to the guest user object and still be considered "memory safe", that doesn't seem like a very safe definition of safety.
  - loeg 7y ago
    It's type safety. The pointer will always point to an object of the same type. This is common in operating systems, for example. You have some out of band way of verifying that the object's identity has not changed (deallocation would be a change of identity) when you access the object under some sort of serialization. It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety. You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.
excursionist 7y ago
> Type identifiers should be in PascalCase [1] I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent. [1] https://nim-lang.org/docs/nep1.html#introduction-naming-conventions https://nim-lang.org/docs/nep1.html#introduction-naming-conv...
- alkonaut 7y ago
  In C# the lowercased ones are keywords, some of which map to built in types. For example "string" is a keyword that always means the type String (System.String). The word name "String" could be a type that some nefarious person added to your current namespace
- treeform 7y ago
  I think it does set the built-in types apart for being built it. Also tradition?
  - excursionist 7y ago
    That makes about as much sense as making builtin functions UPPERCASE. Also, what tradition?
- nemetroid 7y ago
  I like it. It lets the domain-specific types stand out.
- 19ylram49 7y ago
  On the contrary, I feel that the stylistic [and sometimes semantic] separation of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java) improves the developer experience, in that I can very quickly dissect the type of value that I’m dealing with when reading the code.
  - scottlamb 7y ago
    In Java that difference matters a lot for performance: primitives are unboxed, objects are boxed. (Not as true now with auto boxing and escape analysis, but this was absolutely true in version 1.0.) In C++ it can matter for correctness because primitives are uninitialized by default. But other types might be too and the standard library uses under_scores for things that are initialized on construction, so it's not a great example of this distinction. Why do you care in other languages? In Rust for example I'm a little fuzzy on why I care if something is considered a primitive.
nathcd 7y ago
Congratulations Nim team! :D I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on. This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's something I've been wanting in other languages since Nim added it. It seems like the 2010s have been a pretty amazing time for new programming languages. The ones that I can think of that I've at least tried are Rust, Go, Nim, Crystal, Zig, Pony, Fennel, Janet, and Carp (I know, some of these are pre-2010, but I think they've all either 1.0'd or had a first public release post-2010), and every single one has made me really excited about some aspect of it. I hope this experimentation continues into the 2020s!
- ksec 7y ago
  And it turns out Crystal 0.31 [1] is released! And it is ( or should be ) closing to 1.0 release as well, once Windows Support and MultiThreading matures. May be 2020? On the list of languages I only know the first few up to Zig, will need to check out the others. There is also one noticeable missing and that is Elixir. [1] https://crystal-lang.org/2019/09/23/crystal-0.31.0-released.html https://crystal-lang.org/2019/09/23/crystal-0.31.0-released....
  - nathcd 7y ago
    Good call! Also Julia, Typescript, and ReasonML now that I'm thinking about it.
  - phtrivier 7y ago
    Curious why you're adding Elixir in this list ? It operates is in a completely different space than nim / zig, as far as I know (Not statically checked, heavy but powerful runtime, much "higher level" abstractions, etc...) Not to prevent you from trying it, of course - to each and everyone their own...
    - yellowapple 7y ago
z3t4 7y ago
I was going to make a rant about sentimental versioning, but instead congratulations for reaching version 1.0
stakhanov 7y ago
I love nim! Wrote a several-thousand-line side project in it in 2015 and have rewritten it several times over, partially to improve the project itself, but also to keep up with language changes during the various alpha-releases. Did a little evaluation of Rust along the way, but decided my money was going to continue to be on nim. -- Congrats to the team, and thank you so much for making it happen!
nfrankel 7y ago
Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?
- 19ylram49 7y ago
  Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?
  - ptx 7y ago
    It all depends on the tone of the question, which is hard to discern in writing, so the clarification is helpful. Edit: Yes, those are very valid and reasonable questions. Clarifying that it's not meant as trolling is also valid and reasonable, because writing is easily misunderstood in exactly that way - which is the reason smileys were invented. (And, to be clear, I'm not accusing anyone of missing smileys or of trolling. I am trying to express my agreement with both parent and grandparent.)
    - markdog12 7y ago
      Asking a question in plain English like this shouldn't require further clarification.
  - nimmer 7y ago
    Sometime people troll by sealioning: http://wondermark.com/c/2014-09-19-1062sea.png http://wondermark.com/c/2014-09-19-1062sea.png (I'm not accusing the granparent post)
    - anchpop 7y ago
      I've seen that comic before but have no idea what it's trying to express, could you explain? Is it just when you repeatedly pester someone with questions to annoy them?
  - simplify 7y ago
steve_adams_86 7y ago
This is super cool. I built a small CLI tool with Nim back in 2017, and it was a joy. It ended up being very accessible to the rest of the team for further development (probably more credit due to the folks building Nim than to my design) and I believe it's still in use. It's a good language, and it was a nice break from JavaScript (which I also enjoy, but not so much for CLI tools). If you haven't tried it out yet, I highly recommend it.
inportb 7y ago
Does it support tabs for indentation yet?
- SolitudeSF 7y ago
  #? replace(sub = "\t", by = " ") but please, dont
Kip9000 7y ago
Christmas had come early!!
pier25 7y ago
Congrats to the team! Could Nim be used to generate a framework for Xcode and the the same code be used in a Windows C++ or .NET project? I've been looking for ages for a cross platform solution that can be used to create dynamic or static libraries that isn't C++.
- nepeckman 7y ago
  As far as I know, that should be doable. Nim can compile to Objective C as well as C++, and has a `when` statement that makes it easy to produce code for a specific OS or language target. Not an Xcode or .NET expert though, so not sure how difficult it is to hook into those platforms.
- PMunch 7y ago
  Without knowing any more specifics about your problem it seems like this would be possible in Nim. It is cross platform and can generate dynamic libraries across them. I guess you could somehow also set up a static library, but I've never tried that myself. So as long as your target language(s) have the ability to use dynamic libraries then Nim should be able to supply them.
13415 7y ago
Great! I love this language, so simple and powerful, so fast executables! I hope I don't spoil the party by asking: What's the status of GUI bindings?
- PMunch 7y ago
  WxWidgets works great, Gtk(2/3) also works great (both have macros that make actually creating UI's much easier than in most other languages). There is also wNim for making Windows UIs and NiGui for pure Nim cross platform UIs (that target the native toolkits). Apart from that there are various bindings to other toolkits, both meant to be embedded in games, and stand-alone things. There's even ways to use Nim code to power Electron apps. So all in all I'd say it's pretty decent, but I still have plans for my own toolkit that would solve my personal gripes with creating cross platform UIs.
  - mwcampbell 7y ago
    I'm curious about why you want to develop your own toolkit and what will differentiate it from the others. Will it draw its own widgets, or wrap platform-native toolkits?
    - PMunch 7y ago
      Well it all started when I wrote the genui macros for wxNim and the Gtk wrappers. I started working on a rather simple note-taking application and had an idea in mind for what I wanted it to look like. Turns out this look wasn't possible in wxWidgets without resorting to custom widgets (because the Windows back-end didn't have support for something none of the others could support it). So I had to switch away from wxWidgets and use Gtk instead, not a huge issue for that project since I was just going to use it for personal purposes anyways, but it made me realise something. There isn't a single cross-platform UI toolkit that allows me to learn that one library and then create UIs for either all the targets, or one specific target. The idea has then gone through many revisions and back and forth on implementation ideas, but the current vision is to base it on Nims powerful type system. So instead of saying that "I want a wxTextCtrl" you say "I want to have a way of editing this string". Then it is up to the target toolkit to have an idea of how a string should be edited. Then any sort of styling of the resulting UIs are done on a per-platform basis, with whatever tools are available for that platform. This will also allow the toolkit "drivers" to take in their own UI specifications (for example Glade for Gtk) and map the types you supply to parts of the UI. Essentially separating the UI generation completely from the code/logic. The benefits of an approach like this is that for a simple UI that is only meant as a front-end for some algorithm you can just specify your inputs and actions and the UI can be automatically generated for you across platforms. If it looks weird on one platform you are able to specify for that platform what modifications to make. Or if you want to create a beautiful shiny graphical application you are able to tailor make every aspect of the UI for the target platform and then bind it back to your code. This is probably already way longer than what you expected, or even wanted, I've been thinking about this and toying around with implementations for a while now. I had an early prototype that created widgets for Gtk and Karax (Nim web front-end toolkit) that worked really well, but I hit some snags with the implementation in an earlier version of the language. Now that the language is more mature, and I'm more used to it, I might finally be able to implement it properly.
dom96 7y ago
Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :) It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work. Grab a copy here: https://manning.com/books/nim-in-action?a_aid=niminaction&a_bid=78a27e81 https://manning.com/books/nim-in-action?a_aid=niminaction&a_...
- PMunch 7y ago
  Not only a good resource to learn Nim, but also an excellent programming book in general!
- totalperspectiv 7y ago
  I can confirm, the book is excellent and worth a read-through.
- sergiotapia 7y ago
  Thank you, purchasing a copy now
- muktabh 7y ago
  I bought a copy of the book a few months back (and haven't yet found time to read it fully, I can write a lot of programs just after reading a first few chapters), will Manning upgrade it for a newer version for Nim 1.0 ?
  - narimiran 7y ago
    > will Manning upgrade it for a newer version for Nim 1.0 ? The version of the book you bought (and which is still on sale) is compatible with Nim v1 and it is still relevant, no need for another version anytime soon.
- ecmascript 7y ago
  Aw, I missed it by a couple of hours.. :/
qaq 7y ago
Once ecosystem matures (good async db drivers) would be pretty good option for web dev
- dom96 7y ago
  It's already a pretty good option, the Nim forum is written 100% in Nim.
75dvtwin 7y ago
Finally, very happy for Nim and the team! version 1.0, stability, RFC process -- all are signs of maturing language and the ecosystem. Here is a curated list of frameworks for Nim https://github.com/VPashkov/awesome-nim https://github.com/VPashkov/awesome-nim For me, personally, the interest, is its javascript-as-target capabilities.
rajangdavis 7y ago
For compiling to Javascript, is it possible to use npm modules with the code?
- dom96 7y ago
  There is no first-party support for this, but I don't see why it shouldn't be possible. It might take quite some effort though.
- curioussavage 7y ago
  I know of at least one nim lib that wraps a js lib (react) you could find that and use it as an example.
- SolitudeSF 7y ago
  https://github.com/bluenote10/nim-electron-karax https://github.com/bluenote10/nim-electron-karax
staticassertion 7y ago
Right now I write, almost exclusively, Rust and Python. I'm really hoping I can replace a lot of the Python code with Nim some day.
_0ffh 7y ago
I've been intermittently working on my own language ("transpiled" to C) for more than three years before seriously checking out Nim in 2015, at which point I just threw my code away. It already had very nearly everything I thought I could bring to the table, and then some stuff I had never even contemplated. Go, go, Nim!
maxpert 7y ago
Congrats and Thanks Nim team. I’ve been tinkering with Nim to build a really efficient pubsub server. Something that can take heavy concurrent connections. Now I can actually build with confidence.
ilaksh 7y ago
One exciting new project using Nim: https://github.com/status-im/nim-libp2p https://github.com/status-im/nim-libp2p and also https://github.com/status-im/nimbus https://github.com/status-im/nimbus which is a lightweight Ethereum 1.0 & 2.0 client in development. If Ethereum 2.0 is really able to scale like they plan, a project like nimbus could really enable widespread use of cryptocurrency on phones.
p5a0u9l 7y ago
But why do they have to use camelCase? I don't know why it bothers me so, but I see that in a language or a repo and immediately and irrationally despise it. Is it just me?
- tachyonbeam 7y ago
  Camel case is extremely common, but it's funny that they use it given that the language is case insensitive: https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-it-caseunderscore-insensitive https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i... Sidenote: not a Nim user, but this seems like it could get in the way of interoperability with C (and most other languages)?
  - PMunch 7y ago
    Not really, when you want to import things from C you simply name them what you like and then you can call them in a case-insensitive fashion. When writing code that should be imported into C code it will either have its name exactly as typed, or you can specify a name for it yourself.
- xena 7y ago
  Nim is style insensitive, so `foo_bar`, `foobar` and `fooBar` all resolve to the same symbol. However, `Foobar` won't.
- hota_mazi 7y ago
  More of a personal preference, but to me, typing all these underscores all the time would probably give me carpal tunnel syndrome within just a few years.
- PMunch 7y ago
  As other have mentioned Nim is style insensitive. This might sound odd at first, but it allows you to use snake_case in your code even though the standard library is camelCase. It also allows me to use your snake_case library in my camelCase code without ending up in mixed_Case hell like you often end up in Python.
mwcampbell 7y ago
I noticed that Araq's personal post about v1.0 mentioned a powerful macro system as a top priority. I wonder if Nim's macro system is now expressive enough that a front-end web framework like Svelte [1] could be implemented using Nim macros, as opposed to Svelte's HTML template language and custom compiler. COuld be useful for developing isomorphic web apps with something lighter than Node on the server side. [1]: https://svelte.dev/ https://svelte.dev/
- leorize 7y ago
  I think this is what you're looking for: https://github.com/pragmagic/karax https://github.com/pragmagic/karax
  - mwcampbell 7y ago
    Not quite. Karax has a virtual DOM, and Svelte's creator argues that this is pure overhead [1]. [1]: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
aredirect 7y ago
Congratulations Nim team! Last year I wrote a book on building applications with Nim, now I think it's the time for all of the people waited for 1.0 to pick it up https://xmonader.github.io/nimdays/ https://xmonader.github.io/nimdays/
6gvONxR4sf7o 7y ago
I love seeing new languages that do interesting things. I wish I could see what languages everyone will be using in 100 years. Or at least I'm curious what we'd see with 100 years of development towards solving today's problems (and without AI because that's not what this particular fantasy of mine is about). It's one of my favorite things to fantasize about when I run into another python bug or a write a tedious unit test that feels like I should be able to let my tools deal with for me. Super-future-dependent-haskell's type system with python's ergonomics, and fantasy-future-python's gradual typing to go fast and loose when I feel like it, and C's ability to specify exactly what I want when I need to with rust's ability to keep me from shooting myself in the foot while doing so, and zig's ability to do dead-simple compile time programming, and super-future-idris/coq's ability to write ergonomic proofs in place of many tests, and so on. Or even the futuristic fantasy one-FFI-to-rule-them-all, so I can mix and match pieces super smoothly. Every time I see an interesting new language catching on, I can't help but engage in optimistic flights of fancy about the future of programming.
- DNF2 7y ago
  Many of these features sound like Julialang to me.. Not certain how well they fit with Nim. In fact, I almost suspect you are hinting in that direction yourself ;)
  - freyr 7y ago
    Let's not call it that.
  - xyproto 7y ago
    Julia discourages Linux distros to package it. They include modified and unmodified versions of all libraries they depend on within the Julia source repository. I am not quite sure how they are planning to grow within the ecosystem that matters most for many developers.
    - DNF2 7y ago
      There's a very major revamp going on of how binary dependencies are handled. I don't know much about it, but it might possibly change this picture.
benboughton1 7y ago
I have been considering approaching a new language lately after have self learn python and more recently javascript. Where does nim sit in regards to the future of machine learning? Can we expect clones of pytorch/tensorflow? Is it a suitable language for this?
- narimiran 7y ago
  > Where does nim sit in regards to the future of machine learning? Can we expect clones of pytorch/tensorflow? https://github.com/fragcolor-xyz/nimtorch https://github.com/fragcolor-xyz/nimtorch
  - benboughton1 7y ago
    Cheers. No harm in checking it out. That Manning book looks good.
ziotom78 7y ago
I would have never thought to live long enough to see this happening! I started using Nim in 2014, but abandoned it after a few years, frustrated by the instability of the language and what I perceived as a lack of vision. (In 2014, release 1.0 was said to be "behind the corner".) This release makes me eager to try it again. I remember that the language impressed me a lot: easy to learn, well-thought, and very fast to compile. Congratulations to the team!
tomp 7y ago
What’s Nim’s concurrency story? Since it’s compuled via C, I suspect the answer is “shitty” as in I expect it to inherit all of C’s issues with undefined behaviour, values out of thin air, and so on...
- Varriount 7y ago
  That's kinda jumping the gun - just because something is compiled to C, doesn't mean that it has all of the characteristics of C. That's like saying that because something is compiled to assembly, it has all the complexities and dangers of assembly. For example, take a look at Cython, CGo etc. Regarding concurrency, Nim has cross-platform thread support in the standard library. Concurrency, at least right now, is more memory safe than other languages, but also more restrictive. Each thread has its own heap, and and memory from one thread's heap cannot be referenced by another thread's heap without use of unsafe pointers. One can, however, copy memory from one heap to another. There are more abstract currency mechanisms detailed in the manual (primarily for work that is well-suited for threadpool use cases)
  - tomp 7y ago
    > and memory from one thread's heap cannot be referenced by another thread's heap without use of unsafe pointers Are you sure about that? Your statement seems to conflict Nim's manual, which says > Each thread has its own (garbage collected) heap and sharing of memory is restricted to global variables. This does suggest it inherits all of C's memory (un)safety characteristics.
  - dom96 7y ago
    Note that what you’re describing here is Nim’s parallelism. Nim supports concurrency via a macro-implemented async await mechanism that is very mature (it runs in production at https://forum.nim-lang.org https://forum.nim-lang.org)
peteforde 7y ago
Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators, what is the philosophy driving its design, is it intended to be an eventual competitor or replacement for languages XYZ, where does it sit on the spectrum between raw assembly and MS Access, is it intended to be a "systems language" eg can you write a kernel or device driver using it, does it require a VM, is there corporate support available, how established is the developer community, are there books and courses, does it have garbage collection, is it a compiled language, is it a strongly typed language, what are the three perfect use cases, how stable is the API, what's the package management story, does it have a reasonable standard library, is there editor support for color coding and linting, what's the job market look like, is the documentation well-written, and most importantly, if we all got in the same room, would I want to hang out with the people excited about this language? The cost of learning yet another language vs actually spending your finite spare time building something (or with your loved ones, or reading, or sleeping, or making art) is insanely huge.
- qpleple 7y ago
  From a book linked in another comment: https://livebook.manning.com/book/nim-in-action/chapter-1/34 https://livebook.manning.com/book/nim-in-action/chapter-1/34
- narimiran 7y ago
  > yet another slightly different take on Rust or Go From Wikipedia article of each language: Rust: First appeared July 7, 2010; 9 years ago Go: First appeared November 10, 2009; 9 years ago Nim: First appeared 2008; 11 years ago
  - lmm 7y ago
    The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand out?
ayush--s 7y ago
Great that it's here. I tried Nim around 8-9 months ago, and left it because I didn't want to work with a language that wasn't stable yet. Guess I'll give it a visit again.
- narimiran 7y ago
  > I didn't want to work with a language that wasn't stable yet. IME, the language was quite stable since version 0.19, which was released one year ago. But I know that people don't trust some random bloke on the internet, they want to see 1.0 before they dive in. I had the same concern when I first heard about Nim (I think at that time Nim was at v0.17).
atemerev 7y ago
Nim is a thing of beauty. It has a well-thought syntax (some consider it to be similar to Python, but it removes many Python idiosyncrasies), state of the art type system with generics, beyond state of the art macro system, excellent performance (comparable to Rust or C), and it can work as a low-level or a high-level language. It is pragmatic: you can write functional or imperative code, neither is imposed on you. There are so many beautiful hacks I enjoy (e.g. unit tests are supposed to be included in each file, all files are compiled as executables, and you can run them to run the tests). Here is a taste of what's possible: https://hookrace.net/blog/what-is-special-about-nim/ https://hookrace.net/blog/what-is-special-about-nim/
wiz21c 7y ago
Why Nim ? As someone who put a lot of efforts in some personal project and understands what it takes to build a new language, I wonder why did the Nim's authors did it in the first place ? Just for the sake of it ? To make money ? For the fun ? I'd like to know (as Nim doesn't seem to be backed by big dollars)
- sheerun 7y ago
  It compiles to C which compiles to everything. You don't have that with Rust or Go
- jhbadger 7y ago
  Basically it is a compiled language that feels like a scripting language -- typically compiled languages have so much boilerplate code -- but Nim doesn't. If you just looked at a Nim program, you might even think it is in some scripting language you haven't seen before. I see Nim and Crystal filling a similar niche -- Nim feels more like Python and Crystal more like Ruby.
  - squarefoot 7y ago
    "Nim feels more like Python and Crystal more like Ruby" Agreed. To me Crystal is a bit easier to grasp because I already used Ruby a long ago, but it has the non trivial disadvantage of being bootstrapped (ie, it requires itself to compile itself) so that it is slower to port to different architectures.
- nimmer 7y ago
  > To make money? Not at all. Nim aims to achieve the expressiveness of Python , the speed of C, the programmability of LISP.
  - zerr 7y ago
    What about kotlin-native?
    - 7y ago
guggle 7y ago
Love Nim ! Key points for me: - familiar, easy to read syntax - great performance - standalone executables / ease of deployment - easy interfacing with C and C++ code I would love to see its community grow and see more available libs.
planetis 7y ago
My reasons for using nim: - Syntax is very expressive and not restrictive or bloated (I can write clean code, almost like pseudocode, without boilerplate) - Runs fast and has type checking something that Python lacked (until recently at least) (When I was programming in python I was so frustrated that any variable could be used in a function call and no code is checked until it's used, Also 'nim c -r file' is faster than any Python program I have written) - Documentation is very good nowadays, but since code was so easy to read and in nim (whereas most python code interfaces with c) I could read and understand what the standard library functions were doing, another big plus when learning.
deleted 7y ago
[deleted]
fithisux 7y ago
While Nim is a much better python, you cannot use python modules with Nim (pushing strings to a python interpreter does not count as such), so you need some man-years to build a reasonable software collection. Haxe had another approach. Create a library and transpile it to be used with Lua/Python/ Java and other options.
- narimiran 7y ago
  Have you seen Nimpy[0]? It allows for a nice integration between Nim and Python. At least for the examples I have tried, it could be used in place of Cython, when there's a need for extra speed in some hot loops and similar situations. [0] https://github.com/yglukhov/nimpy https://github.com/yglukhov/nimpy
  - fithisux 7y ago
    Havent't seen this. Should try.
kalekold 7y ago
The binary sizes that Nim produces are as usual misrepresented. D and C will blow it out of the water. Here's some D code: import core.stdc.stdio; extern(C) void main() { printf("Hello, World!\n"); } Compile with: $ dmd -betterC main.d $ ls -h main -rwxrwxr-x 1 user group 8.5K Sep 24 12:39 main
- szemet 7y ago
  I guess the examples use the default std libs, and runtimes of the languages. So in this sense your D example is the misrepresentation, by directly calling libc. If these kinds of low level size optimizations are enabled then both Nim and Rust can be more than 50 times smaller than your D example ;) : 150 byte Nim: https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/ 151 byte Rust: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...
Mikeb85 7y ago
Fantastic news. I haven't done anything too serious with Nim, but I did find for the code I did write in it, that its extremely intuitive and easy to get going. It also has all the features I could ask for in a language and it never feels like you need to work around a limitation. Of course that's the initial impression, I haven't used it as much as languages that have batteries included for the specific tasks I do (most of the programming I actually do these days is around data analysis, economic forecasting, so R is pretty hard to beat).
juststeve 7y ago
Damn, this is some solid work. Seriously impressive.

Nim 1.0

785 points by treeform 7y ago

pietroppeter 7y ago

see also: https://nim-lang.org/araq/v1.html https://nim-lang.org/araq/v1.html

treeform 7y ago
see also change-log: https://github.com/nim-lang/Nim/blob/5b43c98897ee7eb9f8ded8ceb7623f6caa23bace/changelogs/changelog_1_0_0.md https://github.com/nim-lang/Nim/blob/5b43c98897ee7eb9f8ded8c...
dmix 7y ago
It's interesting to hear the constraints the language developer wanted from the beginning (20k lines, macro system drives most of the language development) and the various compromises they had to make along the way. > Furthermore, we don't really know yet how to leverage a macro system in order to give us extensibility on the type system level, so Nim's core needed generics and constraints for generics. I'm curious to dig into Nim and it's type system. I'm not familiar with Pascal style typing, I wonder how it compares with Rusts type system?
- maxdamantus 7y ago
  I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that has always seemed notable to me is that it seems to defer type checking of generic code until it is instantiated (this is what happens in C++), so these functions will all typecheck until you actually try to use them: proc foo[T](): float32 = result = "foo" + 4 proc bar[T](n: T, m: T): T = result = n(m)(n) In Rust, such functions would require some sort of explicit constraints on `T`, so it's more-or-less guaranteed to be instantiable (ignoring the issue of polymorphic recursion) and you don't get some error pointing to code internal to the function when the user applies types that don't work.
  - Arnavion 7y ago
    >it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work. Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require with trait bounds). But if `foo` does use the concept `template<Incrementable T>`, then a call like `foo(S{})` will raise an error at the callsite, not at the `t++` line.
    - maxdamantus 7y ago
      Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types"). EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Looking into it now, Nim apparently has experimental support for the same feature: https://nim-lang.org/docs/manual_experimental.html#concepts https://nim-lang.org/docs/manual_experimental.html#concepts
      - maxdamantus 7y ago
        > EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract). I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.

perturbation 7y ago

Congrats guys!!! This has been much-anticipated and I'm very excited. I personally wish that the owned reference stuff (https://nim-lang.org/araq/ownedrefs.html https://nim-lang.org/araq/ownedrefs.html) had been part of 1.0, but I think that at some point shipping 1.0 >> everything else. I've been following (and evangelizing) Nim for a while, this will make it easier to do so.

treeform 7y ago
I don't think the owned reference part will change the language drastically. For people that want to write kernels, games or real time code it would be great. Nim's GC is super configurable already. Yeah owned reference would be better but its already pretty good.
Clyybber 7y ago
It is part of 1.0, but you have to enable it using the "--newruntime" build switch.
ptx 7y ago
I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption? If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption? If an admin user object can suddenly start pointing to the guest user object and still be considered "memory safe", that doesn't seem like a very safe definition of safety.
- loeg 7y ago
  It's type safety. The pointer will always point to an object of the same type. This is common in operating systems, for example. You have some out of band way of verifying that the object's identity has not changed (deallocation would be a change of identity) when you access the object under some sort of serialization. It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety. You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.

excursionist 7y ago

> Type identifiers should be in PascalCase [1] I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent. [1] https://nim-lang.org/docs/nep1.html#introduction-naming-conventions https://nim-lang.org/docs/nep1.html#introduction-naming-conv...

alkonaut 7y ago
In C# the lowercased ones are keywords, some of which map to built in types. For example "string" is a keyword that always means the type String (System.String). The word name "String" could be a type that some nefarious person added to your current namespace
treeform 7y ago
I think it does set the built-in types apart for being built it. Also tradition?
- excursionist 7y ago
  That makes about as much sense as making builtin functions UPPERCASE. Also, what tradition?
nemetroid 7y ago
I like it. It lets the domain-specific types stand out.
19ylram49 7y ago
On the contrary, I feel that the stylistic [and sometimes semantic] separation of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java) improves the developer experience, in that I can very quickly dissect the type of value that I’m dealing with when reading the code.
- scottlamb 7y ago
  In Java that difference matters a lot for performance: primitives are unboxed, objects are boxed. (Not as true now with auto boxing and escape analysis, but this was absolutely true in version 1.0.) In C++ it can matter for correctness because primitives are uninitialized by default. But other types might be too and the standard library uses under_scores for things that are initialized on construction, so it's not a great example of this distinction. Why do you care in other languages? In Rust for example I'm a little fuzzy on why I care if something is considered a primitive.

nathcd 7y ago

Congratulations Nim team! :D I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on. This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's something I've been wanting in other languages since Nim added it. It seems like the 2010s have been a pretty amazing time for new programming languages. The ones that I can think of that I've at least tried are Rust, Go, Nim, Crystal, Zig, Pony, Fennel, Janet, and Carp (I know, some of these are pre-2010, but I think they've all either 1.0'd or had a first public release post-2010), and every single one has made me really excited about some aspect of it. I hope this experimentation continues into the 2020s!

ksec 7y ago
And it turns out Crystal 0.31 [1] is released! And it is ( or should be ) closing to 1.0 release as well, once Windows Support and MultiThreading matures. May be 2020? On the list of languages I only know the first few up to Zig, will need to check out the others. There is also one noticeable missing and that is Elixir. [1] https://crystal-lang.org/2019/09/23/crystal-0.31.0-released.html https://crystal-lang.org/2019/09/23/crystal-0.31.0-released....
- nathcd 7y ago
  Good call! Also Julia, Typescript, and ReasonML now that I'm thinking about it.
- phtrivier 7y ago
  Curious why you're adding Elixir in this list ? It operates is in a completely different space than nim / zig, as far as I know (Not statically checked, heavy but powerful runtime, much "higher level" abstractions, etc...) Not to prevent you from trying it, of course - to each and everyone their own...
  - yellowapple 7y ago

z3t4 7y ago

I was going to make a rant about sentimental versioning, but instead congratulations for reaching version 1.0

stakhanov 7y ago

I love nim! Wrote a several-thousand-line side project in it in 2015 and have rewritten it several times over, partially to improve the project itself, but also to keep up with language changes during the various alpha-releases. Did a little evaluation of Rust along the way, but decided my money was going to continue to be on nim. -- Congrats to the team, and thank you so much for making it happen!

nfrankel 7y ago

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

19ylram49 7y ago
Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?
- ptx 7y ago
  It all depends on the tone of the question, which is hard to discern in writing, so the clarification is helpful. Edit: Yes, those are very valid and reasonable questions. Clarifying that it's not meant as trolling is also valid and reasonable, because writing is easily misunderstood in exactly that way - which is the reason smileys were invented. (And, to be clear, I'm not accusing anyone of missing smileys or of trolling. I am trying to express my agreement with both parent and grandparent.)
  - markdog12 7y ago
    Asking a question in plain English like this shouldn't require further clarification.
- nimmer 7y ago
  Sometime people troll by sealioning: http://wondermark.com/c/2014-09-19-1062sea.png http://wondermark.com/c/2014-09-19-1062sea.png (I'm not accusing the granparent post)
  - anchpop 7y ago
    I've seen that comic before but have no idea what it's trying to express, could you explain? Is it just when you repeatedly pester someone with questions to annoy them?
- simplify 7y ago

steve_adams_86 7y ago

This is super cool. I built a small CLI tool with Nim back in 2017, and it was a joy. It ended up being very accessible to the rest of the team for further development (probably more credit due to the folks building Nim than to my design) and I believe it's still in use. It's a good language, and it was a nice break from JavaScript (which I also enjoy, but not so much for CLI tools). If you haven't tried it out yet, I highly recommend it.

inportb 7y ago

Does it support tabs for indentation yet?

SolitudeSF 7y ago
#? replace(sub = "\t", by = " ") but please, dont

Kip9000 7y ago

Christmas had come early!!

pier25 7y ago

Congrats to the team! Could Nim be used to generate a framework for Xcode and the the same code be used in a Windows C++ or .NET project? I've been looking for ages for a cross platform solution that can be used to create dynamic or static libraries that isn't C++.

nepeckman 7y ago
As far as I know, that should be doable. Nim can compile to Objective C as well as C++, and has a `when` statement that makes it easy to produce code for a specific OS or language target. Not an Xcode or .NET expert though, so not sure how difficult it is to hook into those platforms.
PMunch 7y ago
Without knowing any more specifics about your problem it seems like this would be possible in Nim. It is cross platform and can generate dynamic libraries across them. I guess you could somehow also set up a static library, but I've never tried that myself. So as long as your target language(s) have the ability to use dynamic libraries then Nim should be able to supply them.

13415 7y ago

Great! I love this language, so simple and powerful, so fast executables! I hope I don't spoil the party by asking: What's the status of GUI bindings?

PMunch 7y ago
WxWidgets works great, Gtk(2/3) also works great (both have macros that make actually creating UI's much easier than in most other languages). There is also wNim for making Windows UIs and NiGui for pure Nim cross platform UIs (that target the native toolkits). Apart from that there are various bindings to other toolkits, both meant to be embedded in games, and stand-alone things. There's even ways to use Nim code to power Electron apps. So all in all I'd say it's pretty decent, but I still have plans for my own toolkit that would solve my personal gripes with creating cross platform UIs.
- mwcampbell 7y ago
  I'm curious about why you want to develop your own toolkit and what will differentiate it from the others. Will it draw its own widgets, or wrap platform-native toolkits?
  - PMunch 7y ago
    Well it all started when I wrote the genui macros for wxNim and the Gtk wrappers. I started working on a rather simple note-taking application and had an idea in mind for what I wanted it to look like. Turns out this look wasn't possible in wxWidgets without resorting to custom widgets (because the Windows back-end didn't have support for something none of the others could support it). So I had to switch away from wxWidgets and use Gtk instead, not a huge issue for that project since I was just going to use it for personal purposes anyways, but it made me realise something. There isn't a single cross-platform UI toolkit that allows me to learn that one library and then create UIs for either all the targets, or one specific target. The idea has then gone through many revisions and back and forth on implementation ideas, but the current vision is to base it on Nims powerful type system. So instead of saying that "I want a wxTextCtrl" you say "I want to have a way of editing this string". Then it is up to the target toolkit to have an idea of how a string should be edited. Then any sort of styling of the resulting UIs are done on a per-platform basis, with whatever tools are available for that platform. This will also allow the toolkit "drivers" to take in their own UI specifications (for example Glade for Gtk) and map the types you supply to parts of the UI. Essentially separating the UI generation completely from the code/logic. The benefits of an approach like this is that for a simple UI that is only meant as a front-end for some algorithm you can just specify your inputs and actions and the UI can be automatically generated for you across platforms. If it looks weird on one platform you are able to specify for that platform what modifications to make. Or if you want to create a beautiful shiny graphical application you are able to tailor make every aspect of the UI for the target platform and then bind it back to your code. This is probably already way longer than what you expected, or even wanted, I've been thinking about this and toying around with implementations for a while now. I had an early prototype that created widgets for Gtk and Karax (Nim web front-end toolkit) that worked really well, but I hit some snags with the implementation in an earlier version of the language. Now that the language is more mature, and I'm more used to it, I might finally be able to implement it properly.

dom96 7y ago

Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :) It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work. Grab a copy here: https://manning.com/books/nim-in-action?a_aid=niminaction&a_bid=78a27e81 https://manning.com/books/nim-in-action?a_aid=niminaction&a_...

PMunch 7y ago
Not only a good resource to learn Nim, but also an excellent programming book in general!
totalperspectiv 7y ago
I can confirm, the book is excellent and worth a read-through.
sergiotapia 7y ago
Thank you, purchasing a copy now
muktabh 7y ago
I bought a copy of the book a few months back (and haven't yet found time to read it fully, I can write a lot of programs just after reading a first few chapters), will Manning upgrade it for a newer version for Nim 1.0 ?
- narimiran 7y ago
  > will Manning upgrade it for a newer version for Nim 1.0 ? The version of the book you bought (and which is still on sale) is compatible with Nim v1 and it is still relevant, no need for another version anytime soon.
ecmascript 7y ago
Aw, I missed it by a couple of hours.. :/

qaq 7y ago

Once ecosystem matures (good async db drivers) would be pretty good option for web dev

dom96 7y ago
It's already a pretty good option, the Nim forum is written 100% in Nim.

75dvtwin 7y ago

Finally, very happy for Nim and the team! version 1.0, stability, RFC process -- all are signs of maturing language and the ecosystem. Here is a curated list of frameworks for Nim https://github.com/VPashkov/awesome-nim https://github.com/VPashkov/awesome-nim For me, personally, the interest, is its javascript-as-target capabilities.

rajangdavis 7y ago

For compiling to Javascript, is it possible to use npm modules with the code?

dom96 7y ago
There is no first-party support for this, but I don't see why it shouldn't be possible. It might take quite some effort though.
curioussavage 7y ago
I know of at least one nim lib that wraps a js lib (react) you could find that and use it as an example.
SolitudeSF 7y ago
https://github.com/bluenote10/nim-electron-karax https://github.com/bluenote10/nim-electron-karax

staticassertion 7y ago

Right now I write, almost exclusively, Rust and Python. I'm really hoping I can replace a lot of the Python code with Nim some day.

_0ffh 7y ago

I've been intermittently working on my own language ("transpiled" to C) for more than three years before seriously checking out Nim in 2015, at which point I just threw my code away. It already had very nearly everything I thought I could bring to the table, and then some stuff I had never even contemplated. Go, go, Nim!

maxpert 7y ago

Congrats and Thanks Nim team. I’ve been tinkering with Nim to build a really efficient pubsub server. Something that can take heavy concurrent connections. Now I can actually build with confidence.

ilaksh 7y ago

One exciting new project using Nim: https://github.com/status-im/nim-libp2p https://github.com/status-im/nim-libp2p and also https://github.com/status-im/nimbus https://github.com/status-im/nimbus which is a lightweight Ethereum 1.0 & 2.0 client in development. If Ethereum 2.0 is really able to scale like they plan, a project like nimbus could really enable widespread use of cryptocurrency on phones.

p5a0u9l 7y ago

But why do they have to use camelCase? I don't know why it bothers me so, but I see that in a language or a repo and immediately and irrationally despise it. Is it just me?

tachyonbeam 7y ago
Camel case is extremely common, but it's funny that they use it given that the language is case insensitive: https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-it-caseunderscore-insensitive https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i... Sidenote: not a Nim user, but this seems like it could get in the way of interoperability with C (and most other languages)?
- PMunch 7y ago
  Not really, when you want to import things from C you simply name them what you like and then you can call them in a case-insensitive fashion. When writing code that should be imported into C code it will either have its name exactly as typed, or you can specify a name for it yourself.
xena 7y ago
Nim is style insensitive, so `foo_bar`, `foobar` and `fooBar` all resolve to the same symbol. However, `Foobar` won't.
hota_mazi 7y ago
More of a personal preference, but to me, typing all these underscores all the time would probably give me carpal tunnel syndrome within just a few years.
PMunch 7y ago
As other have mentioned Nim is style insensitive. This might sound odd at first, but it allows you to use snake_case in your code even though the standard library is camelCase. It also allows me to use your snake_case library in my camelCase code without ending up in mixed_Case hell like you often end up in Python.

mwcampbell 7y ago

I noticed that Araq's personal post about v1.0 mentioned a powerful macro system as a top priority. I wonder if Nim's macro system is now expressive enough that a front-end web framework like Svelte [1] could be implemented using Nim macros, as opposed to Svelte's HTML template language and custom compiler. COuld be useful for developing isomorphic web apps with something lighter than Node on the server side. [1]: https://svelte.dev/ https://svelte.dev/

leorize 7y ago
I think this is what you're looking for: https://github.com/pragmagic/karax https://github.com/pragmagic/karax
- mwcampbell 7y ago
  Not quite. Karax has a virtual DOM, and Svelte's creator argues that this is pure overhead [1]. [1]: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead

aredirect 7y ago

Congratulations Nim team! Last year I wrote a book on building applications with Nim, now I think it's the time for all of the people waited for 1.0 to pick it up https://xmonader.github.io/nimdays/ https://xmonader.github.io/nimdays/

6gvONxR4sf7o 7y ago

I love seeing new languages that do interesting things. I wish I could see what languages everyone will be using in 100 years. Or at least I'm curious what we'd see with 100 years of development towards solving today's problems (and without AI because that's not what this particular fantasy of mine is about). It's one of my favorite things to fantasize about when I run into another python bug or a write a tedious unit test that feels like I should be able to let my tools deal with for me. Super-future-dependent-haskell's type system with python's ergonomics, and fantasy-future-python's gradual typing to go fast and loose when I feel like it, and C's ability to specify exactly what I want when I need to with rust's ability to keep me from shooting myself in the foot while doing so, and zig's ability to do dead-simple compile time programming, and super-future-idris/coq's ability to write ergonomic proofs in place of many tests, and so on. Or even the futuristic fantasy one-FFI-to-rule-them-all, so I can mix and match pieces super smoothly. Every time I see an interesting new language catching on, I can't help but engage in optimistic flights of fancy about the future of programming.

DNF2 7y ago
Many of these features sound like Julialang to me.. Not certain how well they fit with Nim. In fact, I almost suspect you are hinting in that direction yourself ;)
- freyr 7y ago
  Let's not call it that.
- xyproto 7y ago
  Julia discourages Linux distros to package it. They include modified and unmodified versions of all libraries they depend on within the Julia source repository. I am not quite sure how they are planning to grow within the ecosystem that matters most for many developers.
  - DNF2 7y ago
    There's a very major revamp going on of how binary dependencies are handled. I don't know much about it, but it might possibly change this picture.

benboughton1 7y ago

I have been considering approaching a new language lately after have self learn python and more recently javascript. Where does nim sit in regards to the future of machine learning? Can we expect clones of pytorch/tensorflow? Is it a suitable language for this?

narimiran 7y ago
> Where does nim sit in regards to the future of machine learning? Can we expect clones of pytorch/tensorflow? https://github.com/fragcolor-xyz/nimtorch https://github.com/fragcolor-xyz/nimtorch
- benboughton1 7y ago
  Cheers. No harm in checking it out. That Manning book looks good.

ziotom78 7y ago

I would have never thought to live long enough to see this happening! I started using Nim in 2014, but abandoned it after a few years, frustrated by the instability of the language and what I perceived as a lack of vision. (In 2014, release 1.0 was said to be "behind the corner".) This release makes me eager to try it again. I remember that the language impressed me a lot: easy to learn, well-thought, and very fast to compile. Congratulations to the team!

tomp 7y ago

What’s Nim’s concurrency story? Since it’s compuled via C, I suspect the answer is “shitty” as in I expect it to inherit all of C’s issues with undefined behaviour, values out of thin air, and so on...

Varriount 7y ago
That's kinda jumping the gun - just because something is compiled to C, doesn't mean that it has all of the characteristics of C. That's like saying that because something is compiled to assembly, it has all the complexities and dangers of assembly. For example, take a look at Cython, CGo etc. Regarding concurrency, Nim has cross-platform thread support in the standard library. Concurrency, at least right now, is more memory safe than other languages, but also more restrictive. Each thread has its own heap, and and memory from one thread's heap cannot be referenced by another thread's heap without use of unsafe pointers. One can, however, copy memory from one heap to another. There are more abstract currency mechanisms detailed in the manual (primarily for work that is well-suited for threadpool use cases)
- tomp 7y ago
  > and memory from one thread's heap cannot be referenced by another thread's heap without use of unsafe pointers Are you sure about that? Your statement seems to conflict Nim's manual, which says > Each thread has its own (garbage collected) heap and sharing of memory is restricted to global variables. This does suggest it inherits all of C's memory (un)safety characteristics.
- dom96 7y ago
  Note that what you’re describing here is Nim’s parallelism. Nim supports concurrency via a macro-implemented async await mechanism that is very mature (it runs in production at https://forum.nim-lang.org https://forum.nim-lang.org)

peteforde 7y ago

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators, what is the philosophy driving its design, is it intended to be an eventual competitor or replacement for languages XYZ, where does it sit on the spectrum between raw assembly and MS Access, is it intended to be a "systems language" eg can you write a kernel or device driver using it, does it require a VM, is there corporate support available, how established is the developer community, are there books and courses, does it have garbage collection, is it a compiled language, is it a strongly typed language, what are the three perfect use cases, how stable is the API, what's the package management story, does it have a reasonable standard library, is there editor support for color coding and linting, what's the job market look like, is the documentation well-written, and most importantly, if we all got in the same room, would I want to hang out with the people excited about this language? The cost of learning yet another language vs actually spending your finite spare time building something (or with your loved ones, or reading, or sleeping, or making art) is insanely huge.

qpleple 7y ago
From a book linked in another comment: https://livebook.manning.com/book/nim-in-action/chapter-1/34 https://livebook.manning.com/book/nim-in-action/chapter-1/34
narimiran 7y ago
> yet another slightly different take on Rust or Go From Wikipedia article of each language: Rust: First appeared July 7, 2010; 9 years ago Go: First appeared November 10, 2009; 9 years ago Nim: First appeared 2008; 11 years ago
- lmm 7y ago
  The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand out?

ayush--s 7y ago

Great that it's here. I tried Nim around 8-9 months ago, and left it because I didn't want to work with a language that wasn't stable yet. Guess I'll give it a visit again.

narimiran 7y ago
> I didn't want to work with a language that wasn't stable yet. IME, the language was quite stable since version 0.19, which was released one year ago. But I know that people don't trust some random bloke on the internet, they want to see 1.0 before they dive in. I had the same concern when I first heard about Nim (I think at that time Nim was at v0.17).

atemerev 7y ago

Nim is a thing of beauty. It has a well-thought syntax (some consider it to be similar to Python, but it removes many Python idiosyncrasies), state of the art type system with generics, beyond state of the art macro system, excellent performance (comparable to Rust or C), and it can work as a low-level or a high-level language. It is pragmatic: you can write functional or imperative code, neither is imposed on you. There are so many beautiful hacks I enjoy (e.g. unit tests are supposed to be included in each file, all files are compiled as executables, and you can run them to run the tests). Here is a taste of what's possible: https://hookrace.net/blog/what-is-special-about-nim/ https://hookrace.net/blog/what-is-special-about-nim/

wiz21c 7y ago

Why Nim ? As someone who put a lot of efforts in some personal project and understands what it takes to build a new language, I wonder why did the Nim's authors did it in the first place ? Just for the sake of it ? To make money ? For the fun ? I'd like to know (as Nim doesn't seem to be backed by big dollars)

sheerun 7y ago
It compiles to C which compiles to everything. You don't have that with Rust or Go
jhbadger 7y ago
Basically it is a compiled language that feels like a scripting language -- typically compiled languages have so much boilerplate code -- but Nim doesn't. If you just looked at a Nim program, you might even think it is in some scripting language you haven't seen before. I see Nim and Crystal filling a similar niche -- Nim feels more like Python and Crystal more like Ruby.
- squarefoot 7y ago
  "Nim feels more like Python and Crystal more like Ruby" Agreed. To me Crystal is a bit easier to grasp because I already used Ruby a long ago, but it has the non trivial disadvantage of being bootstrapped (ie, it requires itself to compile itself) so that it is slower to port to different architectures.
nimmer 7y ago
> To make money? Not at all. Nim aims to achieve the expressiveness of Python , the speed of C, the programmability of LISP.
- zerr 7y ago
  What about kotlin-native?
  - 7y ago

guggle 7y ago

Love Nim ! Key points for me: - familiar, easy to read syntax - great performance - standalone executables / ease of deployment - easy interfacing with C and C++ code I would love to see its community grow and see more available libs.

planetis 7y ago

My reasons for using nim: - Syntax is very expressive and not restrictive or bloated (I can write clean code, almost like pseudocode, without boilerplate) - Runs fast and has type checking something that Python lacked (until recently at least) (When I was programming in python I was so frustrated that any variable could be used in a function call and no code is checked until it's used, Also 'nim c -r file' is faster than any Python program I have written) - Documentation is very good nowadays, but since code was so easy to read and in nim (whereas most python code interfaces with c) I could read and understand what the standard library functions were doing, another big plus when learning.

deleted 7y ago

[deleted]

fithisux 7y ago

While Nim is a much better python, you cannot use python modules with Nim (pushing strings to a python interpreter does not count as such), so you need some man-years to build a reasonable software collection. Haxe had another approach. Create a library and transpile it to be used with Lua/Python/ Java and other options.

narimiran 7y ago
Have you seen Nimpy[0]? It allows for a nice integration between Nim and Python. At least for the examples I have tried, it could be used in place of Cython, when there's a need for extra speed in some hot loops and similar situations. [0] https://github.com/yglukhov/nimpy https://github.com/yglukhov/nimpy
- fithisux 7y ago
  Havent't seen this. Should try.

kalekold 7y ago

The binary sizes that Nim produces are as usual misrepresented. D and C will blow it out of the water. Here's some D code: import core.stdc.stdio; extern(C) void main() { printf("Hello, World!\n"); } Compile with: $ dmd -betterC main.d $ ls -h main -rwxrwxr-x 1 user group 8.5K Sep 24 12:39 main

szemet 7y ago
I guess the examples use the default std libs, and runtimes of the languages. So in this sense your D example is the misrepresentation, by directly calling libc. If these kinds of low level size optimizations are enabled then both Nim and Rust can be more than 50 times smaller than your D example ;) : 150 byte Nim: https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/ 151 byte Rust: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...

Mikeb85 7y ago

Fantastic news. I haven't done anything too serious with Nim, but I did find for the code I did write in it, that its extremely intuitive and easy to get going. It also has all the features I could ask for in a language and it never feels like you need to work around a limitation. Of course that's the initial impression, I haven't used it as much as languages that have batteries included for the specific tasks I do (most of the programming I actually do these days is around data analysis, economic forecasting, so R is pretty hard to beat).

juststeve 7y ago

Damn, this is some solid work. Seriously impressive.