Live data from Hacker News

Nim 2.0

nim-lang.org

51–60 of 213 posts

Re: Nim 2.0

#51
post #36

Earlier quoted context omitted.

I maintain auto-generated bindings for my C libraries for Zig and Nim (and Odin and Rust - although the Rust bindings definitely need some love to make them a lot more idiomatic). I think looking at the examples (which is essentially the same code in different languages) gives you a high level idea, but they only scratch the surface when it comes to language features (for instance the Zig examples don't use any compt…

And which language did you enjoy coding in the most? Yeah, a subjective question :-). (Edit: Missed the auto-generated part, so maybe you don't have an opinion on experience regarding this?)

I think actually Odin, although I was surprised by that (being more of a Zig fan). Odin has some neat convenience features which are nice for higher level code, while Zig can be a lot more 'draconian' by enforcing correctness even at the cost of some "line noise" (but I guess both languages are still in flux, so that might change).

As for Nim I enjoyed it initially (because of the Python vibes I guess) but the automatic memory management gets confusing quickly. IIRC there's quite a few different reference types - but maybe that has been simplified in 2.0

PS: Even though the bindings are auto-generated, I still try to make them 'language-idiomatic' by injecting some 'semi-manual' mappings for things like naming conventions or implicit type conversions, ideally getting the API close to what a 'native' API would look like - at least that's the goal.

Re: Nim 2.0

#52
post #20

Earlier quoted context omitted.

Nim's should probably be redone with mummy (multi-threaded) and chronos (async single-threaded) for a better showing: https://github.com/guzba/mummy https://github.com/status-im/nim-chronos

Why does the stdlib implementation do so badly in the first place?

It is maybe the most simple web server implementation, similar to what you get from "python3 -m http.server"? What sense does it make to compare highly focused web server frameworks to languages most simple stdlib implementations, much apples vs oranges.. (thus also not getting why the proposal to compare with actual web frameworks for nim is that much downvoted?!)

Re: Nim 2.0

#53

Could be a fun python alternative Questions: - value/object semantic: i peeked at some code, and i can't tell what is a value, and what is a reference type, is everything heap allocated? - tooling: what's the state of their language server? does it work with all of their language features? - debugging: does gdb/lldb understand nim's types and slices? And finally: is a no-gc mode available? I'll play with it later tod…

1. Nim uses 'var' modifier to pass by reference, e.g. "proc (n: var int)...", default behaviour is pass by value. And there're also raw pointers and references (safe pointers). >is a no-gc mode available? You can disable gc, but most of standard library depends on it. But in Nim 2.0 there's finally support for ARC and ORC (ARC + cycle collector).

I've been searching and can't find it: A in ARC is for automatic, what does the O stand for?

Re: Nim 2.0

#54

What are some noteworthy projects or libraries written in Nim?

I don't know if my particular version is noteworthy, but I recently started making updated Nim bindings for OpenCV and it was kinda fun. I don't consider myself an advanced C++ programmer, but Nim made the process easier than I had feared it would be. https://github.com/tapsterbot/mvb-opencv

Re: Nim 2.0

#56
post #35

Nim looks awesome. Does anyone know why it doesn't have first-class support for wasm? That's the only thing that would keep me from diving into it more.

I think the short answer is it's built on top of C tooling so it doesn't really need another way to do it because you can use emscripten. Search their forum for "web assembly". I did ask him about it eight years ago: https://forum.nim-lang.org/t/1392#8675 But that was a little early on and there have been other priorities for the language.

The reason I ask is that I was poking around and saw some projects to help with wasm compilation, and on this random list of wasm-capable languages [0], Nim is listed as "Work in Progress." Notably, Swift is ranked higher, and I view Swift as extremely experimental when it comes to wasm

[0]: https://github.com/appcypher/awesome-wasm-langs

Re: Nim 2.0

#57
Looking forward to trying out this release!

After programming professionally for 25 years, IMO Nim really is the best of all worlds.

Easy to write like Python, strongly typed but with great inference, and defaults that make it fast and safe. Great for everything from embedded to HPC.

The language has an amazing way of making code simpler. Eg UFCS, generics, and concepts give the best of OOP without endless scaffolding to tie you up in brittle data relationships just to organise things. Unlike Python, though, ambiguity is a compile time error.

I find the same programs are much smaller and easier to read and understand than most other languages, yet there's not much behind the scenes magic to learn because the defaults just make sense.

Then the compile time metaprogramming is just on another level. It's straightforward to use, and a core part of the language's design, without resorting to separate dialects or substitution games. Eg, generating bespoke parsing code from files is easy - removing the toil and copypasta of boilerplate. At the same time, it compiles fast.

IMHO it's easier to write well than Python thanks to an excellent type system, but matches C/C++ for performance, and the output is trivial to distribute with small, self contained executables.

It's got native ABI to C, C++, ObjC, and JS, a fantasic FFI, and great Python interop to boot. That means you can use established ecosystems directly, without needing to rewrite them.

Imagine writing Python style pseudoocode for ESP32 and it being super efficient without trying, and with bare metal control when you want. Then writing a web app with backend and frontend in the same efficient language. Then writing a fast paced bullet hell and not even worrying about GC because everything's stack allocated unless you say otherwise. That's been my Nim experience. Easy, productive, efficient, with high control.

For business, there's a huge amount of value in hacking up a prototype like you might in Python, and it's already fast and lean enough for production. It could be a company's secret weapon.

So, ahem. If anyone wants to hire a very experienced Nim dev, hit me up!

Re: Nim 2.0

#58

Been happily crunching away at Nim in production. I'm working on what is mainly a data analysis and report generation tool, compiled as a CLI executable that gets called by server scripts. Nim makes fast, small executables. It has an excellent heterogenous JSON data structure and a good dataframe library. It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dict…

This sounds great. How is the package management story, and how robust is the ecosystem currently?

Re: Nim 2.0

#59
"Nim is a programming language that is good for everything, but not for everybody."

now you got me really interested.

At some point dlang-betterc + zig + nim should have an interoperability article and share libraries.

Re: Nim 2.0

#60

Earlier quoted context omitted.

1. Nim uses 'var' modifier to pass by reference, e.g. "proc (n: var int)...", default behaviour is pass by value. And there're also raw pointers and references (safe pointers). >is a no-gc mode available? You can disable gc, but most of standard library depends on it. But in Nim 2.0 there's finally support for ARC and ORC (ARC + cycle collector).

I've been searching and can't find it: A in ARC is for automatic, what does the O stand for?

I assumed the O was for "optimised", but apparently it stands for "cycle":

https://nim-lang.org/blog/2020/12/08/introducing-orc.html

Post reply on HN