Nim imports are great. I would hate to qualify everything. It feels so bureaucratic when going back to other languages. They never cause me issues and largely transparent. Best feature.
Thank you for working on the Nim Compiler. This is great. Another great release. The Nim Compiler continues to move forward.
Thank you very much to everyone who has contributed to the development of this superior language. Nim Compiler continues to be one of the most wonderful languages I have worked with. With the speed of C and the simplicity of Python, it has allowed me to write a lot of cool software.
I do not know where I would be if Nim did not exist in my life.
Not the OP, but as an individual who has programmed in Nim on and off for a decade, I feel qualified to answer. The similarities are definitely only skin-deep, and Nim is just as complex, if not more complex than Python.
Nim is much closer to Pascal / Modula / Oberon than Python. The whole - ease/simplicity of Python and speed of C is mostly marketing jargon that the Nim community has been using as long as I've been aware of the project.
In practice, it means that unlike most native-compiled languages, if you want a data-oriented approach without having to worry about system details at all, you can do that. Your program will still be strongly typed, but you're not obligated to worry about allocation, reference vs value semantics, ownership, or initialization details. For programs that shouldn't have to worry about those details, the Nim team has done a lot of work to make sure the language gets out of the way and lets you process data. Then, you get a fast binary comparable to the results you'd get from C++ (with a lot more effort).
In buzzword-speak, it's easy to write programs composed of nearly pure business logic while getting C++-level performance.
How do you find a simple language with abstraction? Pretty much all the "complexity" of the language is juggling its abstraction overhead. Whether that's Haskell's monad transformer stacks or Rust's Send + Sync.
Given the space it's tackling I think Nim is a great effort and refreshing as it keeps a Python like syntax with a Pascal-like feel, which I feel is an underexplored evolution of languages.
Abstraction overhead is very much worth it for non-trivial programs. The "simpler" syntax of languages like Python is a one-time initial gain (and even then, it really only "saves" a tiny bit of boilerplate) that ultimately turns into a big drawback as programs grow more complex and your abstraction possibilities are severely limited due to an overly simplistic initial approach to the code.
This sounds to me like you don't like Python's syntax and abstraction model more than anything else. Which is fine, there's plenty of languages out there.
I find that python has this simplicity other languages lack. Nim has it too. It's hard to strictly define it? Its a bit syntax, a bit lists or dicts, batteries included? A bit how you run it. Maybe a culture of straightforward code - at least in the python 2.x days. Maybe its just you write an algorithm and its easy to follow?
I've used Nim a bit, though it's been a while. I've been primarily a Python developer for the past 20 years, with a sprinkling of other languages and paradigms - including languages like Scala and Haskell, so not just OOP stuff.
I characterize Nim as Python with one major difference: where Python prioritizes "developer happiness", Nim prioritized performance. As a result, the syntax looks very similar, the edges are quite a bit rougher, and performance is exponentially better.
It still "feels like" Python in a lot of ways. The ways places if differs feel a lot like Haskell IMO.
with some limitations: https://github.com/nimpylib/nimpylib/tree/master/doc/mustRew... no "end" argument in print, no triple quote and newline, no "a not in b" (write not (a in b)), no variable named _ (underscore), or double underscore, no slice as foo[:b] where the left part of the slice is not specified, rewrite foo[0:b], etc.
I feel like Nim made me fall in love with programming again.
Nim fixes many of the issues I had with Python. First, I can now make games with Nim because it’s super fast and easily interfaces with all of the high performance OS and graphics APIs. Second, typos no longer crash in production because the compiler checks everything. If it complies it runs. Finally, refactors are easy, because the compiler practically guides you through them. The cross compiling story is great you can compile to JS on the front end. You can use pytorch and numpy from Nim. You can write CUDA kernels in Nim. It can do everything.
I feel like Nim, along with C#, is one of the few languages that just cannot be used without a great IDE.
It heavily encourages namespace pollution and `import *`, making it very hard to figure out what where a given function is coming from and hence what it does.
I agree with all your points but last I tried, the VS Code LSP was terrible. It’s hard to justify a new language when even the basics of autocomplete, inline errors and go to definition don’t work well. Part of the reason was that any function can be called on anything, which pollutes the autocomplete list.
Has the LSP situation improved yet? Similar issue with Crystal lang, which I enjoy even more than Nim.
Unfortunately the LSP hasn’t improved that much. There’s been some work on to kill errant processes and such. So it’s a bit more stable. It does work pretty well when it works though. But I just kill it now.
Unfortunately it may not be until Nim 3 based on the Nimony rewrite comes out. It supports incremental compiling and caching which will make the underlying LSP tooling much better.
However I find with Cursor that I don’t mind so much the missing autocomplete. I’ve actually thought about writing an alternative LSP just for quick find and error inlining…
Frankly, I'm surprised this is the only issue you bring up (I had many, when I first tried Nim several years ago - I think they were related to cross-platform GUI libraries for Nim, or the lack of them, or their awful state back then).
But LSP as a major concern? For me these little helpers are useful to catch small typos but I could happily do without them.
It's not just small typos, it's the ability to explore apis, the standard library, go to definition, quickly catch any error at the location it happens, not having to memorize large models and their field names, the list goes on.
I can work without an LSP, but when I'm searching for a new language that would be used by a team (including Junior devs) it's hard to justify something missing the basics of good DX. I haven't tried it with Cursor though, it might be less of a dealbreaker at this point.
How do you navigate through a project with things like `go to definition` or `incoming calls`? (given that we are talking about a relatively large code base maintained by more that one or two individuals)
You can do it with just rg or something similar but it will give you many false positives and are going to waste quite some time.
That’s very interesting actually. Can you call only specially wrapped libraries from Nim, or is any Python library importable? When you cross-compile to JS can you only use pure-Nim libraries or how does that work?
It's not a built-in Nim feature, and it'll only work with native backends (C/C++/ObjC). The project that makes it possible is https://github.com/yglukhov/nimpy
>typos no longer crash in production because the compiler checks everything.
Gentle correction: Python is typed now too and you can get the benefits of typing both in your IDE (via LSP) and before deploying to production (via mypy and the like). This happens both by type inference as well as explicit type annotations.
That's the dream. Reality is very different. Mypy presents numerous false negatives and false positives. Useful to screen for some bugs, but definitely far from giving guarantees.
Not to mention, if a library does not or does sloppily use type annotations, you would not get reliability even with a perfect type checker.
Sure but you can also write bugs in a perfectly typed compiled language. Short of formal verification the best we can do is try to minimise the possible surface for errors to occur. I'm of the opinion that language and tooling plays only a small part in writing robust software. What's more important is designing software using simple components that are small enough to be obviously correct.
I'm sure you're right that there are situations where mypy or ty or LSP give false positives/negatives, but in my use of them over the last ~6 months I really haven't run into many of those situations, or at least none come to mind. Libraries without type annotations do reduce the effectiveness to just what can be inferred by the type checker.
you need to work on big project for these flaws to become a problem. Say, you have a huge code base, 100000's of lines that you didn't write. Then you want to refactor a method's name. Python can't give you any guarantee the refactoring is fully complete. Only a real typed language can do that.
I write 95% of my code in python, I love it, it's my go to language for many things. But for huge code base which I don't master, the lack of type system makes me more than nervous.
What percentage of typing features does a language need to have to be "good enough"? Because I'm gaining benefits of typed languages in Python, but responses to this thread are, literally: You aren't a programmer.
I got one recently. It has a learning curve, but it’s been really fun. It’s infinitely customizable like no other keyboard. The magnetic switches feel really good. I feel like I am in a cyberpunk novel when I use it.
If I were to set up a customized S&P500 (with some tweaks) and over time companies leave and/or are added to the index. Will those changes be reflected in my custom S&P500? In the months or years in the future will it buy or sell these new currently unknown companies?
To be fair to Nim, only Python has the huge ML ecosystem of numpy, scipy, pandas, opencv, pytorch, tensorflow, keres... Doing ML/AI style work in anything but python is really hard!
That said Nim does have the nimpy library that allows for pretty seamless interop with python. Which means you can just import PyTorch, or scipy, or opencv and use them in Nim.
for me (mobile developer) interop with python is not enough because of really poor python story on mobile devices (iOS / android) when using native modules. I think if Nim had a seamless interop with Rust or even Zig it could piggyback on those communities to get some libraries for free.
That looks interesting. Unfortunately it looks like it hasn't been updated in a while? Is that because it's complete or a lack of interest?
For example, the approach mentioned at the bottom of the README of integrating via nlvm (https://github.com/arnetheduck/nlvm) sounded great but appears to be unpursued.
that looks interesting, thanks! Did you try it if it delivers on promises? There was not any new commit since 2020 so not sure if the project is stale by now.
Things might changed but last time I checked you could easily call C function but you had to kind of export each single C function, structs etc. You couldn't just import single header file and be ready to call any function in the library. There is some pending project [0] futhark but not sure how mature it is and that still only for C libraries (instead of C++ or Rust) but maybe easy adopt for Zig - would be great nonetheless.
Most of those libraries are written in C++ or C, which Nim has excellent support for. I've used opencv c++ library with Nim. It's just that opencv is so massive it'd take a lot of work to wrap well, so I haven't yet. Some folks are working on a pure Nim pandas lib too.
I would not call std/json it "terrible in performance" probably still way faster then what you get in many other languages (like python). But yes the JSON lib I wrote is faster due to avoiding branches and allocations.
