271–280 of 308 posts
Earlier quoted context omitted.
> To make money? Not at all. Nim aims to achieve the expressiveness of Python , the speed of C, the programmability of LISP.
What about kotlin-native?
Earlier quoted context omitted.
Scala and rust both compile to JS too I think.
Do they have first-party JS backends though? I think that's what sets Nim apart, the Nim compiler includes the JS backend which means the JS backend is always up to date with the latest Nim developments.
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.
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…
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…
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…
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 wouldn't say separating the GC at the type level is a major innovation, but as you say it's useful. I don't think Nim really sells itself on a groundbreaking GC implementation either. However it does give you a fast GC with enough flexibility should you need it. For example, the Boehm GC is not thread-local. GC types are copied over channels with threads, or you can use the usual synchronisation primitives and pass…
Languages like Nim allow for having the productivity of relying on GC's help, with language features for performance freaks available, when they really need to make use of them.
Java not offering a Modula-3 like feature set has tainted a whole generation to think that GC == Java GC.
EDIT: grammar errors
Earlier quoted context omitted.
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…
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.
Judging by some of the comments here, it seems like the macro system has a similar approach as Lisp's macro system, which is also AST-based. Something I don't see here is macros that generate other macros, but the question is how much you really want that anyway (when I did that, I thought the syntax was horribly complicated because of all the quoting). I know Lisp also has reader macros (they run before the parser) that allow you to effectively change the language syntax, but I didn't use those.
Earlier quoted context omitted.
> 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…
Nim is however not alone, with Haskell using C--, Eiffel using C (nowadays C++ as well) and Unity's IL2CPP/Burst.
Indeed several languages compile to C; I regard that as a downside for all those languages. I'm not sure what your point is?
Earlier quoted context omitted.
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.
Disclaimer: I only did a hobby project in Lisp once. But I did use some of the macro functionality. Judging by some of the comments here, it seems like the macro system has a similar approach as Lisp's macro system, which is also AST-based. Something I don't see here is macros that generate other macros, but the question is how much you really want that anyway (when I did that, I thought the syntax was horribly compl…