I don’t know much about Nim, does it have a mandatory gc, like go? How good is Nim’s gc?
Those who have written some Go and Nim, home does the code look like vs go?
Those who have written some Go and Nim, home does the code look like vs go?
And Nim does not have a mandatory GC, you can go as low-level as you want, but in case you don't want that you can choose from several great GC's(a capable soft real-time GC and Boehm for example). Or you could combine the best of both worlds and take a look at the shiny fancy ARC/ORC deterministic memory management: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...
Nim has other advantages, including great Interop with C or C++ as it compiles to these languages and allows low level, unsafe features like raw pointers when needed.
* I feel like Go has less 'edge cases', but the Nim compiler is steadily getting more stable, especially consider it's not backed up by a major company!
* Metaprogramming is really powerful, but not beginner friendly. The documentation says use macros when necessary, but personally I don't think that really happens in practice.
The advantages by far outweigh the disadvantages, especially if you are looking for a clean Go alternative(except maaaaaaybeee web application).
EDIT: my own wishlist, but they aren't relevant compared to Go:
* Better sum types * Builtin pattern matching
> The json module provides the %* operator which is used to create JSON objects
I'm curious what the benefits are here of an operator over some more readable syntax. I have a dislike of languages where ascii noise seems to be favoured over readable english tokens.
Even Rust dropped most of its strange operators/sigils early on in the experimentation phase, because they confused people and Rust doesn't step back from confusing people lightly, haha.
But yah Nim's % is a bit strange at first, but becomes fairly handy in practice when dealing with lots a small bits of JSON. There's the % "to json" operator that mimics the $ "to string" operator for a single value. Then %* was added to handle multiple json items (I read it like apply % to all items). So it has a decent symmetry. Other than % and $ ascii operators are pretty rare in Nim code. Even bitops use or, and, shl, shr, etc over ascii operators.
import std/json
echo %*{
"key1": "value",
"key2": 12,
}Because * / - + is the common ground that essentially everyone is familiar with. And that's about as much math notation as makes sense in general purpose programming languages.
There is only one math but many programming languages. Multiplication is universal and fundamental. Creating JSON objects in nim is the opposite of that.
If I entered "nim json" into google I'd get thousands of results for the language and json in general, and no way to narrow it down to meaning the operator "JON". That's not really what searchable means.
My google insider tells me you can add the word "operator" to your query to do that. Or any other similar word like "keyword" that anyone else thought to call it on stack overflow.
Even after the first time symbols have a non-trivial cognitive cost for a lot of people, if not most, all while providing near zero benefit unless your app is pretty much nothing but a bunch of inline json expansions.
let a = (1.5'f32, (b: "b2", a: "a2"), 'x', @[Foo(t: true, z1: -3), nil])
let j = a.toJson
assert j.jsonTo(typeof(a)).toJson == j
If you squint, it looks like a toddler Python with strong typing, compilation and a few different API, espacially for managing finalisation.
From around 1:00 pointers are being discussed.
Nim is less verbose than Go and more expressive.
ORC turns out to be rather nice to use: https://nim-lang.org/blog/2020/12/08/introducing-orc.html