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

231–240 of 308 posts

Re: Nim 1.0

#231

Post by mumblemumble »

alashow wrote: post #123
mumblemumble wrote: post #29

Earlier quoted context omitted.

At first blush, it's easy to describe Nim as C-flavored Python, but I'm not sure that quite captures it. The syntax is similar, but that's about where the similarities end - Python is deeply, fundamentally a dynamic language, and Nim one of the more firmly statically typed non-functional languages out there. You could also describe it as being competitive with Rust, but with more compromises for the sake of developer…

We already got a Java-killer: Kotlin

Don't get me wrong; Kotlin is a great language and, if I have to work on the JVM, it's one of my top two picks.

But, being a JVM language, it's still stuck with all of the Java shortcomings that I had listed before: Achieving a decent level of type safety is impossible, the FFI is still a pain to use, and you've got to go through contortions to get really good numeric performance. Because all of those problems are characteristics of the JVM's run-time environment, not the language you're using to target it.

Re: Nim 1.0

#232

Post by PMunch »

marble-drink wrote: post #205
arc776 wrote: post #194

Earlier quoted context omitted.

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

Talk of metaprogramming intrigues me. I'd like to hear what a Lisp user makes of it because I find non-Lisp users are usually amazed by any metaprogramming at all and can't be as critical about it.

Not a Lisp user, but a heavy Nim macro user. Nim macros are AST based, which means that after the parser part of the compiler have read the code and created a tree structure of it your macro is called on this tree. Then you can modify this tree to your hearts desire and return a new tree that the Nim compiler will splice back into the main tree before continuing. This means that you rewrite pretty much anything into pretty much anything else. You also have access to reading files on the machine, or doing pretty much anything else that Nim offers. For examples of what you can do with it you can have a look at my macro to create GUIs: https://peterme.net/cross-platform-guis-and-nim-macros.html, my article on how I use macros to create more read- and maintainable code: https://peterme.net/metaprogramming-and-read-and-maintainabi... or perhaps see how Protobuf was written as a string parsing macro which reads a Protobuf specification and spits out all the types and procedures you need to use it: https://github.com/PMunch/protobuf-nim

Re: Nim 1.0

#233

Post by narimiran »

peteforde wrote: post #150
stakhanov wrote: post #41

Earlier quoted context omitted.

I disagree in quite a few respects. I think there's not much merit in discussing "C-flavored Python" as a description of nim, as that description seems just wrong. Aside from significant whitespace, I don't find that many similarities with Python syntax. Describing Nim as non-functional is misleading. Nim does have functional constructs and is a mixed-paradigm language involving both procedural and functional element…

In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.

> In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.

Probably because most people are more familiar with Python than Ada and Modula (combined) ;)

I guess it depends on your previous experience. Some people will only see Python, others might think of Nim and its syntax as "Pascal for 21st century" (fun fact: the original Nim compiler was written in Pascal).

Re: Nim 1.0

#234

Post by pjmlp »

lmm wrote: post #218
arc776 wrote: post #199

Earlier quoted context omitted.

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…

I think the biggest issue is that most equate GC with Java/Smalltalk style, instead of GC Modula-3/C# style.

Re: Nim 1.0

#235

Post by PMunch »

guggle wrote: post #217
PMunch wrote: post #188

Earlier quoted context omitted.

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.

Audio programming? And why is it frowned upon? If it is because of the Java-like GC freezes that is something you can ensure will not happen in Nim by turning on manual control and only running it when its suitable.

Re: Nim 1.0

#236

Post by PMunch »

peteforde wrote: post #212
PMunch wrote: post #175

Earlier quoted context omitted.

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.

Well thank you :) Meet up at FOSDEM and you can buy me a sandwich there!

Re: Nim 1.0

#237

Post by balfirevic »

pjmlp wrote: post #234
lmm wrote: post #218

Earlier quoted context omitted.

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

I think the biggest issue is that most equate GC with Java/Smalltalk style, instead of GC Modula-3/C# style.

Doesn't .NET (and C# with it) have stop-the-world GC, very similar to Java?

Or do you mean something else?

Re: Nim 1.0

#238

Post by pjmlp »

alashow wrote: post #123
mumblemumble wrote: post #29

Earlier quoted context omitted.

At first blush, it's easy to describe Nim as C-flavored Python, but I'm not sure that quite captures it. The syntax is similar, but that's about where the similarities end - Python is deeply, fundamentally a dynamic language, and Nim one of the more firmly statically typed non-functional languages out there. You could also describe it as being competitive with Rust, but with more compromises for the sake of developer…

We already got a Java-killer: Kotlin

Kotlin is no Java killer.

The only KVM in town is Android.

Re: Nim 1.0

#239

Post by pjmlp »

mumblemumble wrote: post #231
alashow wrote: post #123

Earlier quoted context omitted.

We already got a Java-killer: Kotlin

Don't get me wrong; Kotlin is a great language and, if I have to work on the JVM, it's one of my top two picks. But, being a JVM language, it's still stuck with all of the Java shortcomings that I had listed before: Achieving a decent level of type safety is impossible, the FFI is still a pain to use, and you've got to go through contortions to get really good numeric performance. Because all of those problems are ch…

Most of those Java shortcomings are in the process of being fixed, while still enjoying one of the best language eco-systems currently available, with libraries for almost any kind of problem domain.

Re: Nim 1.0

#240

Post by mumblemumble »

lmm wrote: post #218
arc776 wrote: post #199

Earlier quoted context omitted.

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…

So, the full gist is: Nim uses automatic reference counting with cycle detection. If you want to, you can disable the cycle detection, perhaps only temporarily. The compiler flag for turning GC off doesn't actually turn off all GC, IIRC. It still does automatic reference counting, and it can still do cycle detection, it's just that you need to initiate it manually.

The language does have pointers, and will let you do any C-style memory unsafe whatever you want to do with them. However, it doesn't have any library calls that I'm aware of that are equivalent to C's malloc() and free(). You'd have to supply your own.

There are also ambitions, of introducing real non-GC memory-safe memory management. Probably something along the lines of how Rust does it. Those haven't come to fruition yet, though.

So, long story short, yes you can completely disable GC, but I think that its capabilities on that front are somewhat overstated.

Post reply on HN