The book is not really about algorithms, it talks about async, multithreading, with example on a building a chat app or a Wikipedia parser and a tweeter clone. So it's more web backend oriented for the practical stuff.
Obviously it also goes into Nim specific features like metaprogramming, interfacing with C and JS and the standard lib features in general.
That reminds me, I participated in a C++ contest some number of years ago in which I came out one of the prize winners. They gave me a C++ book. I opened it maybe once or twice because I already knew much of what it said.
Even though I haven't taken it out for a spin just yet, I've gotten a good impression of nim. Anybody out there who has tested that can say if my hunch is right or not?
> I've gotten a good impression of nim. Anybody out there who has tested that can say if my hunch is right or not?
I've started using Nim couple of months before last year's Advent of Code, after I've been reading about Nim both here and on Reddit.
As a Python user, I was immediately drawn to Nim's elegant syntax, which looked to me like "ok, just copy-paste my Python code, and declare some variables, and voila: 10-100x faster Python!", which is 80% true. The remaining 20% were "this works in Python, why doesn't work in Nim?" questions, which were promptly answered by the great Nim IRC community. I soon realized that those differences are what makes Nim great, and I began to really like the language.
I decided to solve AoC 2017 in both Python and Nim [0] so I could directly compare my solutions. This was a great experience for me, and I've learnt a lot.
In the past year I started using/liking Nim more and more (I have used Nim even at my work (numerical calculations, before done in Numpy)). This year I'm gonna solve AoC solely in Nim.
Thank you. That is the best answer to comparing languages I have seen by looking at your two codes. I never really thought of Nim as being that close to Python in syntax but seeing the two codes together I saw how you were able to achieve that and it was really insightful.
Last time I was going to try it, I got sidetracked reading up on rules for identifier equality, prompted by noticing that the nim package bundled its own grep (nimgrep).
Basically, Nim ignores case (except for the first character) and underscores in identifier names, so the following is a valid Nim program and all those names refer to the same variable:
var myVar = 1
my_var = 2
mYVAR = 3
echo(myVAR)
Most people wouldn't actually write code like that, but I personally found it to be a turn-off.
I feel like this is mentioned (by the people who just glance over Nim) every time there is some discussion about Nim, and IMO it is blown way out of proportion.
In my cca year and half of using Nim, I not even once had a problem with the style insensitivity.
IMO, you (general you) shouldn't use `my_foo` and `myFoo` for different things, regardless if a language allows for it or not.
I had an operating system with a parameter of a scalar process id, which in our parlance was spelled pidTarget. The documentation folk 'corrected' it in the manual to pIdTarget, which would mean a pointer to a target id.
Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler.
This is a reasonable concern, but after having used Nim for a couple of years I have never run into this as an actual issue. The benefit of being able to keep your entire program in one casing style outweighs these concerns. For that is the purpose of this style insensitivity, to allow you to use a library using snake_case in a project using camelCase and the other way around. And after having used Python with mixed case libraries I must say it is a good solution.
Now back to your concern of identifiers being read in different ways meaning different things. Once you know that this will be an issue you tend to think about it when naming your variables, and so it tends to not really be an issue. The thing is that once you get used to it you know that `pidTarget` and `pIdTarget` is the same thing, so you either relax you expectations, or you don't construct your names with this ambiguity. And besides, a "pointer to a target id" and a "scalar process id" probably don't share the same type, so the compiler should be catching that anyways if you ever used it wrong.
The big issue for me is it interferes with code search tools. I like being able to use ripgrep to find all uses of an identifier. That becomes hard with style insensitivity.
That is also a valid concern, with nimsuggest (and soon nimlsp) you will be able to easily find every instance in your editor (as well as rename them). For searching through files however nimgrep is probably your best bet, but that might break up your workflow. In my experience this hasn't been that much of an issue. Typically you write all your identifiers in the same style always, so most of the time you'll find what you need with just a simple grep.
grep -i solves the case issue, and grep/ripgrep probably _should_ have a feature to ignore _ ; in which case you will be able to use them - but until then, nimgrep will do that work.
It seems crazy to me that people are so annoyed that their libraries have different style that we have to have additional tooling to make code search simple for the end-user.
You don't _need_ additional tooling. You can get by with just searching as normal, it's not as if people's code bases are filled with random conventions or random case variations...
style insensitivity WILL lead to typos that don't get caught. Someone will change the casing somewhere. Therefore you must always search with style insensitivity in mind.
Styles are religions, including - in some organizations - the threat of excommunication if you don’t practice the one style.
I don’t know how atheistic style looks, but Nim is style agnostic - everyone can practice their religion and they all get along. C, Python, and the real world - not so much.
"Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler."
This one point is always worth considering when deciding on user-facing portions of technology.
Common lisp also ignores case (sort of..it's a little bit more complicated). I've never found it to be a problem - apart from the compiler always uppercases my symbols when it reports to me, it feels a bit like being shouted at.
It's actually easier on the hands than using `_`. As on a standard (us, uk, chinese, etc.) keyboard underscore requires a shift-press whereas minus/hyphen requires a single press. It's a small change but you'd be surprised how much of a difference it makes, given that tokens are a significant amount of all writing when programming.
Not to mention, in my opinion it's more aesthetically pleasing, but that's just me :)
Sure, Lisps allow many more characters in the identifiers, including all traditional operators (makes sense, since the "operators" are just functions and they had to be defined somehow in the first place...) You get functions named like add-message! create-response/text bytes->string/utf-8 and so on. Kebab case refers to identifiers with words separated with minus sign, like some-class-member-doing-something etc. Some infix languages borrowed this, like Dylan and LiveScript, among others.
Common Lisp actually lets you use any string for an identifier if you wrap it in pipes, though you have to be a bit careful of casing in that case. Still for so many characters on the keyboard it's not needed to wrap which is so convenient as you illustrate.
Not as common, as it clashes with using '-' for subtraction, but as that's never been a problem for Lisp, it's quite common there. Perl6 went that way, too, despite having infix syntax. But hey, it's Perl, we're used to syntactical warts.
I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix. Upper/lower case add a new dimension to name things that are related but different.
But is not a deal breaker for me. If the language doesn't let me I can use `ii` or `i2` or whatever.
> I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix.
Please notice that the first letter in Nim is case-sensitive, so `I` != `i`, and you can continue use your conventions.
And before some new comment starts bashing that, I think this is a must so you can differentiate your types, written in PascalCase, from your variables, written in camelCase.
I've never used Nim either (mostly C/Perl6/Clojure), but all I hear when this gets brought up is that I would finally be able to use a consistent style for all code I write, regardless of whether or not I personally implemented everything I'm using.
A lot of people are replying saying this isn't a big deal in practice. I believe them but I'll chime in and say this is also a dealbreaker for me.
I would love to find a language for game / engine development that's as performant as C++ and as easy to use as C# or Python, but this issue scares me. If I search for a variable using any of my existing plain text search tools, I expect to find the variable. It makes me think that this isn't a language that's meant to be used by large teams on large, long-lived codebases.
> If I search for a variable using any of my existing plain text search tools, I expect to find the variable.
I think you are over-estimating how inconsistent Nim code typically is. I have been coding in Nim for a very long time and I personally just use case insensitive search (which I use for all languages anyway).
It's easy to tell from context what the identifier will be. If the code base is snake_case then I search for `foo_bar` if not then I search for `fooBar`. I cannot remember a single time this has failed me, and even if it does then the worst case is you'll need to search for the other alternative. There is really no trouble here and I feel like a lot of people, when they see this feature, worry too much because it's so different. Please please please reconsider, I know it's a strange feature and it doesn't feel worth it, but it really isn't a problem at all.
I totally hear you that this is not a huge inconvenience in practice. Part of me is worried that it becomes more and more of a problem the bigger the project gets.
But mostly, it just seems like a really weird call to make for the language. There are real disadvantages to it -- I can't really rely on my search tools. So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important?
I don't know, it just seems like a really weird call to make, and if that's one of the first things I've learned about the language it makes me think there are probably plenty of other weird things like it.
> Part of me is worried that it becomes more and more of a problem the bigger the project gets.
But why? I personally haven't experienced this having worked in a big Nim project. I'm really curious why you think a bigger project could become burdened by this.
> There are real disadvantages to it -- I can't really rely on my search tools.
I disagree. You can rely on your search tools, as I've demonstrated in my previous reply. I feel like you're thinking of the worst case scenario and convincing yourself that it's very common. It simply isn't, people don't create crazy identifiers, why would they?
> So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important?
It's important for consistencies sake. In the real world developers prefer different conventions, so you undoubtedly run into a library which uses a convention that is different to your own. It's nice to be able to call that libraries functions in the same convention as your own.
I agree that it's not a huge advantage, which is why I created this thread on the Nim forum recently: https://forum.nim-lang.org/t/4388. My main reason to consider getting rid of it though is people like yourself who dismiss the whole language because of this small feature :(
I'd take a long, hard look at Julia if I were you.
It has a lot in common with Nim, but is backed by a much larger community. Its FFI interface for C functions is faster than...C.
If Julia doesn't fit your use case(s), Rust might also be worth a look. What worries me about Rust is that it looks to me to have an awful lot of boilerplate that detracts from readability.
The goal was to make it so library authors could write Nim in their own "style" - some prefer snake_case, others prefer camelCase, maybe PascalCase.
If you had your own preference one way or the other, you could call a library's `snake_case(foo)` function as `snakeCase(foo)` instead, and pretend that the library matched your own personal style.
Of course, this isn't very useful in practice, and makes simple things like grepping for identifiers or Googling a function that much harder. Tools for refactoring also suffer.
What's better is having a single style guide enforced by ordained tooling; e.g. PEP 8 for Python, Prettier for JavaScript, or gofmt for Go.
In a perfect world, yes. But having worked with Python I must say not all Python libraries are PEP 8, and I've more than once ended up with a strange mix of styles.
Nim on the other hand takes a different approach, don't trust anyone else to keep things the way you like it, but rather allow you to use it however you want. This means that if some inexperienced Nim programmer who didn't care to look at the NEP 1 style guide (yes Nim also has a style guide, which says Nim prefers camelCase), but nonetheless wrote an interesting library could still see his library used by others.
Something else to keep in mind is that Nim also has it's own version of gofmt in development, it's called nimpretty.
If everyone is using this tool anyway then style insensitivity will not be a problem, and for those cases where some library uses snake_case instead the code formatter will still be able to format your code completely consistently even if you're using that library. There is no way that gofmt or any other language's code formatter can do that.
Even if somebody deviates from a style guide, the library is still usable. The consumer might just need to use a casing convention they're not using elsewhere.
This is such an incredibly small inconvenience, I have no idea why the Nim language would choose to make identifiers case/_ insensitive. Basic refactoring tools become unnecessarily more complicated.
Just searching for an identifier is a complex regex instead of what should just be ctrl+f.
Nim's roots are firmly in Pascal and Ada, which are both case insensitive; Every editor supports case insensitive search so I don't understand what your problem is with case insensitive identifiers.
"Basic refactoring tools" would just need to replace the case sensitive search with insensitive. Every editor knows how to do that.
If you're talking about the underscore and first letter rules - yes, they're different, and that's why nim includes nimgrep, and support was added for just about every editor under the sun already (Emacs, VSCode, Vim, Sublime, TextMate at the very least). It's still Ctrl+F
I find it a big nuisance to use different casings in my code, but obviously people are different. Most of the type you won't be using the style insensitivity though, so for the most part a simple case-sensitive search will give you exactly what you are expecting. For more complicated things though you have nimgrep, and also nimsuggest (and soon nimlsp) which gives you editor support for finding and renaming identifiers. It really is a much smaller issue than people think it is.
> The goal was to make it so library authors could write Nim in their own "style" - some prefer snake_case, others prefer camelCase, maybe PascalCase.
That's something that would have appealed to me years ago, but now not so much.
In 2018, I want all the libraries, and all the code I ever look at in a language to follow the same style and naming conventions. If you adapt yourself to that, my belief is that will aid comprehension in the long term.
So I appreciate the language communities which have strong conventions which are followed by the majority, and are encouraged / enforced by the tooling. All hail gofmt and rustfmt!
> Last time I was going to try it, I got sidetracked reading up on rules for identifier equality
It's way too easy to ignore (or even embrace) the identifier equality rules in Nim to make this the hill you die on. My story's very similar to other responses - I've been using Nim for quite a while and these identifier rules have never been an issue.
I strongly suggest anyone hung up on this monster under the bed try Nim anyway as it's really pleasant to use. It's sad that all Nim's benefits are sometimes drowned by mostly unfounded hangups on this identifier thing.
Considering how common it seems to be, it wouldn't be fair to call it "unfounded".
Anyway, don't worry: I didn't die on that hill. I've had the opportunity to spend some more time on Nim since.
There was a set amount of time available to spend on Nim at that point, and all that time went into finding out why nimgrep exists in the first place, then reading up on the background.
It didn't help that all nimgrep's documentation had to say on the matter was "Nimgrep has particularly good support for Nim's eccentric style insensitivity", which doesn't really tell you anything unless you already know about Nim's style insensitivity.
I personally think it's a great idea. Much better than having a code base with mixed camelCase and snake_case because a library didn't follow the language convention.
I've seen people write wrappers just to fix casing.
Interop with C/JS: you can't control all identifiers, because you can reuse a rich ecosystem of other language libs: you can't force their names to change
EDIT: you can still change them in importc pragmas, but this still seems less nice to me.
Still, you can reuse Nim libs even if they don't follow nep1: one can still use nimpretty/gofmt for his own codebase.
Nim is actually great. The syntax is streamlined and you can pick it up in a few hours if you have some basic experience with python.
Because it's effectively a transpiler and it's way less opinionated than (say) Rust, I managed to use nim in embedded controllers without any special support from the compiler.
Nim suffers because it doesn't have the big push of a corporation such as Mozilla behind.
" A source-to-source compiler translates between programming languages that operate at approximately the same level of abstraction, while a traditional compiler translates from a higher level programming language to a lower level programming language."
In other words, Nim is not a transpiler, it's a compiler that outputs C or Javascript. But the difference is just in terms of the readability and modifiability of the output. For the purpose of using it in embedded controllers, the difference doesn't matter, it's the fact that it generates C code that is of value. And yes, Nim is vastly less "opinionated" than Rust, thank goodness.
It depends on whether the C code generated by Nim is at the same abstraction level as the Nim source code ... clearly that's not the case, because Nim is using C as an assembly language. People acting in bad faith can down vote me all they want (I know that wasn't you, Dominik; you're a great guy) but that's what "transpiler" means. Coffeescript is a transpiler; Nim is not at all ... it does a vastly more complex transformation of the Nim source in order to generate that C code ... as you, Dominik, are especially well aware.
And there are people who will disagree about just about anything, because they are ill informed or have poor judgment or are dishonest (looking at you, White House) ... the mere fact that there are people who disagree about something is not of significance.
> I know that wasn't you, Dominik; you're a great guy
Of course not :)
Yeah, to me Nim is a compiler. However, I can see why people might refer to it as "transpilation" if we are talking Nim->JS. But yeah, please don't call Nim a transpiler, it makes us Nimians all sad.
I tried to use Nim in an embedded context (ESP32). Since one of the bullet points is that it "compiles to C", I thought it'd be a good option.
In practice, even once I was able to compile basic Nim, there were a lot of glibc and other POSIX dependencies for any of Nim's standard libraries, some of which weren't available in ESP-IDF.
That's totally fair, but many of those dependencies aren't available when compiling to JS either, though, so I was surprised. In the end, delving into the code I found that a lot of stuff was gated behind the equivalent of "platform=JS" switches throughout the stdlib. It seemed like adding support for another platform would be a major pain.
This was all preliminary investigation and I didn't reach out to the Nim community, so perhaps I missed something. Maybe this kind of portability isn't even a goal for Nim. It would definitely be nice to have, though.
You need to pass --gc:none when compiling so that the compiler warns you when you try to use a garbage collected type and instead of the stdlib, use the SDK facilities.
Here are some libraries for embedded you can get inspiration from[1]:
- msp430f5510 - Run Nim on MSP430f5510 micro-controller (6KB of RAM).[2]
- stm32f3 - Run Nim on STM32F3 micro-controller (16KB of RAM).[3]
- ardunimo - Nim wrapper for Arduino + LinkIt ONE SDK by Mediatek.[4]
- ardunimesp - Nim wrapper for Arduino ESP8266 framework + A tool for flash, compile and make the nim project into an Arduino project.[5]
In the end I got Nim code to run and was able to do a "hello world". As a hack I also used -d:android to trigger some conditionals that reduced the reliance on various dependencies. But it wasn't enough to be usable, and it was a bit unfortunate to have to do that.
Looking at those projects you linked though, clearly I didn't try hard enough! Great to see that people have had success.
Thanks for sharing your experience. I read another comment about Nim being nice on microcontrollers because it compiles/transpiles to C, and my first thought was ESP32. I've written Rust for STM32 and MSP430 and it's awesome. ESP32, OTOH, seems like a nice platform but doesn't have LLVM support so C and MicroPython are pretty much the only options.
I really enjoy nim. Using it in two projects now. I write Python and typescript at work so nim gives me the syntax I like from python with the type safety I miss from typescript plus cool stuff like macros.
Please note that cheatfate is one of the most prolific Nim contributors and is also working in Nim as a full-time job at Status[1]. He is also the main author of an asyncdispatch hardfork[2]. I.e. any issue you might have with the lib can be raised and addressed fast.
I wasn't proposing anything. I dropped a link with relevant content to your post. It was as much aimed at readers of your comment as it was aimed at you. Please turn down your scorn.
Pretty far from my area of expertise. BTW. I have 0 expectation that someone has to solve my problem but when looking at a lang to me the minimum req. are good PG support and decent http lib which is obviously not the requirements people actively working on Nim have.
In terms of features it's powerful enough to build a Discourse-like forum enough. In terms of performance it's very well performing in the TechEmpower benchmarks[3] it is competing in. It even grabbed first place on JSON serialization on Cloud hardware.
OK english is not my native lang so maybe I am not formulating things clearly I did not try to suggest that nim does not have good http lib. I was just saying my 2 core requirements good http lib and high quality mature PostgreSQL driver. Nim has good Http lib Nim does not have async PG driver that I would feel confident using in prod.
I found the same thing. There are oddities in the non-async library too -- for example, rows are returned as a tuple without any column metadata, so you can't do a "select *" because you don't know the column order. I think all types get stringified too, which is weird.
The core language is interesting, but like the standard library has an odd edge here and there.
I enjoyed it quite a bit while playing with it about a year ago. The compiler had some bugs and the language spec had some rough edges that turned me off a bit, but I've also noticed in the year since that most (all?) of the issues I ran into got fixed. So that is promising! They have gotten a bunch of funding since then too so progress may accelerate.
I'm working on a library to do that right now [1]. Currently, it's alpha quality, but you can make OpenGL apps in both, SDL2 apps in iOS and Webview apps in both. Also check out nimx [2]
Advent of Code is a really fun event in general and an excellent problem-solving exercise, I remember how /g/ won last year's global leaderboard. I'll definitely going participate this year as well.
/g/ is a discussion board on 4chan(nel). Last year's global leaderboard winner (anonymous user #193354) was part of a private leaderboard for /g/ users.
Every feature you can possibly imagine, and then some.
Not always a great thing. Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas.
I’ve tried the language a few times over the years, and each time the compiler was just as buggy.
Lots of corner cases to worry about with features, like generators working only if the code that invokes them can entirely be inlined.
> Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas.
I'm not too familiar with the specifics of Nim, but how are case-insensitive variable names a bad idea, except that notion is so unfamiliar to programmers?
Flipped around, if a language were to be designed today in a vacuum, what is the argument in favor of case-sensitivity in variable names?
My feeling is that we take case-sensitivity for granted because the vast majority of languages inherited that behavior from history's lineage of great programming languages. But re-evaluated without that history, case-sensitivity seems only to create potential confusion at best and opportunities for trolling and obfuscation at worst. Today's use case to indicate scope, mutability, or permissions is an artifact of this history. As programmers, we know how to read something like this in Java, but if we were able to completely erase our historical knowledge and consider language design without that baggage, this seems like bad language design:
// Local variable square is instantiated equal to
// SQUARE constant in class Square.
Square square = Square.SQUARE;
I'm not sure what alternative syntax we'd have today if we had never adopted case sensitivity in names to begin with, but my hunch is I would prefer it even if it involved more typing (e.g., prefix or suffix symbols).
Admittedly, a statically analyzed language will have most case typographical mistakes found and corrected at compile time, so they are a lesser annoyance than case-sensitivity in other contexts (such as filenames or column names in database tables). Generally speaking, I would be in favor of a hard break to drop case-sensitivity across the board, but I'll put that on the same list as adopting the metric system in the US (titled: "LOL, good luck.").
How? we would just have case insensitive refactoring tools.
> Encourages a consistent style in the ecosystem from the beginning.
Python, C, Java, etc are case sensitive langs, and it's possible to define function names in all upper-case and do all kind of inconsistent styling. Python has pep8 for a reason.
> Not needing specialized tooling to grep for an identifier in a codebase.
If all langs were case-insensitive, all those tools would be case-insensitive by default (or we would all know the right combination of flags to make them behave).
> Being able to Google a particular function name.
Is google case sensitive? In any case the lang would define a preferred style, like all case-sensitive lang do anyway.
> Consistency in identifier naming when looking at a stacktrace.
Same as above.
Parent said "if a language were to be designed today in a vacuum", I don't think any of your arguments hold.
You might think so, but Nim had to backtrack some on case insensitivity because it removes a very useful way to distinguish between types and things of that type ... so now the first character of a symbol is case-sensitive and the rest is not. If starting from scratch, as you suggest, I think most people would go for complete case sensitivity instead of Nim's now partial sensitivity. And the OP is also referring to Nim's "interesting experiment" of being agnostic between snake_case and CamelCase ... SnakeCase and Camel_case are matching symbols ... but notice how the case-sensitivity kind of kills the whole notion of agnosticism about snake_case. It's experience with this experiment that makes it pretty clear that it was not a good idea.
patty and gara should eventually combine into a single lib: including probably the current gara matching DSL(inspired by patty) and patty's variant DSL in the same place.
> Do the pattern matching libraries check for exhaustiveness in the match cases?
I'm not 100% sure, but I would guess yes.
> Do you see this eventually becoming part of the language?
I can answer this with some confidence: no. Nim is designed to have a small but very extensible core via metaprogramming. This is why we encourage users to write such macros. They may end up in our stdlib eventually but it's unlikely they'll be part of the language.
At least gara can't check exhaustiveness now: require one to add `else` to check all cases: it might be harder in general make sure branches match each possible value.
However it should be possible for sum types/enums: `case` already does it
I have done Advent of Code in C++ and Rust (2 years), it has been fun every time. This year I will change tack and use Factor, which I have admired for a long time but never used much in anger.
> The Nim team has decided to reward the best (fastest) player on Nim leaderboard
Does this mean the fastest developer (first to submit a solution?) or does it mean the fastest program in terms of runtime performance or something completely different?
