Live data from Hacker News

Nim 2.0

nim-lang.org

171–180 of 213 posts

Re: Nim 2.0

#171

"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.

Really, I'm quite hopeful for crabi: https://github.com/rust-lang/rust/pull/105586

An ABI for languages with a proper type system seems fantastic. Swift, Rust, Nim, D all share very similar type systems (and memory management systems) and it would be very cool to see what kinds of interop easy dynamic linking would allow.

Re: Nim 2.0

#174

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…

You have convinced me to look in to Nim! Can you speak to the build system(s)? CMake is the bane of my existence.

I did a lot of nim small projects. All of them are on nimble build system: https://github.com/inv2004

Re: Nim 2.0

#175
post #123

Earlier quoted context omitted.

Where in the announcement does it say that?

They likely read "overloadable enums" and went "Oh Rust calls their tagged unions enums" so assumed all languages did.

Oh, no, I actually misunderstood cobby's complaint: the field names, yes, those still have to be unique. Which is also a bit annoying, though I've seen discussions about changing it.

Re: Nim 2.0

#176
post #74

Nim is really very nice language to write software in. Ship fast, enjoy the ride, produce very performant software. Unfortunately it still in my experience has some sharp edges: juggling C/C++ compilers and options, very poor error messages, very situational libraries that only work on some settings and systems. Given the small community, tho, I can't really fault them for it. The VS Code integration works very well…

At least error reporting has been improved recently: https://nim-lang.org/blog/2023/03/31/version-20-rc2.html

Re: Nim 2.0

#177

Earlier quoted context omitted.

>More and more large companies and startups are adopting Nim. Ineresting. Are there any stats / data on this, or is it anecdotal? Even if anecdotal, can you name some names?

For startups, you can count us in[1]. Our backend, across all services, is using Nim. [1] https://cxplanner.com

What's the experience of writing web backend with Nim ? Did you use existing libraries / framework ? How good is the concurrency compared to something like Go ?

Re: Nim 2.0

#178
post #135

So, Nim doesn’t seem to be under an umbrella of a non-profit. Isn’t this destined to be a problem at some point regarding either acquisition of rights or succession? Edit: Ouch. Just found this thread. Very disappointing, and actually makes a greater case for institutional ownership: https://forum.nim-lang.org/t/10312

I thought it was strange that comments were deleted and the thread was closed for going off the original topic when it was Araq who shifted the topic.

Re: Nim 2.0

#179

I loved Nim when I used it first. But I left it because of recursive imports. I had to basically put all my types into one file and use them from various others. For a relatively medium sized project (~10LOC), its a but of a hassle. Refactoring is an issue. That being said, the language is fantastic. Can anybody with experience suggest me what HTTP library/framework do they prefer for servers?

Node and Python also don't really work with circular imports.

Re: Nim 2.0

#180
post #135

So, Nim doesn’t seem to be under an umbrella of a non-profit. Isn’t this destined to be a problem at some point regarding either acquisition of rights or succession? Edit: Ouch. Just found this thread. Very disappointing, and actually makes a greater case for institutional ownership: https://forum.nim-lang.org/t/10312

I find using main a little obnoxious, but like who cares that much?

Despite the remark about confusing people over 50, a primary branch called "master" isn't exactly an unalterable ancient tradition in version control, either. "Trunk" was common in centralized VCSes. I had to get used to "master" and "main" is at worst a lateral move.
Post reply on HN