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.
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.
I’d be curious to get your Nim highlights.
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
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
- 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)
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.
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.
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.
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?
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.
If so, that was a quick edit.
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'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.
-----
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.
Julia is the same thing. Data oriented.
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.
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.
