Live data from Hacker News

Nim 2.0

nim-lang.org

131–140 of 213 posts

Re: Nim 2.0

#131

Earlier quoted context omitted.

or even just std::vector some_seq{1, 2, 3, 4, 5, 7}; nowadays (for a value of nowadays that is 5 years old for GCC and 6 years old for Clang)

Indeed there's no question that Nim is basically following C++'s lead on this. Nim iirc always had constructors and destructors. Final piece of the puzzle is move semantics, and I recall a blog post where Araq came up with something very similar.

yes, Nim has move semantics, but takes care of you more than c++ does. for example, if you use an object that was previously moved, you dont get garbage, the compiler turns the first move into a copy (and tells you)

the relevant docs are here: https://nim-lang.org/docs/destructors.html

Re: Nim 2.0

#132
post #90
post #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 scaffoldin…

>Then writing a web app with backend and frontend in the same efficient language. How does that work? What i mean specifically is how convenient is it to use js interop in dev time, and not just compile nim to js as a standalone lib? Can we simply call something like browser API directly from Nim (Or with fairly simple wrapper)?

I think you can just import dom and get access to browser APIs.

Re: Nim 2.0

#133

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.

[deleted]

Re: Nim 2.0

#134

As someone who doesn't know much about Nim: Improved type inference ... let foo: seq[(float, byte, cstring)] = @[(1, 2, "abc")] This looks like a normal type declaration to me, why is there any inference involved?

It looks simple but in a typed language it's actually somewhat tricky. The compiler needs to infer that the 1 is a float type, 2 is a byte, and compile it appropriately. Previously Nim didn't do any "reverse" type inference so you'd need to say `@[1'f64, 2'byte, "abc")]`. That was because it's a constraints problem that can become exponentially expensive to solve. Exploding compile times in Rust and Swift are good ex…

> It looks simple but in a typed language it's actually somewhat tricky.

But that example looks about as simple as it can be, so I clearly must miss something.

> The compiler needs to infer that the 1 is a float type, 2 is a byte, and compile it appropriately.

And I don't understand _why_ it has to infer anything, as the type is explicitly declared. I mean, there are 2 possibilities: * 1 is both a valid integer and a float literal => Nim needs the type declaration on the left to unify the type (from "integer or float" or "numeric" or whatever the type checker inferred) to `float`. * 1 is not a valid float literal (but an integer) => the type is not inferred, but implicitly converted to `float`. In both cases the solution does not involve inference?

Re: Nim 2.0

#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

Re: Nim 2.0

#136

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?

You can check out the list of Nim packages at https://nimble.directory

Re: Nim 2.0

#137

Earlier quoted context omitted.

I have a shortlist of pain points: - Tooling is not great. The language server has a tendency to silently crash on occasion, and it's no rust-analyzer to begin with. A tooling rewrite has been delayed behind proper incremental compilation, which has been delayed behind ARC/ORC... - Interfaces ("concepts") are experimental and there are two differing implementations. - It lacks proper sum types and structural pattern…

> It lacks proper sum types We've talked about this before! You know it has sum types, just not the variation you want.

I know, I know! I do very much like the "type wrapper" approach more than the "object variant" approach.

Perhaps in the future we'll simply have both and have no reason to debate ;-)

Re: Nim 2.0

#138

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?

This provides a good overview of packages for various applications: https://github.com/ringabout/awesome-nim

I think most of them are available via nimble.

Re: Nim 2.0

#139

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?

The ecosystem is smaller than some, but wrapping libraries is mostly automatable, and there is tooling to assist interop with python, c, and c++

Re: Nim 2.0

#140
post #4

Anyone have working experience with Nim and Zig? I'd love to hear how they are similar and contrast. I'd also would like to see some idiomatic web server benchmarks between the two (now with Nim v2).

There are a lot of features in Nim that are basically the polar opposite to Zig's values; macros/templates as opposed to comptime which has no real capability of just inserting random code and the very pervasive naked imports (functions/methods can come from anywhere) that are all over the place come to mind, as opposed to the explicit imports and qualified names you would have to use in Zig (or deconstruction of imports to get the bare names, making it obvious where an identifier is coming from).

On top of that you have only indirect control over memory allocation and deallocation, which goes completely against Zig's values where custom allocators are used and everything that allocates should take an allocator as an argument (or member in the case of structures). In contrast to that there isn't even the concept of an allocator in the Nim standard library.

I would say that my experience with Nim has made me fairly certain that Nim has absolutely no desire to make things obvious but rather chooses convenience over almost everything. It's not so much a competitor (in performance or clarity) to Odin or Zig as it is a competitor to Go or something with a much higher-level baseline.

On top of all of this it doesn't really have tagged unions with proper support for casing on them and getting the correct payload type-wise out of them, which is an incredibly odd choice when all of its competitors have exactly that or an equivalent.

Overall I would say that coming from Odin or Zig (or Go) and actually liking those languages it's very hard to like Nim. I could imagine that if someone came from a much higher-level language where performance is nearly inscrutable anyway and nothing is really obvious in terms of what it's doing, Nim would feel like more of the same but probably with better performance.

Edit:

Often while reading the Nim manual, news and forum posts, etc., I get the sense that Nim is really just an ongoing research project that isn't necessarily trying to solve simpler problems it already has along the way. If you look at some of the features in this announcement, it's hard to see anyone ever asking for them, yet here they are. In many ways it's way worse than Haskell, which often gets derided as "just a research language". A lot of what Nim has makes for a much worse experience learning and using the language and I'm sure it doesn't get easier in the large.

Post reply on HN