Live data from Hacker News

Pros and Cons of Nim

onlinetechinfo.com

81–86 of 86 posts

Re: Pros and Cons of Nim

#81
post #74

Earlier quoted context omitted.

You can and you should use Java libs where appropriate. It's always nice to have pure idiomatic Kotlin but calling Java from Kotlin is already idiomatic. As for multi platform io they are working on it https://github.com/Kotlin/kotlinx-io

But the discussion was about Kotlin AOT. Not kotlin JVM.

Right but using graal native instead of kotlin native you can have kotlin calling Java code and compiling to a binary

Re: Pros and Cons of Nim

#82
post #49

Earlier quoted context omitted.

While Araq is BDFL and is still doing most of the implementation for Nim, there are nontrivial contributions from others, and commercial sponsorship at this point. And with respect to the ecosystem-at-large, there are tens of contributors and a very healthy package repository: nimble (package manager) written and maintained by dom96; arraymancer (tensor+array+nn) written and maintained by mratsim; an up-and-coming th…

I see one of the top jobs of the dictator as exercising reputation and credibility to gather and delegate expert work to expert lieutenants. If the years pass and you're still the lonely dictator...

But duties are being delegated and Araq isn't alone. For example multithreading has been delegated to the amazing mratsim: https://github.com/mratsim/weave . There are multiple people helping with the new move-semantics-based runtime: https://github.com/nim-lang/Nim/issues/14224 Documentation is delegated to narimiran who also has his fair share of commits: https://github.com/nim-lang/Nim/graphs/contributors?from=201...

Re: Pros and Cons of Nim

#83
post #58

Earlier quoted context omitted.

I'm hopeful that Kotlin/Native will improve in these areas (excepting the last one) but: * Faster compilation. * Tooling is less memory-hungry. * C++ interop. * Macros.

Why macros vs decorators?

I think you basically covered it in your other comment. Macros are much quicker and easier to write than compiler plugins or annotation processors, but they are difficult for the IDE to understand. So it's a trade-off where Nim and Kotlin both make reasonable, but quite different, choices.

Re: Pros and Cons of Nim

#84
post #31

Earlier quoted context omitted.

> - It has a bus/lottery factor of 1. What was Rusts early years like? Was it one developer for the first part? I'd imagine this is not a big deal in the early days, where the benevolent dictator is as much the language as the project itself, not all technology adoption happens on the same timelines. Matz with Ruby took a long time to become super popular, Rich Hickey with Clojure seemed to be a powerhouse even as th…

When Rust 1.0 was released it had in the order of hundreds of developers doing work here and there. When Rust started as a hobby project it was a one man effort, but it was also a project with ~1 user. It grew developers before actually growing users, and for a while, it had more developers than users.

Rust is design by committee with complicated and large syntax area and to solve one problem of memory safety created a mountain of borrow checker syntax and a steep learning curve.

So only time will tell if BDFL based language comes up like Linux or design by committee like language. Right now Rust is not that significant like Nim and Zig so all have a chance to come up.

Once there are substantial software written in them like C or C++ than only will know, right now among modern language only golang and Swift reached that stages as being significant systems programming language in spite of GC. Indeed I doubt if Rust will be as revolutionary as Lisp or Haskell or Smalltalk in terms of contributions for the development of compilers and language designs.

Re: Pros and Cons of Nim

#85

Earlier quoted context omitted.

When Rust 1.0 was released it had in the order of hundreds of developers doing work here and there. When Rust started as a hobby project it was a one man effort, but it was also a project with ~1 user. It grew developers before actually growing users, and for a while, it had more developers than users.

Rust is design by committee with complicated and large syntax area and to solve one problem of memory safety created a mountain of borrow checker syntax and a steep learning curve. So only time will tell if BDFL based language comes up like Linux or design by committee like language. Right now Rust is not that significant like Nim and Zig so all have a chance to come up. Once there are substantial software written in…

Not bad for a bot, tell your master that your coherency levels are well down.

Re: Pros and Cons of Nim

#86
post #55

Earlier quoted context omitted.

Why use nim over Kotlin with AOT?

I'm not familiar enough with Kotlin to give a real answer, but from what I do know the following might be relevant: * Backends: Nim compiles to JS both directly, and indirectly (emscripten) with various trade-offs (e.g. 64 bit ints require emscripten). It also compiles to C, C++ and Objective C giving you the simplest most efficient FFI to those languages one can hope for (including e.g. exception handling) while at…

>> Metaprogramming: Nim's metaprogramming ability is second only to Lisp[0], ...

There are some other languages that have metaprogramming abilities equal to Lisp. For eg. Rebol, Red & Forth.

I think some people would also consider Prolog and Smalltalk to be in the same ballpark.

And there are languages that would also claim to be second only to Lisp, for eg. Julia, Elixir, Raku/Perl6 and probably some others to!

Post reply on HN