Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.4

nim-lang.org

Post reply on HN
Print view View original

81–90 of 144 posts

Re: Nim 1.4

#81

Post by nivviv »

cb321 wrote: post #71
Abishek_Muthian wrote: post #67

Earlier quoted context omitted.

Statement on performance is surprising, I haven't personally benchmarked Nim against Go so couldn't say about that. But I started using Go for the same reasons pointed out in parent and after being tired of changing Python code to C to resolve performance issues. How about concurrency?

There is a link in another of my comments here and because Nim is pretty open architecture you can roll your own basis for what you want (more than most languages) such as: https://github.com/mratsim/weave

I can't speak about go vs nim generally, but:

Our particular design is a bunch of single-threaded apps on a message bus. Each app (network ingress/egress, data handling, relays, etc) sits on the bus, and can use async/await to do IO concurrency, but on the app level, there's no threading and no locking to observe.

Each app also has a erlang-inspired supervisor task system, where each task is just a async proc kept alive. It's proven to be very robust (from the standpoint of service availability) in the face of bugs or input validation mishaps.

Re: Nim 1.4

#82

Post by fataliss »

Maybe my lack of lower level language knowledge will show here, but how does that compare to Rust? I keep seeing and hearing about these new-ish languages Rust, Nim, Zig, etc. that all claim to be C/C++ perf lvl but better developper experience. Any of these is preferred for API/Web development? Does it yield much advantage over something like Elixir that already provides significant perf increase over a Python(Django-Flask)/RoR stack?

Re: Nim 1.4

#83

Post by nivviv »

jimbob45 wrote: post #78
nivviv wrote: post #74

Earlier quoted context omitted.

Our production stuff runs on Linux, so we just wrap it into docker and that's that. Personally, I develop on Mac and it runs natively there the same as on Linux. Windows binaries for the tooling releases I used to build with a cross-compiler, but more recently, GH actions looks attractive enough to take that role. Edit: Sorry, could have been clearer. The build system is just running the binary directly via nim cpp -…

So you use Docker to keep the build system unchanged between builds? That’s genius if so and cuts deeply into MSBuild’s main advantage (comprehensively delineated system settings).

I think there might be a misunderstanding. I'm just talking about the multiplayer service infrastructure, not the whole game.

Despite doing a lot and having a lot of smaller moving parts, the mp infra is of moderate code size and build complexity is not a concern. The whole thing compiles in less than 5 minutes, and can be done with nimble (the package manager). We have a docker builder image that spits out the final production image containing the apps, and a docker-compose setup then runs those as needed.

Any kind of per-platform specifics are handled in nim itself (when defined(Linux): etc) and via nim.config/nims.nim, to link in platform libraries.

Re: Nim 1.4

#86

Post by steveklabnik »

fataliss wrote: post #82

Maybe my lack of lower level language knowledge will show here, but how does that compare to Rust? I keep seeing and hearing about these new-ish languages Rust, Nim, Zig, etc. that all claim to be C/C++ perf lvl but better developper experience. Any of these is preferred for API/Web development? Does it yield much advantage over something like Elixir that already provides significant perf increase over a Python(Djang…

In my mind, and be aware of my bias here, these languages split up into three different categories:

* Has a GC, but you can remove it. This is Nim and D.

* Relies on pervasive refcounting. This is Nim if you choose that implementation, Swift.

* Has no GC. This is Zig and Rust. (Though obviously you can use refcounting in these languages, but it is as a library.)

While this focuses on a specific aspect of these langauges, I think it also represents their philosophies pretty well. Nim and D start from a "what if we had a GC" and then try to make things nicer down the stack. Rust and Zig are how nice can we go starting from nothing?"

There are also additional factors that may or may not play in here, depending on what your needs are. Arguably, Rust is starting to break out of the "niche language" stage and move into the "significant projects and is sticking around" phase, whereas many of these other languages aren't quite there yet. This can matter with things like getting help, package support... some people love the open frontiers of new languages, others want something more mature. https://nimble.directory/ has 1,431 packages at the time of writing, https://crates.io/ has 48,197.

Re: Nim 1.4

#87

Post by ddragon »

te wrote: post #85

Nim or Julia?

You can pick both, they are very different. Julia is a dynamic language looking for a compromise between interactivity and performance (from it's origin on R/Matlab), while Nim is one of the new batch of static languages that looks for the perfect balance between of easy of development and safety/speed.

For example, if you want to do something more exploratory (like some research or data analysis) that can still easily scale up to HPC you can use Julia, if you want to create something reliable with small binaries and no start-up issues or use in more resource constrained environments you can use Nim.

Re: Nim 1.4

#88

Post by cb321 »

ddragon wrote: post #87
te wrote: post #85

Nim or Julia?

You can pick both, they are very different. Julia is a dynamic language looking for a compromise between interactivity and performance (from it's origin on R/Matlab), while Nim is one of the new batch of static languages that looks for the perfect balance between of easy of development and safety/speed. For example, if you want to do something more exploratory (like some research or data analysis) that can still easi…

Not that @ddragon exactly said you could not, but you can also use Nim for data science, such as https://mratsim.github.io/Arraymancer/ or https://github.com/Vindaar/nimhdf5 or many others and there is a REPL INim mentioned in another comment here. If you want everything "done for you already", Julia has more libraries and it is (for better or worse) more fundamentally dynamic.

Re: Nim 1.4

#89

Post by dnautics »

elcritch wrote: post #55
neverartful wrote: post #37

Earlier quoted context omitted.

"Nim isn't quite as simple as Zig" My experience is complete opposite. I find Nim to be very simple and Zig to be not simple. What's the problem with Zig? I find the documentation to be chaotic. I believe that this is largely due to the rapid pace of changes (including changes that break earlier code).

That makes sense. I haven't tried Zig, but it's still pretty early in its history. That means a lot of syntax change, similar to Rust which is settling down, or Swift. Nim's been around long enough that it's settled it's syntax a while back. Before I started really digging into Nim, it seemed like it was always changing the language a lot (feature churn). However, most of those changes have been compiler support for…

My understanding is that Zig is also strongly committed to working out as many kinks as possible so that 1.0 can be an extremely stable release, so they are running as fast as possible to make mistakes in the language. In that sort of an environment it doesn't really make sense to solidify docs.

Re: Nim 1.4

#90

Post by imtringued »

DannyB2 wrote: post #39
judofyr wrote: post #34

Earlier quoted context omitted.

> Obviously, just from Java occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right. I'm not sure if this argument holds. Java's high memory usage is frequently cited as a downside of Java. GUI applications written in Java have a reputation of being memory-hungry, and I know plenty of people struggling with memory usage of server application (e.g. ElasticS…

> Java's high memory usage I would rather optimize for performance and energy use at the cost of higher memory use. See recent SN: https://news.ycombinator.com/item?id=24642134 https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle... Memory is a one time capital cost and gets cheaper over time.

High memory usage forces you to only run one JVM process. If you need to do something that doesn't require a significant amount of memory you can't use Java at all.
Post reply on HN