Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.0

nim-lang.org

Post reply on HN
Print view View original

211–220 of 308 posts

Re: Nim 1.0

#211

Post by peteforde »

galangalalgol wrote: post #201
nimmer wrote: post #176

Earlier quoted context omitted.

> appears to be yet another slightly different take on Rust or Go Nim is nowhere close to that. Most people describe it as a very fast statically typed Python.

Also nim came first, also, rust and go aren't even targeting the same use cases. Rust is for performant systems coding or webasm with far fewer footguns than c or c++. Go is for back end software with less cruft or boilerplate or latency than java but about the same throughput as java. It sounds like nim is "i just wan to get this working but I'm worried python wont run fast enough."

Okay, but you're ignoring the thrust of my question, which is "why do I care". Your name is nimmer so it's safe to say we understand why you care, but help me understand why I care about the 3rd-runner:

https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F09g...

I'm only comparing it to those languages because of the direct comparisons many others have many in this thread. And popularity != quality, but age is also a very poor measure of success.

Re: Nim 1.0

#212

Post by peteforde »

PMunch wrote: post #175
peteforde wrote: post #151

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

Let's try to fill out some of this grid: Who started this? - That would be Andreas Rumpf, or Araq as he is known on IRC Is it corporately affiliated? - No, it was created by Andreas, and has stayed independent. But it has corporate backing, which helps pay for development, and they do get a certain prioritisation in what gets implemented. But no closed door stuff. What languages is it similar to? - Depends on what ki…

This is an AMAZING answer. I'm sad I can't buy you a sandwich.

Re: Nim 1.0

#213

Post by littlestymaar »

pdimitar wrote: post #174
gtycomb wrote: post #109

Earlier quoted context omitted.

I heartily wish that you continue learning Rust, another significant contribution to open source languages. What has been already commented, things such as borrow/checker are humps you work through and it will work out for you eventually. The other challenges are some of your enterprise 3rd party integrations with the outside world, some of which may again demand your time if they are still in beta, etc. Also, the or…

Is there a site(s) where there is specified how to represent more complex data structures while making the borrow checker happy?

When you've internalized its rules, the borrow checker isn't too complicated to keep happy (you may need to use stuff like RefCell and Rc though). It takes some time though, and this tutorial helped me a lot in the beginning: https://rust-unofficial.github.io/too-many-lists/

Re: Nim 1.0

#214

Post by lmm »

arc776 wrote: post #197
lmm wrote: post #187

Earlier quoted context omitted.

I see that as a downside, personally. It makes it a lot harder to understand what guarantees there are about with a given piece of code (rather than being able to look at the assembly and the language's own compiler, you would have to also understand C's rather odd semantics and the complex behaviour of many C compilers).

This is a bit like saying you wouldn't use LLVM languages because of the semantics of IR, or that you have to understand the guarantees IR provides, isn't it? Ultimately if you're really interested in performance, regardless of the stages of compilation, the juice is the machine code output at the end. In terms of guarantees, those should be satisfied higher up in the language itself, with C generation being output a…

> This is a bit like saying you wouldn't use LLVM languages because of the semantics of IR, or that you have to understand the guarantees IR provides, isn't it?

Those languages tend to be a lot simpler than C, both in terms of what constructs they offer and in terms of how simply they translate into (platform-specific) assembly language. I'm not against the idea of intermediate languages in general, but IME C is the worst of both worlds: more complicated than most high-level languages and most assembly languages.

> In terms of guarantees, those should be satisfied higher up in the language itself, with C generation being output according to Nim's CGen spec. The compiler is fully open source though and easy to dig into.

The problem is being confident that those guarantees are preserved all the way down. It's very hard to be confident of the properties that any given piece of C code has, because it's extremely rare for C code to be 100% standards compliant and different compilers do radically different things with the same code. And it's hard to reason about the effects of changes because C compilers are so complicated: maybe you understand the Nim compiler and can see how two similar Nim functions will generate similar C code, but that doesn't help you much when two similar C functions can be compiled to radically different assembly (which happens a lot).

Re: Nim 1.0

#215

Post by egeozcan »

_0ffh wrote: post #95
nfrankel wrote: post #20

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

For me, personally, the biggest points for Nim are: - "Transpiled" to C, with some options regarding runtime library, which means you can target any uController out there - Good metaprogramming support - Static and _strong_ typing - Consequently, precise type aware function dispatch - Type inference - Good generics Also, more stuff like covariants and contravariants and... maybe you just have a look-see? ;-)

There are "concepts" which are like generics but still experimental. Are there any other generic programming facilities in nim?

https://nim-lang.org/docs/manual_experimental.html#concepts

Re: Nim 1.0

#216

Post by wycy »

gjm11 wrote: post #189
ranit wrote: post #180

Earlier quoted context omitted.

> ... something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) FORTRAN has this distinction since the beginning.

I think that's wrong. Isn't Fortran's procedure/function distinction between things that return a value and things that don't , rather than between things without side effects and things that might have side effects ? The latter is what Nim's func/proc distinction is about. (Modern Fortran does have a pure keyword meaning "no side effects", but that wasn't there "since the beginning".) [EDITED to add:] I checked in t…

I can confirm, Fortran subroutines are essentially just void functions, unless specifically declared pure.

Despite working in Fortran every day, I never knew about statement functions before. Thanks.

Re: Nim 1.0

#217

Post by guggle »

PMunch wrote: post #188
fluffything wrote: post #181

Earlier quoted context omitted.

> Yes, by default Nim has a garbage collector, Does the standard library and all other user libraries work with the garbage collector turned off, or do I have to use a different ecosystem for those applications?

They work only as long as they don't use any garbage collected types (the compiler will warn you of this when you turn the GC off). Unfortunately this means most libraries are out, and you have to do your own thing. Turning the GC off is more meant as a way to use Nim on micro-controllers and for things like kernels and such. In this case many libraries that aren't written for this use-case doesn't really make sense…

> so I'm not sure how big of an issue this is in reality.

I have audio programming in mind. Not that you can't do audio programming in GC-enabled languages, it's just that's it's quite frown upon in this circle (for good reasons). I'm sure there are workarounds though.

Re: Nim 1.0

#218

Post by lmm »

arc776 wrote: post #199
lmm wrote: post #170

Earlier quoted context omitted.

The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand…

Basically you only use GC if you declare something using a GC type. type # A `ref` type is GC and will use the heap. MyGCType = ref object fieldA: int # Otherwise ALL types are stack based. MyStackType = object fieldA: int Also GC is deferred, so if you use a GC type in a local scope that doesn't escape, you don't pay for reference counting. The only other type that use GC is `seq` (equivilent to C++ vectors) IIRC. T…

> Basically you only use GC if you declare something using a GC type.

So similar to C# (2000)? A useful feature to be sure, but not a major innovation.

> The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though.

Running with the GC off (and accepting the leaks) was already a standard managed-language technique though.

> Nim's GC is thread-local (so no stop-the-world issues)

Well no wonder it has nice properties if it avoids all of the hard problems! What happens when you pass references between threads?

> only triggered on allocate, and has realtime support via enforcing collection periods.

Your link describes the realtime support as best-effort, and implies that it doesn't work for cycle collection. So honestly this doesn't seem to offer much over e.g. the tuneable GC of the JVM (which admittedly made a massive mistake in choosing defaults that prioritised batch throughput rather than latency).

I do appreciate the information, and hope this isn't coming off as overly confrontational. But honestly it sounds like Nim is overselling things that are mostly within the capabilities of existing managed languages (maybe even behind them if the "GC" is only thread-local and/or not cycle-collecting).

Re: Nim 1.0

#219

Post by szemet »

kalekold wrote: post #208

The binary sizes that Nim produces are as usual misrepresented. D and C will blow it out of the water. Here's some D code: import core.stdc.stdio; extern(C) void main() { printf("Hello, World!\n"); } Compile with: $ dmd -betterC main.d $ ls -h main -rwxrwxr-x 1 user group 8.5K Sep 24 12:39 main

I guess the examples use the default std libs, and runtimes of the languages. So in this sense your D example is the misrepresentation, by directly calling libc.

If these kinds of low level size optimizations are enabled then both Nim and Rust can be more than 50 times smaller than your D example ;) :

150 byte Nim: https://hookrace.net/blog/nim-binary-size/

151 byte Rust: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...

Re: Nim 1.0

#220

Post by pletnes »

benj111 wrote: post #161
pletnes wrote: post #159

Earlier quoted context omitted.

For some reason, a lot of fortran programmers insist on screaming, even though it’s been optional for 3 decades. I mostly program in python these days...

Backwards compatibility.

I’ve never encountered a compiler that needed ALL CAPS. I guess some people saw old code and just emulated that.
Post reply on HN