Mastering Nim – now available on Amazon
nim-lang.orgI absolutely hate Nim for spoiling pretty much all other programming languages for me. I wish it gained more traction. Congratulations on your book and keep up the great work, Araq. You did an outstanding job with Nim and I wish you all the best!
I totally agree, Nim is great but it really needs more traction. I'm developing a web framework for Nim with batteries included (an ORM, for one), Nexus: https://github.com/jfilby/nexus
jasfi, I am actually following your project and wanted to take this moment to ask a couple of questions. How are you planning to solve for Postgres drivers/clients with async and pipelining support?
I had added nim std lib to the Techempower benchmarks, and while Nim shines in the plain text and other non db related requests, it comes at the very bottom as far as tests like Fortune go. When I did the work, there were no maintained/active Postgres drivers with async and pipelining support. And IMO, that wa the biggest reason why Nim hasn't had great benchmarking scores.
Glad to hear you're interested in Nexus. The ORM currently uses db_postgres (from Nim's stdlib) only. I'm going to implement support for db_mysql and db_sqlite as well, it should be easy enough given how similar the API for the stdlib DB drivers are.
Actual work on DB drivers is out-of-scope for me though. I noticed there is an async Postgres driver available: https://github.com/treeform/pg. I don't know how well tested this driver is, and no mention of pipelining support.
It would be great to see Nim's web frameworks higher up on the Techempower benchmarks. Lack of such DB driver features usually comes down to time. The support for those features in stdlib would be a good bounty issue.
I did some testing with Nim a couple of years ago for HashBackup. Here's one of the db_sqlite issues I created:
https://github.com/nim-lang/Nim/issues/13559
I had much better luck with tiny_sqlite: https://github.com/GULPF/tiny_sqlite
It seems that issue is now fixed. Either way, Nexus will soon support multiple DB drivers, and I'll work on making adding new ones relatively straightforward.
I went with db_postgres as well. Unfortunately, it is not async. I did consider treeform's pg, but unfortunately i did not get any reply from him on my question so decided not to go with it for the TE benchmarks.
I think the lowest hanging fruit for db drivers would be to just wrap libpq, the default PG driver. Given Nim's c interop, that should be easy. I was planning to do that, but then life happened and I had to skip that project.
I would say, that if you are trying to create a very involved framework, you should look to solve this problem. Otherwise the current perf of db_postgres can be a big deterrent to a lot of potential users.
I agree that wrapping libpq sounds like a good idea.
did a bit more digging and apparantly db_postgres wraps libpq already. So either nim is still using a very old version of libpq or it was never updated to use the async apis.
Nice one of the projects I want to work on is a simple text editor that lets you build and run. I think back to some of my favorite niche languages like Processing and Racket although I dont use them a ton when I do I love their interactive editors.
I am getting ahead of myself since I am still learning the language but I am coming from Python and various other languages so it has not been a complex transition.
Nim also needs lots of example code for people to learn from. Even if people don't use Nexus, it's at least one more Nim project out there.
Do you have a Discord or anything? I'm interested in helping, I love Django and I would love to help any way I can.
There's no Discord yet, just GitHub issues. Here's an issue to track this request: https://github.com/jfilby/nexus/issues/14
I'll email you regarding what/how to help.
Yes, that is fine, my email is in my profile. I'll look forward to hearing from you. I can help with the Discord if you need help.
That’s how I feel about Elixir. Everything else just feels wrong now.
I’d be curious to get your Nim highlights.
My experience after a couple of weeks:
Pros: Extremely good C and C++ interop Significant indentation Very good performance Quick compilation Terse, but readable Easy cross platform Powerful macros and close to trivial DSL construction Very little code to do a lot of stuff Incoming future features look very promising
Cons: Hard to predict and control program performance, LTO does a lot of heavy lifting Immature ecosystem, because only few users. Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together. Many different ways to do the same thing everyThingIsCamelCase, ambiguous variable names (subjective) Documentation and tutorials is mostly reading through the code and googling forum posts outside the core language You compile either for C or C++, some libraries simply won't work without C++ compilation
Nim has several GCs available. For predictable performance you may want to use ARC. See: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...
For my contribution to the ecosystem see Nexus mentioned in another comment. If you see bugs please report them. Sometimes libraries are deprecated/abandoned because of new ideas, this happens in every ecosystem.
I personally use camelCase/PascalCase, but Nim is style insensitive, meaning you can call procs written in camelCase using snake case. However this is controversial and under discussion, my personal opinion is to make style sensitivity optional, with insensitivity the default.
Ambiguous variable names I hate, you won't see that in Nexus, if anyone does they should file an issue. That's really developer dependent.
For my part Nexus has some docs and a basic tutorial. But if people want more they need to ask for it. Why write docs nobody wants or will read? Anyway, this book (Mastering Nim) is one more definite step forward for learning Nim.
I think compiling to C is what mostly happens, C++ is probably an outlier. Even then, a C++ compiler isn't difficult to install if needed.
> Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together.
For me missing libraries never stopped me, I could always port/wrap whatever I needed. However with the advent of AI assisted coding, working on libraries is even faster and at some point I hope I wouldn't spend much time rolling decent libraries that are ports of existing github projects.
I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).
As with most things, "it depends". If you compile very macro compile-time virtual-machine heavy code that can be slow. If you compile to the c++ backend then that backend process can be slow. If you invoke some macro that generates mountains of Nim code translated to continents of C code it can be slow. If you use the default `nim.cfg` that has gcc -Og it can take a lot longer than gcc -O0, for example. Meanwhile, if you use the `tcc` backend even without incremental compilation it can be close to immediate feedback:
(I point my default backend compiler to tcc in my $HOME/.config/nim/nim.cfg.) There are some more details in this nim forum thread: https://forum.nim-lang.org/t/8677$ touch foo.nim $ /usr/bin/time nim c foo.nim CC: ../usr/lib/nim/lib/std/private/digitsutils.nim CC: ../usr/lib/nim/lib/system/dollars.nim CC: ../usr/lib/nim/lib/system.nim CC: foo.nim Hint: gc: refc; opt: none (DEBUG BUILD, `-d:release` generates faster code) 36891 lines; 0.154s; 39.434MiB peakmem; proj: /tmp/foo.nim; out: /tmp/foo [SuccessX] 0.24user 0.02system 0:00.27elapsed 101%CPU (0avgtext+0avgdata 44360maxresident)k 0inputs+0outputs (0major+13676minor)pagefaults 0swapsUnless your standards are "single digit milliseconds per file like tcc itself, please!", 240 ms is not so bad. (EDIT: And this is just on some 2016-era Intel i7-6700k box, not some liquid helium cooled 10 GHz whatever.)
It's much faster than C++, Rust, Go and many others.
I'm assuming this must be for huge projects?
I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s).
nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.
how are u compiling (optimization, custom compilation flags etc.?) In my case https://github.com/mratsim/Arraymancer big project compile under your 4.2s so or you have like 10k+ lines of codes with macros or you just pass some debug flags to compiler :D
Compilation command is:
I will add that once it's been run a few times, it does go a bit quicker (down to ~0.7s) but the Go also gets quicker (down to 0.28s for two outputs when files are cached.)nim c -d:release --passC:"-flto" --gc:markAndSweep --out:ap ap.nim
No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?
How would I check that? I installed it through homebrew via https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... which doesn't seem to mention debug mode anywhere?
Run `nim -v`, if it's not in debug mode you should see "active boot switches: -d:release".
Looks like it isn't in debug mode after all.
$ nim -v Nim Compiler Version 1.6.6 [MacOSX: arm64] Compiled at 2022-05-05 Copyright (c) 2006-2021 by Andreas Rumpf active boot switches: -d:release -d:nimUseLinenoise
Thanks for the data; that's what I call an elegant rebuttal.
No, it is not - Nim's compiler backend is extremely complex and full of cruft. I've been around Nim for 7+ years now and there's a reason the compiler was hard forked.
Nim's compiler is definitely not speedy, and this is why so much effort has been spent on incremental compilation, which tmk, still isn't working - https://github.com/nim-lang/Nim/issues/19757.
In comparison to languages like Rust and C++ it compiles pretty fast. Or maybe you built the compiler in debug mode.
I think Nim does DSLs particularly well and is the performant option for the Python class of scripty general purpose languages. I personally prefer more state controlled languages (Clojure, Rust) but I've considered pushing for Nim on shared/work projects. The main reason I haven't is network effects. The language niceties compared to other scripty general purpose languages aren't going to make up for the time spent writing all the libraries from scratch and I can't point to being able to control state as a motivation.
Odd, I've really yet to run into a key library that I needed and couldn't find. Not all libraries are listed in Nimble too. Granted I've not done much web server stuff in Nim. Sometimes a library needed a bit of polish, which is usually trivial given how concise they are. I've actually had better luck with it than say with Elixir on anything not web related. Occasionally I've needed to wrap or convert some C code on non-embedded projects.
Elixir is not bad, but I definitely prefer static typed languages now after getting more into TypeScript. Not having types just feels wrong now.
You might like this development around Elixir then: https://twitter.com/josevalim/status/1535008937640181760
static types in Elixir would be fantastic
Not having failure domains is worse than not having types IMO.
What are failure domains?
By default a green thread is the atomic failure domain. A 'panic' in this green thread is isolated, but sends an uncancellable notification to anyone who subscribes to it. You can tie multiple green threads together so that when one goes down the others do too.
thats exactly how I feel when it comes to web frameworks. nothing else has anything good enough to give up all the nice toys elixir gives me.
haskell's types are cool
vuetify makes me consider nuxt
but only elixir has otp, immutable data structures, intercluseter message passing, channels, good performance, ease of use and descent ecosystem out of the box.
rust is the only other new language Im looking at but for things outside web development
Elixir is indeed the most loved web framework according to the latest StackOverflow survey. I'll be looking to Elixir for ideas for Nexus (web framework).
I meant Phoenix, which is built on Elixir.
a lot of what makes phoenix amazing is directly inherited from elixir which are sub-derived from beam.
Beam really is a marvel.
copy one write and immutable data structures mean you ca have garbage collection reserved for the termination of a thread whihc would be a nontrivial task in languages that encourage mutability cough go cough
Beam processes are a blessing
its also extremely tuned for creating threads that are super lightweight. consequently, scaling strategies that are optimal in elixir would be a TERRIBLE idea in other languages. You could make a dynamic cluster of node/go instances that communicate over rabbitmq and have a supervisor process that can keep track of their state and resurrection in case of a crash. Its going to be error prone and take weeks of fiddling to get right. beam gives you that out of the box. Its not perfect but its more than good enough for your first 10000 customers.
This benefit extends all the way up to Phoenix. because threads are trivial to create and the overhead is low, its a viable strategy to generate a stateful process for every user as they interact with the system, this is what allows liveview to be so powerful.
Each channel connection gets its own thread as well. A single machine can handle thousands of threads this way with full isolation. one thread crashing won't affect your other connections. nodejs cannot provide that. if a web-socket connection crashes a node instance, it ends the connection for every customer currently connected to that node.
Every attempt I've seen outside beam to recreate this revolve around OS level process which have a higher overhead and then they still need to create a mesasge passing protcol and supervision system. since OS threads are epensive, it wouldn't be a. good idea to try creating something like liveview as you'll overload your machine.
So you might say, "ok, I'll craete a multicluster virtual machine optimized for immutable data structures with a built in intra process messaging protocol for communication as well as a higher level super vision process. at that point, I'll say "congratulations, you just reinvented the beam, lets see if we can port other languages to it!"
anyways, if you're looking for something a little smaller for now, I highly recommend really understanding ecto and how it has you interact with databases. its easily the best database library I've worked with. precisely because it isn't a orm. It maps sql rows to elixir records which has much less of an impedance mismatch. its achieves almost zero friction between your database and your api.
Care to give a brief overview of what you find appealing? I've never looked into the language before.
I particularly like, from the syntax side:
- Python-style syntax with significant indentation
- Uniform Function Call Syntax: a.len() == a.len == len(a)
- Fully unqualified imports by default: which might seem scary to Python programmers, but works great in practice because of static typing
- All of the above makes code readable and succinct
And from a language features side:
- Compiles to C with all the architectural targets that come with it
- Compilation to C also allows for easy C interop: wrap function signatures and types and you're done
- This, in turn, means that Nim libraries can bootstrap off of the massive C ecosystem, while adding nicer APIs on top
- Extremely performant GC by default: optional Rust-style annotations can further improve performance, and you can remove all overhead and manually manage memory with C-style pointers if you'd like
- Useful compile-time templates and macros that can directly change the AST
The community is also active and helpful on IRC/Matrix/Discord/Gitter (bridged together)
One really important thing I forgot to mention is how extendable Nim is - first class support for macros and AST manipulation is very powerful. This cuts back significantly on the amount of functionality that needs compiler magic.
So you'll see alternative (or new) implementations of core language features like async, threading, DSLs, typeclasses, traits, etc available as external packages, with just about the same user experience as if they were built into the stdlib or compiler.
>- Uniform Function Call Syntax: a.len() == a.len == len(a)
a.len() == len(a) seems like a good idea, but I'm not so sure about a.len... Isn't that a bit ambiguous?
Other comments already gave great examples but for me personally: - Concise syntax - Elegant language constructs (e.g. method call syntax) - Great macro system - You have control over what GC you use - Great performance - Everything is simple, it's easy to read other people's code
Even Rust?
Nim gives you like 85% of the performance of Rust without having to worry about a borrow checker. It also solves concurrency problems via its use of Channels, like Go.
So it's just hard to justify using Rust, for me. Unless you're writing a DB or something where a GC is a no go. But Nim's memory management seems pretty good, and many things are stack allocated.
Even though Nim by default works with a GC to manage memory, I regularly use Nim to work with direct-memory/raw-pointers and can still have increased memory safety by using HOOKS and ARC. I have written about my experience here[1], in case somebody is curious.
1. https://ramanlabs.in/static/blog/raw_memory_management_patte...
Its nice being able to go all the way from fully GC reliant cyclic data-types with closures all the way to memory control-freak every byte and microsecond matters by using stack objects and 'var' parameters. Often you can keep 90% of the code and just tweak a few slow points.
And for the stuff that matters, it is usually possible to tinker around enough to get it pretty much as good as Rust or C++.
For HN folk, it may not be so obvious from the blog post, but the author of this book is the Nim originator/technical lead/primary author to this day { since before 2008 publicly and I believe 2005..2006 privately }.
If you want more adoption of the language, probably best to leave a copy on the website for free. I think I saw some statistics that it doesn’t really reduce sale of the hard copies that much.
Curious on this, would you happen to have a citation?
Two things:
1. Buying this book supporters the founder and lead developer of Nim.
2. Theres consideration for some major v2.0 changes. Have a look and chime in if you haven’t.
I've liked Nim for years. Just jumped back in to use with the Godot engine. I originally went with rust (not by choice but due to an important dependency), and switching to Nim made me so much more productive. In this case I don't think rust was really adding much safety since the engine owns all the game objects.
I am hoping for an eBook. I don't have a lot of space for books, but my computer or phone is always nearby.
There's a free ebook by a different author, Dr. Stefan Salewski, "Computer Programming with the Nim Programming Language": https://ssalewski.de/nimprogramming.html
An e-book is going to heavily (and negatively) impact the sales figures for the print book. So I wouldn't hold out for that. Looking at the price of the book, he wants to make money from it, so no e-book is probably the right strategy.
> An e-book is going to heavily (and negatively) impact the sales figures for the print book
What? Do you have a source on that claim?
For me, I only get ebooks for programming books because I can have the IDE side by side with the PDF, no need to continuously look at the physical book and then back into my IDE, and I can copy paste code examples.
I prefer ebooks too. If I am really interested in the book, I buy the print version of the book though, if I cannot find an ebook version of high quality (that excludes many epubs, as formulas are typeset horribly in all of them; so a high-quality ebook is usually in PDF format). I am toying with the idea of sending these print books to somebody who (destructively?) scans them for me as PDFs.
For reading, I prefer my iPad Pro, although when looking at multiple books at the same time, I also put them up on one of my monitors.
totally agree re user experience with ide...
> Looking at the price of the book, he wants to make money from it
The price of a printed book includes:
- the price of materials
- the price of printing
- the price of transportation
- the price of storage
- the margins and profits of all of the above
- the margins and the profit of the store
And then, and only then, the author making money, if any.
How is e-book going to impact the author's profit, exactly?
Manufacturing of a book is really cheap. It's just a little part of overall cost. Nowadays it may cost more becauase of higher prices of paper. Everything else is managed by amazon for their cut. Stop shilling. The author is just greedy.
> An e-book is going to heavily (and negatively) impact the sales figures for the print book.
Well, if the price is the same, that hardly matters? Or are you implying unpaid/illicit downloads will be worse with a legal digital version as opposed to an illicitly scanned copy?
After buying an e-reader I can't defend buying print books from an environmental standpoint - it may be a sunk cost/resources fallacy - but with all the infrastructure for digital production, distribution and reading in place - print copies are a strict waste of resources.
You can read a print book without wasting electricity every time you open it and the toxic materials used to produce a e-reader.
Reading print is still a much more enjoyable experience (except in the tub -- a waterproof Kindle is still great and lightweight for that!), especially with the slow speed of e-ink screens.
I can't defend ebooks compared to the reading, sharing, and the later selling at a used book store my cast-off print books.
I've even gotten O'Reilly books from a decade ago at used book stores that are great to read and look great on my shelf, and I love finding some old novel by some forgotten author instead of whatever the latest Amazon bestseller is.
And I don't have to worry about the Orwellian deletion of my books from my e-reader: https://www.nytimes.com/2009/07/18/technology/companies/18am...
>You can read a print book without wasting electricity
You don't 'waste' electricity, you waste your money. And in many places electricity is (much) cheaper than (good) paper.
>toxic materials used to produce a e-reader.
Surely you realise that different chemicals are used during paper production too? https://en.wikipedia.org/wiki/Sodium_sulfide and https://en.wikipedia.org/wiki/Sodium_hydroxide for example. And this depends on paper type too.
>Reading print is still a much more enjoyable experience
And this is entirely subjective.
>I can't defend ebooks compared to the reading, sharing, and the later selling
While I 100% agree with selling option, sharing is at least as easy with epub. Unless we are talking about a book from Amazon or something. In most cases you can just send a file over your preferred messenger.
I'm dubious the environmental difference is that much. 1 e-reader vs how many thousands of books? It's seems to me the e-reader is a one and done cost, but each book comes with it's own trees cut down for the paper, shipping, etc.
As for the deletion I'm with you. That's why I always buy DRM free, or promptly crack anything I buy.
Nevertheless, many people like ebooks, for a variety of reasons. And I'll put the marginal environmental cost of another book on my reader, against the cost of producing and shipping a physical book, and then turning on a lamp to read it at night anyway.
There is the mass murder question of trees for books that never get sold and are eventually thrown into a dump, alongside the chemicals used in the publishing process.
> You can read a print book without wasting electricity every time you open it
This is generally true for ebooks as well, as I only have electric heating. Both probably require more electricity for lighting anyway.
> and the toxic materials used to produce a e-reader.
I assume an ebook reader uses more resources to produce than a book, but 1) I already have a reader, and 2) I have for example e-books I inherited from my dad - that's approximately a thousand books. Even just moving them into my apartment would require non-trivial resources.
> Reading print is still a much more enjoyable experience
I don't really agree. Especially not for technical books.
> I can't defend ebooks compared to the reading, sharing, and the later selling at a used book store my cast-off print books.
Agree that the Kindle/Amazon drm/marketplace is pretty bad. Not all books have draconic drm, though - and in such cases it's much easier to share a book with a friend that has moved over seas for example.
> I've even gotten O'Reilly books from a decade ago at used book stores that are great to read and look great on my shelf,
Sure, but in the event this is a problem - it's also a drm problem, not a problem inherent to ebooks.
As for books about "programing language x version y, with best practices as of year z" - I fully expect them to be mostly outdated after 5 to 10 years - maybe replaced by a new version.
> and I love finding some old novel by some forgotten author instead of whatever the latest Amazon bestseller is.
I've never discovered books from the AZ bestseller lists, but I've bought a few classics.
There are always going to be books that are hard to get - like the excellent:
Howard McCord book: "The Man Who Walked to The Moon" which was self-published if I'm not mistaken. I found it in a thrift store in Berlin. As it happens, it's now available for the Kindle:
https://www.amazon.com/Man-Who-Walked-Moon-Novella/dp/092970...
> And I don't have to worry about the Orwellian deletion of my books from my e-reader
Again - a market/drm problem (and a real one for sure).
I really do hope we will see more diversity in ebook sales, sharing, re-sale and lending.
I have no problem paying the same price for an eBook as print. If there is some reason a physical product must be involved, bundle both. I'll keep the eBook and donate the physical book to a library.
I'd like this too, I'm not one to read a physical book, but I'm constantly reading on my phone & computer
Looking at the excerpt on Amazon, the Acknowledgments part of the preface lists numerous people and concludes with: "This book would be as good as it is without your help." The author might want to fix that.
I like to think the author is thanking them for their efforts despite said efforts having produced nothing of value.
This appears to have been fixed in the Amazon page I just pulled up.
If so, that was a quick edit.
It's still there, at least on Amazon.com. I haven't checked other Amazon sites.
Looks to be fixed on Amazon.com: https://i.imgur.com/twYEtb3_d.webp?maxwidth=760&fidelity=gra...
Amazon.com shows the correct English to me.
first time I've heard of nim! anyone using nim in prod care to share their experience?
Disclaimer: I have not written a single line of C/C++ in my life, nim was the first language that exposed me to lower level concepts essentially.
I have a webpage-backend life in it, re-coded a very CRUD-heavy and medium-sized Django project in nim for funsies. You do notice that the ecosystem is not mature. You may have read another comment on here earlier that libs often are not fully featured or have clunky APIs. ORMs in particular are an area where you'll find a lot of teething issues. I found myself contributing to said libs in order to fix some of that, adding another lib to deal with connection pooling for me while I was at it.
Overall though, the coding experience has been intensely enjoyable and fun for me, which is why I kept going. Pushing logic to compile time is trivial, you don't even really need the macro system to do that since there's a pragma for that, and voila, suddenly you are able to have compile-time evaluation on whether you're trying to query a Many-To-Many relationship in your database correctly, guaranteeing you that you won't face those issues ever at runtime. I love this.
And all of this was without me having done any kind of deep dive into the macro system, I was mostly using generics, templates and compile-time-procedures (which are normal procedures, but annotated with the compile-time-pragma). And said macro-system from what I've seen opens up a whole new world of possibilities.
Another fun tidbit is that python interop is effortless, in both ways, thanks to numpy. As in, it is effortless to use python libraries, as it is effortless to make python use a library written and compiled in nim.
Edit: Deployment with docker needed some figuring out first, but wasn't hard by any means. Could use more documentation though, which I'll likely add.
I use Nim in production, its great. Easy to write like Python, but super fast like C. Type system prevents typos. Has very advanced macros.
What GUI libraries does Nim support?
There's 3 languages in the same class. Julia, Nim and Crystal.
I'm specifically curious about Crystal vs. Nim. Benchmarks show that crystal is pretty much faster, but I'd also like to know the advantages of why someone would choose Nim over Crystal I'm looking for reasoning that is deeper then just superficial language syntax differences.
Has anyone extensively used both? I would like an unbiased view from someone who has used both as opposed to someone who's only used one.
Gonna copy paste an old comment of mine:
-----
Syntax wise: Nim is to python what Crystal is to Ruby
Capability wise: both are incredibly powerful general purpose languages. Crystal is fully OOP, while Nim has a more functional/procedural bent. Nim is better for DSLs and has a fascinating macro system.
For system language use, Nim is a better choice as you can use it with its Arc GC or no GC at all.
Perf wise, Crystal seems to be marginably faster in most benchmarks. Though at that level the difference isn't much.
crossplat wise, Crystal has no "official" windows support (and you cannot do webdev on it) while Nim has.
Ecosystem wide: Both are young languages and the ecosystems are tiny. Crystal has more and better options for webdev. Nim, IMO, is better for games, console apps etc.
Tooling wise; crystal IDE tools are far behind that of Nim. But both are terrible when you consider any decent language out there.
Ecosyt
Personally I like Crystal a lot due to its type system and syntax but you can't go wrong with either language.
Perfect! Thanks!
One major issue that stopped me from trying Crystal is that Windows support is being worked on since 2013 and is still WIP as of 2022 with major language features still not working...
Julia isn't in the same class and workflow usually differs significantly from the others.
It is. Ruby and python are in the same class despite python being more data oriented.
Julia is the same thing. Data oriented.
Ruby and Python aren't data oriented. Python specifically was designed and used as system scripting language and Ruby was designed as an improved Python. Python only came to be used for analytics (as well as web and app development) because people made libraries for it. It could have been another language. Nim and Crystal could be utilized to write the underlying libraries (being performant static languages) but it will be hard to serve as exploratory frontend like the previous due to lacking interactivity. In contrast Julia can fulfill both the role of the underlying and the frontend language.
Python is data oriented. Nobody is talking about origins of programming languages. That is a separate topic. We are talking about the language as it stands now based on how it's used and the ecosystem.
I never said Ruby was data oriented.
Last I used it, Crystal’s compilation times are brutal. They may have fixed this (for non-production / dev iteration) with their work on an interpreter, though.
After using fast compilers, it’s really painful to go back to slow ones.
That said, Crystal is a really great language, and I plan on tinkering with it again soon.
What class of languages are those?
script style languages specifically designed with modern concepts and to be highly performant.
V8 is likely the fastest interpreter (javascript) for a script style language but these languages should be a step above and beyond v8 in terms of performance.
Nim is not a "script style language". By default it compiles to C, and the generated C sources are then compiled with gcc or clang, etc.
As it says on nim-lang.org, "Nim is a statically typed compiled systems programming language".
I know. But the syntax is still script style. The syntax is more closer to Python then it is to C++.