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

131–140 of 144 posts

Re: Nim 1.4

#131

Post by [deleted] »

steveklabnik wrote: post #130
darthrupert wrote: post #118

Earlier quoted context omitted.

How many of those 48,197 have over 50 lines of code? How many of them have had changes in the last 1 or 3 years? Same questions apply to Nim too of course, but I believe Rust's focus on newbies and pretty much trivial crates/cargo new pkg addition has led to a lot of cruft in there. Not to mention squatters (even if those are probably not a majority). Also, I would challenge your classification of ARC being in the sa…

It's funny, because everyone wants different metrics. Some people would argue that no changes in the last 3 years is a sign of maturity! Anyone can argue any metric, and that's 100% fine. Any of these things can only be a really rough measure of anything.

[deleted]

Re: Nim 1.4

#132

Post by darthrupert »

steveklabnik wrote: post #130
darthrupert wrote: post #118

Earlier quoted context omitted.

How many of those 48,197 have over 50 lines of code? How many of them have had changes in the last 1 or 3 years? Same questions apply to Nim too of course, but I believe Rust's focus on newbies and pretty much trivial crates/cargo new pkg addition has led to a lot of cruft in there. Not to mention squatters (even if those are probably not a majority). Also, I would challenge your classification of ARC being in the sa…

It's funny, because everyone wants different metrics. Some people would argue that no changes in the last 3 years is a sign of maturity! Anyone can argue any metric, and that's 100% fine. Any of these things can only be a really rough measure of anything.

Yes, Common Lisp people say that a lot. I'm sure you know why :)

Re: Nim 1.4

#133

Post by moonchild »

pjmlp wrote: post #123
moonchild wrote: post #92

Earlier quoted context omitted.

The majority of all GC research goes to java and (primarily the hotspot) jvm. ZGC and kin are like the zfs of garbage collectors: insanely good, but also insanely complex and not readily replicable. It's not practical to expect somebody with fewer resources than oracle to create something similar. Reference-counting strategies are much easier to optimize; so if you have fewer resources available to throw at your comp…

You mean tracing GC, as reference counting is still GC. Adding value types and deterministic deallocation doesn't require endless GC research and was already available in languages like Mesa/Cedar and Oberon, features that Nim also has anyway.

Reference counting is still GC, but I stand by what I said that the majority of all GC research goes into java. The GP was talking about using a tracing GC—like java uses—in nim; which I argue against.

Re: Nim 1.4

#134

Post by pjmlp »

moonchild wrote: post #133
pjmlp wrote: post #123

Earlier quoted context omitted.

You mean tracing GC, as reference counting is still GC. Adding value types and deterministic deallocation doesn't require endless GC research and was already available in languages like Mesa/Cedar and Oberon, features that Nim also has anyway.

Reference counting is still GC, but I stand by what I said that the majority of all GC research goes into java. The GP was talking about using a tracing GC—like java uses—in nim; which I argue against.

Which is why Java is getting value types, as that research has proven that there is only so much that automatic escape analysis is capable of.

Bare bones tracing GC in Java were the state of the art like 25 years ago.

Java GC's are powering quite some interesting stuff, one just needs to open their mind beyond OpenJDK.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/

Still eventually, even Java would enjoy the value types and determnistic destruction capablities of languages like D, or to go to the days before Java, languages like Modula-3 and Eiffel, which they should have paid more attention to for Java 1.0.

Re: Nim 1.4

#135

Post by jibal »

TylerE wrote: post #76
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?

The performance shouldn't be surprising, as it compiles via C (So it benefits from 50 years of work on C compilers), and almost all of the language constructs compile to essentially equivalent C code.

Python is written in C, and yet ...

Compiling to C really isn't relevant. "50 years of work on C compilers" is not at all relevant--languages that compile to LLVM get all the advantages of the optimization work.

Re: Nim 1.4

#136

Post by jibal »

nepeckman wrote: post #15

Since Nim has hit the front page twice in the past day, let me just say: if you're at all curious about the language, try it out over the weekend. Nim isnt quite as simple as Zig (to compare to another compiled language with a smaller ecosystem), but the more advanced features stay out of the way until you need them. If you've worked with any static language, you probably know 80%-90% of what you need to write produc…

Nim and Zig have vastly different philosophies and targets.

Re: Nim 1.4

#137

Post by jibal »

disruptek wrote: post #111
steveklabnik wrote: post #86

Earlier quoted context omitted.

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 langau…

Nim doesn't require that you use a gc; one of its many gc options is `none`, which is, as it sounds, no garbage collector at all.

But then strings and most of the stdlib aren't available to you unless you want one big massive memory leak.

Re: Nim 1.4

#138

Post by jibal »

moonchild wrote: post #94
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…

Sibling talks about memory management. Some other notes: - Nim and rust have macros. - D has very high-quality metaprogramming (probably better than any other language without macros). - (Afaik swift and zig have fairly normal templates. I don't know as much about those.) - D and zig have compile-time function execution (think c++ constexpr on steroids on steroids). - Swift is likely to be the slowest of the bunch; l…

Nim beats D on metaprogramming.

Re: Nim 1.4

#139

Post by MrMan »

moigagoo wrote: post #120
MrMan wrote: post #98

I am using nim this week on a data file scraping project. If you can Google and write python you can just start with nim and learn as you go, very easy. I am super bummed that there is (effectively) no debugging. I am too lazy to mess with VS code to get gdb working, it should just work already. Someday, I guess. Maybe jetbrains will save us. With real IDE support nim would sweep the nations.

From my experience, there really is not that much need for debugging in the sense of adding breakpoints and attaching to a running process with Nim. Honestly, `debugEcho` suffices, give it a shot. I mean, you may need more debugging tools when your project gets large but since you're just starting with Nim, you can just relax and keep going.

Relax is my strategy right now but I am a bear of little brain and spent years with Matlab stopped in the debugger while I went to lunch. Peering into data at will is something I can't easily give up. Debug trace was how I spent the stressful young years of my programming life and for data intensive, rather than logic intensive transactional code, I don't prefer tracing.

Re: Nim 1.4

#140

Post by moonchild »

jibal wrote: post #138
moonchild wrote: post #94

Earlier quoted context omitted.

Sibling talks about memory management. Some other notes: - Nim and rust have macros. - D has very high-quality metaprogramming (probably better than any other language without macros). - (Afaik swift and zig have fairly normal templates. I don't know as much about those.) - D and zig have compile-time function execution (think c++ constexpr on steroids on steroids). - Swift is likely to be the slowest of the bunch; l…

Nim beats D on metaprogramming.

I said 'better than any other language without macros'.

Nim has macros.

Post reply on HN