Nim 0.20.0 (1.0 RC1) released

https://nim-lang.org/blog/2019/06/06/version-0200-released.html

by def- • 7 years ago

132 119 7 years ago

aredirect2• 7 years ago

It's impressive. 1000 commits! Great job Nim team!

dgllghr• 7 years ago

Last I heard, nim was planning on removing the garbage collector and replacing it with a lifetime system, but I don't see anything about that in the release notes. Does that mean that 1.0 of nim will include a garbage collector?

throwmeaway1015• 7 years ago

Links for anybody who doesn't know what is being talked about here, https://github.com/nim-lang/Nim/wiki/Destructors,-2nd-editio... and https://github.com/nim-lang/RFCs/issues/144 describes the specification for those changes.

The plan AFAIK is to ship it with v1 but it would not be default and you would need to do `--newruntime` for using these features. As they stabilize over time and things get ported to this new runtime, it would be made the default.

sprash• 7 years ago

Once NIM is stable it will be superior to Python in every measurable way. Is there any reason to stay with Python for new projects that don't depend on a particular Python library?

def-• 7 years ago

Python has a huge ecosystem of great libraries and is stable right now, no "once" required. In Python you can also write performance critical code in C as the standard library often does.

oblio2• 7 years ago

In Python you can also write performance critical code in C as the standard library often does.

As a sloth I can become a horse to run fast.

I like Python, but let's not take an obvious weakness and try to present it as a strength. In the modern programming language landscape where you can get expressive and fast, Python is still slow.

treeform3• 7 years ago

Huge ecosystem also have issues. Your are tempted to use a library when a simple 100 line "replacement" that just does what you want will do.

I think the biggest problem in programming we have right now is people using libraries upon libraries not knowing how they work and drowning in complexity.

Huge ecosystems are almost like bureaucracies that eat productivity in their wake. They fool you into thinking they add value when instead they take it away.

throwmeaway1015• 7 years ago

The main reason people prefer python is because of the vast ecosystem. Hopefully Nim will reach there someday.

Anyways for a lot of things Nim is pretty good actually and I would recommend people to atleast try it.

luhego• 7 years ago

When talking about programming languages, technically superiority is not correlated with popularity. Using Python means that if in the future I need to do data analysis I can use pandas, matplotlib, etc. If I need a web framework I could use Django, Flask, etc. NIM needs more packages in order to be considered.

Thaxll6• 7 years ago

Superior? You mean a language without community or ecosystem and pretty much not used by anyone.

linsomniac2• 7 years ago

It seems to me that the benefits of Nim over Python are far smaller than the benefits of Python's library ecosystem.

I'm pretty happy with Python though. It seems like Nim's benefits couldn't be that big. I consider Python "great", so the best Nim could be is "great-er", as a core language I mean. I've been rooting for Nim, but haven't actually tried it. And my use case is pretty small, I admit.

throwmeaway1015• 7 years ago

The benefits of Nim over Python are not at the ecosystem level yet, it is at the language level. Nim is not exactly related to Python as TypeScript is to JS.

Nim provides a lot of features like compile-time execution, macros, c/c++/js/obj-c interop, upcoming newruntime, dependency free executable, better performance and lower memory overhead in general (obviously people can write bad code), etc.

So if any of these features matter to you, you should give it a try.

jononor• 7 years ago

Availability of packages, tooling, established best practices and skilled developers is just as important as the language itself.

Unfortunately that can be somewhat of a chicken and egg problem for new languages.

teamski• 7 years ago

OT: I am huge fan of whitespace-sensitive languages.[0] This is alone a reason why I wish nim all the best for its future!

[0] If a language is not whitespace-sensitive I prefer curly brackets as block markers.

linsomniac2• 7 years ago

Shields up!

monetus• 7 years ago

WooHoo! I'm very excited about this. For me, nim has been the perfect glue language in many ways. I hope other people will give it a shot, try out the https://forum.nim-lang.org or their subreddit https://old.reddit.com/r/nim

dickeytk7• 7 years ago

Forgive me while I make some gross generalizations:

  Objective-C -> Swift
  Python -> Nim
  Ruby -> Crystal
  JavaScript -> Elm—or maybe TypeScript?
  C/C++ -> Rust

The future looks good.

oblio2• 7 years ago

Java -> Kotlin (or even modern Java)

JavaScript -> Typescript

C# -> F# (or even modern C#)

pjmlp3• 7 years ago

I would stick with the modern variants from Java, JavaScript and C# until the underlying platforms get rewritten in the guest languages.

perryprog• 7 years ago

Don't forget Julia for Python and data science!

(Obviously also a huge generalization :))

kelp2• 7 years ago

Java -> Go?

Not so much in the language design inspired by sense, but I see a lot of Go being used in places that were previously Java.

K8s was originally written in Java.

Personally very happy to operate fewer Java services...

dickeytk7• 7 years ago

I've seen more Ruby -> Go and Python -> Go myself. I think Go is just pretty well suited to breaking up large monoliths into microservices which is common across the industry.

pjmlp3• 7 years ago

That is a step backwards.

Java 12 -> Go aka Java 1.4

throwmeaway1015• 7 years ago

It isn't exactly accurate. Rust is more like c++ and Nim is more like python+c+pascal. But yeah "The future looks good."

agumonkey3• 7 years ago

and obviously

    haskell -> haskell

galfarragem• 7 years ago

And AFAIK: Clojure -> Clojure

kibwen3• 7 years ago

I don't know if I'd compare Nim to Python precisely; aside from the significant whitespace, I'd say Nim's syntax is directly descended from Pascal, and Nim's philosophy appears to hew more towards TIMTOWTDI than TSBOAPOOOWTDI (although I suppose we could debate whether modern Python still adheres all that closely to the latter). As a result it might appeal more to Rubyists.

dickeytk7• 7 years ago

From the nim homepage:

It combines successful concepts from mature languages like Python, Ada and Modula.

Thaxll6• 7 years ago

Python, Ruby -> Go. Nim and Crystal are pet project compare to other languages, no support, no community, no libraries, Crystal doesn't even supports Windows or threads. They are in pre alpha stage at best.

dickeytk7• 7 years ago

hence why I said the word "future"

stevejohnson• 7 years ago

I found Nim to have a small but active and supportive community. The library ecosystem, while a little thin, has a lot of activity, and I was able to find what I needed or create wrappers for C libraries.

One difference between the Swift and Nim communities is that where Swift's is full of noobs answering each other's questions, Nim's is full of experts who are just as eager to help.

Nim also has pretty good, fairly complete docs and a decent book.

gtrs• 7 years ago

It's not like you can contact Google and get support for Go. The Nim community might be smaller but you still get help if you ask.

kaushalmodi• 7 years ago

no support, no community, no libraries

That's grossly incorrect about Nim. I'm a C/C++ noob and I've found a lot of C/C++/Nim/CS experts answering my questions and helping me out on Nim IRC/Gitter/Nim Forums.

Recent (as recent as few hours ago) proof: https://forum.nim-lang.org/t/4912

flohofwoe2• 7 years ago

C++ -> Rust

...is correct, but

C -> Rust

...is not IMHO. There needs to be a much smaller, simpler, "better C" language than Rust to replace C. Something like zig, or C2, even C99 almost feels like a new language.

PS: ...and I forgot the fairly obvious C -> Go :)

dickeytk7• 7 years ago

I'm not familiar with the C-family languages, but given that Go is GC, wouldn't Rust be a better "C 2.0"?

e12e• 7 years ago

There's always "D as better C".

pcwalton• 7 years ago

I'm not convinced you can be much simpler than Rust while maintaining memory safety without GC (including reference counting) while still having standard heap allocation and deallocation. If you throw out memory safety, then sure, you can be simpler.

wuschel• 7 years ago

Did anyone have experiences with ATS lang [1] as C replacement?

[1] http://www.ats-lang.org/

svnpenn5• 7 years ago

I like Zig, but it doesnt even have a HTTP client yet:

https://github.com/ziglang/zig/issues/2007

granted neither does C, but C has cURL, and Zig doesnt (and wont) have cURL binding:

https://github.com/ziglang/zig/issues/2056

haolez3• 7 years ago

C -> Zig

PMunch3• 7 years ago

Don't forget that Nim can compile down to JavaScript as well :) So you can actually use Nim to create your JS frontend and your C-compiled back-end.

treeform3• 7 years ago

This is what it is for me:

  Objective-C -> Nim (can compile to ObjC, calls methods directly without overhead)
  Python -> Nim (Nim is a super fast python that prevents typos)
  Ruby -> Nim (Nim is better in every-way)
  JavaScript -> Nim (compiles to plain JS (if you need talk to legacy JS libs like most people) or WASM (if you just want speed))
  C/C++ -> Nim (Can compile to C++, calls methods directly without overhead)

Basically...

TeddyDD• 7 years ago

Yeah, Nim has impressive coverage of targets. I dislike almost everything about Nim: the syntax, complexity, weird case insensitivity, documentation, community, package manager...Yet this trait alone makes Nim worth leaning for me.

mikenew• 7 years ago

Nim generates native dependency-free executables, not dependent on a virtual machine, which are small and allow easy redistribution.

That's... awesome. I've written a handful of little tools and scripts in Python for different (often non-technical) clients to use, but I've never found an easy way to package them up as a "click this icon to run the program" type of thing. If that's a solved problem with Nim I'm pretty much already sold.

svnpenn5• 7 years ago

It does do that. The only issue you might have is library support, but I have found it to be pretty good. For example Nim has had async HTTP client for a while now, while even Rust is just now getting it.

https://nim-lang.github.io/Nim/httpclient

https://github.com/nim-lang/Nim/commit/783087fd

Thaxll6• 7 years ago

The async lib doesn't supports timeout, meaning not usable in production or any serious workload.

sametmax• 7 years ago

Nuitka (nuitka.net) does that for python, and is very robust and compatible. It works way better than py2exe, cx_freeze, etx, and is cross platform.

However, the result, even for small scripts, is not what I would qualify as "small" :)

I also like pex (https://github.com/pantsbuild/pex) which allows to bundle a whole venv as a python script. Less heavy than nuitka, doesn't make it stand alone though, but very handy for quick and dirty scripts I want to one shot on my servers.

That doesn't remove any merit to nim. Such a cool project.

Rotareti• 7 years ago

Nuitka also improves performance. It has halved the startup time for a command line tool that I wrote.

vram224• 7 years ago

Nuitka (nuitka.net) does that for python, and is very robust and compatible. It works way better than py2exe, cx_freeze, etx, and is cross platform. However, the result, even for small scripts, is not what I would qualify as "small" :)

How does Nuitka compare for generated executable sizes with PyInstaller? I've used the latter. For small Python scripts, CLI or wxPython, it created EXEs (Windows) in the range of 10 MB in size - with the all-code-in-one-file option.

PMunch3• 7 years ago

As someone who usually develops in Nim but is now stuck with delivering some Python scripts that runs embedded in a C program I feel your pain.. The first time I had to deploy some Nim code and could just copy a single binary to the target machine and run it was such a good feeling!

PhilippGille• 7 years ago

Go might be suited for you as well and it has a bigger ecosystem.

iuuuuu• 7 years ago

Nim supports dynamic libraries as well and that is very important for security.

goodpoint2• 7 years ago

A simple tarball would do, or a package or an installer.

amscotti• 7 years ago

If anyone is looking to learn Nim, Exercism.io has a Nim track with a good number of exercises.

https://exercism.io/tracks/nim

Shoop2• 7 years ago

The undocumented #? strongSpaces parsing mode has been removed.

I remember seeing lots of controversy over this feature a previous time Nim was posted here. Hopefully, its removal will stop people from dismissing the language outright (which would be a shame given all the things Nim has going for it).

(That being said, if people still want to embrace Wadler's Law [0], there's the hot-button topic of case/underscore insensitivity to talk about. [1])

[0] https://wiki.haskell.org/Wadler%27s_Law [1] https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i...

dickeytk7• 7 years ago

It took me a minute to understand what strongSpaces meant [0] but yikes! That looks like a terrible thing! One question though, what is #? strongSpaces vs #! strongSpaces?

[0] https://nim-lang.org/0.11.0/manual.html#syntax-strong-spaces

Shoop2• 7 years ago

I believe that's the syntax for enabling a parsing mode. I think it just changed from #! to #? (to allow a nim bash shebang).

Obviously, the yikes is gone now. It was always an experimental feature, so IMO the fear of it was overblown, but it is a pretty scary idea for a feature.

contras19703• 7 years ago

well, these two things (strongSpaces couldn't have been "undocumented": i knew about it from a cursory glance at the language a few years ago, never wrote more than a hello world in it) made me shy away from the language. i mean, it's niche and all, that does not help, but those two things did decide which way the scales went.

re [0]: whether FUBAR and f_u_b_a_r mean the same thing or not is a matter of semantics, not syntax (it's in the name: "meaning").

re [1]: i use zsh where setopt errexit and setopt e_rR_EX_it mean the same thing, and it's really annoying. all it does is complicate search in man pages and code, i'd say this feature has negative value. e_rR_EX_it is extreme, but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!

i think the arguments in [1] are weak, unsubstantiated, and admissions of negative value.

dom968• 7 years ago

but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!

It sounds to me like this is a problem with your search tool, if it would search in a style insensitive manner then this wouldn't be a problem, you'd find both.

vram224• 7 years ago

Haven't tried it myself, but have read about nimgrep in previous HN nim threads. Just checked:

https://nim-lang.org/docs/nimgrep.html

Excerpt:

Nimgrep is a command line tool for search&replace tasks. It can search for regex or peg patterns and can search whole directories at once. User confirmation for every single replace operation can be requested. Nimgrep has particularly good support for Nim's eccentric style insensitivity. Apart from that it is a generic text manipulation tool.

treeform3• 7 years ago

Nim is a super fast python that also prevents typos.

I use nim everyday. 98% of my programming is in nim only. I highly recommend nim. During the day I work mostly on internal tools and dashboards, during the night I work on games. Nim compiles to JS and C. Its really good.

new4thaccount2• 7 years ago

Any way you could go into more detail on your work and how your apps are setup. I'm guessing your Nim code transpiles the dashboard code to JS and the backend to C?

kuon• 7 years ago

I usually use lua to script my C apps (games, embedded projects), but I might give nim a go for my next project.

kbd• 7 years ago

I'm excited/hopeful about Nim's prospects. The list of "high level languages with garbage collection and exceptions that compile down to an efficient native binary" is very small.

nepeckman• 7 years ago

I've been full steam on the Nim train for the past year. It really hits a sweet spot between semantic complexity and language power. If you've used any mainstream language and understand types, you already understand 80% of the semantics you need to be productive. But more advanced features (generics, algebraic data types, hygienic macros) are available when needed. Now that the language is approaching 1.0, the only caveat is a small ecosystem and community. Nim has completely replaced Node as my language of choice for side projects and prototyping.

karmakaze• 7 years ago

Kinda exciting and sad. We don't know now what we'll later regret having committed to.

haolez3• 7 years ago

What's the current async/await story on Nim? I'm considering it for a new project.

dom968• 7 years ago

The story is that it's used in production and works quite well (but I am pretty biased as I developed most of it). If you want some examples take a look at my book[1] which includes a whole chapter where you build a chat app using Nim's async/await. The code for this is freely available[2].

1 - https://book.picheta.me/

2 - https://github.com/dom96/nim-in-action-code

haolez3• 7 years ago

Great! Congratulations!

I’ve been bitten by Python in this area a few times and I was looking for a statically typed alternative for a while. Nim seems to fit the bill.

The obvious choice would be Go, but the learning curve for my mostly Python-based shop seems higher and Nim looks cooler :)

eptcyka• 7 years ago

https://github.com/dom96/nim-in-action-code/blob/master/Chap...

Does the linked line imply that a slow client will block the rest of the clients from receiving new messages?

Nim 0.20.0 (1.0 RC1) released

Related Stories