7 ms·

Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Ni

Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compared to Python, but after a few attempts (perhaps halfhearted), I never felt "Go" was a suitable replacement.

tschellenbach 9y ago
I never heard of Nim, something to try out at some point. What's your favorite Nim tutorial?
- btym 9y ago
  Nim by Example[0] is a great introduction. The blog mentioned in the OP also has a writeup that explores some of the tooling[1]. After that, the official tutorial[2] is a comprehensive dive. The standard library documentation is sometimes lacking but is easily searchable. [0]: https://nim-by-example.github.io https://nim-by-example.github.io [1]: http://howistart.org/posts/nim/1/ http://howistart.org/posts/nim/1/ [2]: https://nim-lang.org/docs/tut1.html https://nim-lang.org/docs/tut1.html
charred_toast 9y ago
Can you elaborate, somewhat? How long ago did you try GO? Also, I agree, having a generous assortment of contributed libraries makes all the difference.
btym 9y ago
Second this. I've been playing with Nim for the past couple months and love it. The biggest downside has been lack of tooling.
jamiesonbecker 9y ago
Agreed completely. We're in the process of porting our Python 'shim' (aka agent, at https://Userify.com https://Userify.com - plug SSH/sudo key management) to Nim right now, so that we can provide a fully static shim for CoreOS and other minimal distros, and eventually Windows; there are a few languages that can do this cleanly, such as Go, Ocaml, and Lua, but Nim is just blindingly fast and actually pretty fun to code in. Great stuff.
- nimmer 9y ago
  Would you kindly share you experience on using Nim for that project?
  - jamiesonbecker 9y ago
    For that project, we had very specific requirements: easily handle SSL/TLS with contexts and control over self-signed vs certificate checking, JSON processing, speed, nice syntax, and one of the most challenging requirements: statically compiled, linkable against musl and libressl, while still supporting mingw_64 for windows. Only a few languages have flexible compilers that can do this; for example, rust can't (afaik). The experience so far has been outstanding. Nim has functioned flawlessly with a minimum of magic. It seems to work very cleanly and the compiler is cleanly integrated, but still swappable (ie between gcc, clang, ming..) Nicely color-coded, too. Exceptions are caught with full tracebacks, and pre-compile checks quickly point out exact location of syntax errors. (Good, clear error messages are surprisingly missing from many languages.) Here's an awesome example; in my first day of coding, I was able to replicate python's "+" string concatenator ("hello" + "world" versus "hello" & "world" in Nim) with a one-liner: proc `+` (x, y: string): string = x & y This is pretty amazing; not only is it readable and concise (and more than a passing similarity to python's lambda, of course) but nim comes with the ability to define new operators right in the language, and the compiler raises an error if operators, procs, types, etc would introduce ambiguity. Nim compiles quickly and its type inference (where it guesses what type of variable you're working with) makes strong typing mostly painless, and you still get all of the advantages (type safety, speed) of static typing. There are some trade-offs that are made (obviously), but the language designers seem to make trade-offs in favor of speed and robustness over language features -- but this still leaves a lot of room for features. I also like how the syntax has a lot of similarities to Python's. The only thing I've missed so far is a nim interpreter, so that I can get up to speed faster on the syntax or try things out quickly. The tutorial on the Nim website is definitely not for beginning coders (who would probably be quickly scared off by words like lexical), but it quickly covers the language syntax for experienced coders and seems to borrow a lot of the best ideas from other languages. Nim is basically awesome. The few downsides are that the standard library is still pretty light (but that gives you an opportunity to build something great and have it be widely adopted), that there's no interpreter, and that the tooling is still a bit lighter than older languages. All of these will be improved with time. And, it's fast. Really fast. Compare nim in these benchmarks[1] to any other mid-level (or even low-level) language and it really shines. It's generally much faster than Go, for instance. 1. https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks
jazoom 9y ago
> High-performance garbage-collected language Compiles to C, C++ or JavaScript Produces dependency-free binaries Runs on Windows, macOS, Linux, and more Wow. That's cool. I'll have to look into this.
luord 9y ago
I also tried Go and didn't feel it was a suitable replacement either. I had never heard of Nim, I'll have to give it a try, thanks.
sjellis 9y ago
For me, the ecosystem matters as much as the language itself these days (actually more). There are languages that I've used at home just as a learning experience, but ideally, I want a language that I can put into production at work. That means quite a list of criteria: only a small number of languages have a well-supported AWS SDK, for example. I won't say that Go is mainstream yet, but it feels very "production-ready" in those respects.
- oblio 9y ago
  I'd say that simplest "production-ready" criterion is this: does it have an officially supported and stable release of a IntelliJ IDE (there is a slight Java-ecosystem bias, but I think it's only slight). So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET (source: https://www.jetbrains.com/products.html https://www.jetbrains.com/products.html). Sounds about right :)
  - majewsky 9y ago
    So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and any type of shell script is not production-ready. Nice to have that clarified. :P
    - gbersac 9y ago
      They may be production ready, but have a quite small ecosystem compared to other languages mentioned.
      - oblio 9y ago
        Or there's not that many greenfield projects in any of them, for those that have managed to acquire the ecosystem years ago.
      - saghm 9y ago
        Do shell and Perl really have a "small ecosystem" compared to something like Groovy?
reacharavindh 9y ago
Thanks for your comment here. I heard of Him from you here. It genuinely looks like the best of many worlds. Easy to use and learn like Python: Check Fast and efficient approaching the levels of C: Check Ability to spit out a binary that just works without installing all the batteries: Check (particularly hurt by this in Python) Uses multiple cores by default : Check I'm going to spend a good deal of time playing with this and building some CLI tools at work.
eeZah7Ux 9y ago
+1 for Nim: it writes like Python and runs like C.
mac01021 9y ago
> Since then, Nim has been my go-to language of choice. Out of curiosity: You use Nim professionally? Do you work for a company? What kind of software do you make? And what sort of people or organizations are your customers?
tempVariable 9y ago
I tried Nim in non commercial capacity and liked it. Wrote an Aho-corasick string matching algorithm in it to see how it fared with Lua/Luajit and it was fairly close in speed. The code was also quite pleasant to write. I remember that debugging it was a bit of a pain if just not a real option then. Maybe things have changed.
- sp33der89 9y ago
  This could help! https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html https://nim-lang.org/blog/2017/10/02/documenting-profiling-a...
jokoon 9y ago
There is a huge need for python to be compiled or made faster. I wonder if python 4 could make this happen.
- faceplanted 9y ago
  Pypy exists.
koffiezet 9y ago
I use both Go and Python regularly, and both have their uses and issues. Go for me is a rather simple tool that doesn't get in my way, and just lets you do stuff - on it's own it's relatively boring. While it's probably not everyone's cup of tea, I like it's simplicity. It does have some downsides the article here mentions like package management and versioning. I understand why vendoring is being pushed as 'the official solution', but it still feels backwards to me. The thing that eventually makes me grab Go time and time again is how damn easy it is to drop into code of some library - even (and maybe especially) the standard library, something I rarely did or do in any other language. With Go there's little friction to do this, for multiple reasons. The source of truth for pretty much any project is almost exclusively Github, godoc.org documentation has links directly into the source-code for every single function and struct, and it forces you to set up a dev env that let's you understand it's structuring, where your libraries and it's code will end up. About the last part I had some mixed feelings at first, but after a while you appreciate it that the libraries you're using aren't tucked away somewhere in some system directory. Add to that that Go is a simple, pretty readable language, and you end up with a very transparent library system. Would I ever even think about jumping into the paramiko library (which I used on multiple occasions)? Not at all, so I didn't. The first time I used the crypto/ssh lib, I also didn't think about jumping into the code, but somehow, I did because it was the natural thing to do, and made me understand the internals and SSH a lot better (paramiko was slightly easier to get started with though). Another thing I really like is that the language encourages not writing 'applications' but rather libraries that can be reused by virtually anyone, and your final application will be a relatively small front-end shim for it. While this is not hard in Python, creating a separate library for smaller stuff somehow always felt as overhead, while in Go it feels like the natural thing to do. In python, there's yet another ton of overhead if you want to add something to PyPI - while in Go it's a `git push` away. This also creates serious issues and pitfalls, but it makes contributing a library a lot easier.
- baq 9y ago
  > In python, there's yet another ton of overhead if you want to add something to PyPI - while in Go it's a `git push` away. note that it is possible to pip install from git repos and it's actually very easy. you're just not expected to have to do that :)

tschellenbach 9y ago

I never heard of Nim, something to try out at some point. What's your favorite Nim tutorial?

btym 9y ago
Nim by Example[0] is a great introduction. The blog mentioned in the OP also has a writeup that explores some of the tooling[1]. After that, the official tutorial[2] is a comprehensive dive. The standard library documentation is sometimes lacking but is easily searchable. [0]: https://nim-by-example.github.io https://nim-by-example.github.io [1]: http://howistart.org/posts/nim/1/ http://howistart.org/posts/nim/1/ [2]: https://nim-lang.org/docs/tut1.html https://nim-lang.org/docs/tut1.html

charred_toast 9y ago

Can you elaborate, somewhat? How long ago did you try GO? Also, I agree, having a generous assortment of contributed libraries makes all the difference.

btym 9y ago

Second this. I've been playing with Nim for the past couple months and love it. The biggest downside has been lack of tooling.

jamiesonbecker 9y ago

Agreed completely. We're in the process of porting our Python 'shim' (aka agent, at https://Userify.com https://Userify.com - plug SSH/sudo key management) to Nim right now, so that we can provide a fully static shim for CoreOS and other minimal distros, and eventually Windows; there are a few languages that can do this cleanly, such as Go, Ocaml, and Lua, but Nim is just blindingly fast and actually pretty fun to code in. Great stuff.

nimmer 9y ago
Would you kindly share you experience on using Nim for that project?
- jamiesonbecker 9y ago
  For that project, we had very specific requirements: easily handle SSL/TLS with contexts and control over self-signed vs certificate checking, JSON processing, speed, nice syntax, and one of the most challenging requirements: statically compiled, linkable against musl and libressl, while still supporting mingw_64 for windows. Only a few languages have flexible compilers that can do this; for example, rust can't (afaik). The experience so far has been outstanding. Nim has functioned flawlessly with a minimum of magic. It seems to work very cleanly and the compiler is cleanly integrated, but still swappable (ie between gcc, clang, ming..) Nicely color-coded, too. Exceptions are caught with full tracebacks, and pre-compile checks quickly point out exact location of syntax errors. (Good, clear error messages are surprisingly missing from many languages.) Here's an awesome example; in my first day of coding, I was able to replicate python's "+" string concatenator ("hello" + "world" versus "hello" & "world" in Nim) with a one-liner: proc `+` (x, y: string): string = x & y This is pretty amazing; not only is it readable and concise (and more than a passing similarity to python's lambda, of course) but nim comes with the ability to define new operators right in the language, and the compiler raises an error if operators, procs, types, etc would introduce ambiguity. Nim compiles quickly and its type inference (where it guesses what type of variable you're working with) makes strong typing mostly painless, and you still get all of the advantages (type safety, speed) of static typing. There are some trade-offs that are made (obviously), but the language designers seem to make trade-offs in favor of speed and robustness over language features -- but this still leaves a lot of room for features. I also like how the syntax has a lot of similarities to Python's. The only thing I've missed so far is a nim interpreter, so that I can get up to speed faster on the syntax or try things out quickly. The tutorial on the Nim website is definitely not for beginning coders (who would probably be quickly scared off by words like lexical), but it quickly covers the language syntax for experienced coders and seems to borrow a lot of the best ideas from other languages. Nim is basically awesome. The few downsides are that the standard library is still pretty light (but that gives you an opportunity to build something great and have it be widely adopted), that there's no interpreter, and that the tooling is still a bit lighter than older languages. All of these will be improved with time. And, it's fast. Really fast. Compare nim in these benchmarks[1] to any other mid-level (or even low-level) language and it really shines. It's generally much faster than Go, for instance. 1. https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks

jazoom 9y ago

> High-performance garbage-collected language Compiles to C, C++ or JavaScript Produces dependency-free binaries Runs on Windows, macOS, Linux, and more Wow. That's cool. I'll have to look into this.

luord 9y ago

I also tried Go and didn't feel it was a suitable replacement either. I had never heard of Nim, I'll have to give it a try, thanks.

sjellis 9y ago

For me, the ecosystem matters as much as the language itself these days (actually more). There are languages that I've used at home just as a learning experience, but ideally, I want a language that I can put into production at work. That means quite a list of criteria: only a small number of languages have a well-supported AWS SDK, for example. I won't say that Go is mainstream yet, but it feels very "production-ready" in those respects.

oblio 9y ago
I'd say that simplest "production-ready" criterion is this: does it have an officially supported and stable release of a IntelliJ IDE (there is a slight Java-ecosystem bias, but I think it's only slight). So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET (source: https://www.jetbrains.com/products.html https://www.jetbrains.com/products.html). Sounds about right :)
- majewsky 9y ago
  So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and any type of shell script is not production-ready. Nice to have that clarified. :P
  - gbersac 9y ago
    They may be production ready, but have a quite small ecosystem compared to other languages mentioned.
    - oblio 9y ago
      Or there's not that many greenfield projects in any of them, for those that have managed to acquire the ecosystem years ago.
    - saghm 9y ago
      Do shell and Perl really have a "small ecosystem" compared to something like Groovy?

reacharavindh 9y ago

Thanks for your comment here. I heard of Him from you here. It genuinely looks like the best of many worlds. Easy to use and learn like Python: Check Fast and efficient approaching the levels of C: Check Ability to spit out a binary that just works without installing all the batteries: Check (particularly hurt by this in Python) Uses multiple cores by default : Check I'm going to spend a good deal of time playing with this and building some CLI tools at work.

eeZah7Ux 9y ago

+1 for Nim: it writes like Python and runs like C.

mac01021 9y ago

> Since then, Nim has been my go-to language of choice. Out of curiosity: You use Nim professionally? Do you work for a company? What kind of software do you make? And what sort of people or organizations are your customers?

tempVariable 9y ago

I tried Nim in non commercial capacity and liked it. Wrote an Aho-corasick string matching algorithm in it to see how it fared with Lua/Luajit and it was fairly close in speed. The code was also quite pleasant to write. I remember that debugging it was a bit of a pain if just not a real option then. Maybe things have changed.

sp33der89 9y ago
This could help! https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html https://nim-lang.org/blog/2017/10/02/documenting-profiling-a...

jokoon 9y ago

There is a huge need for python to be compiled or made faster. I wonder if python 4 could make this happen.

faceplanted 9y ago
Pypy exists.

koffiezet 9y ago

I use both Go and Python regularly, and both have their uses and issues. Go for me is a rather simple tool that doesn't get in my way, and just lets you do stuff - on it's own it's relatively boring. While it's probably not everyone's cup of tea, I like it's simplicity. It does have some downsides the article here mentions like package management and versioning. I understand why vendoring is being pushed as 'the official solution', but it still feels backwards to me. The thing that eventually makes me grab Go time and time again is how damn easy it is to drop into code of some library - even (and maybe especially) the standard library, something I rarely did or do in any other language. With Go there's little friction to do this, for multiple reasons. The source of truth for pretty much any project is almost exclusively Github, godoc.org documentation has links directly into the source-code for every single function and struct, and it forces you to set up a dev env that let's you understand it's structuring, where your libraries and it's code will end up. About the last part I had some mixed feelings at first, but after a while you appreciate it that the libraries you're using aren't tucked away somewhere in some system directory. Add to that that Go is a simple, pretty readable language, and you end up with a very transparent library system. Would I ever even think about jumping into the paramiko library (which I used on multiple occasions)? Not at all, so I didn't. The first time I used the crypto/ssh lib, I also didn't think about jumping into the code, but somehow, I did because it was the natural thing to do, and made me understand the internals and SSH a lot better (paramiko was slightly easier to get started with though). Another thing I really like is that the language encourages not writing 'applications' but rather libraries that can be reused by virtually anyone, and your final application will be a relatively small front-end shim for it. While this is not hard in Python, creating a separate library for smaller stuff somehow always felt as overhead, while in Go it feels like the natural thing to do. In python, there's yet another ton of overhead if you want to add something to PyPI - while in Go it's a `git push` away. This also creates serious issues and pitfalls, but it makes contributing a library a lot easier.

baq 9y ago
> In python, there's yet another ton of overhead if you want to add something to PyPI - while in Go it's a `git push` away. note that it is possible to pip install from git repos and it's actually very easy. you're just not expected to have to do that :)