281–290 of 308 posts
Earlier quoted context omitted.
Nim is however not alone, with Haskell using C--, Eiffel using C (nowadays C++ as well) and Unity's IL2CPP/Burst.
C-- is very different from C. 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.
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…
Lisp works slightly different. The macro form is an expression (a list) with the macro operator as the first element. The next elements in the expression can be anything as data.
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…
The malloc/free equivilents are in the system module: https://nim-lang.org/docs/system.html#alloc%2CNatural
While Nim is a much better python, you cannot use python modules with Nim (pushing strings to a python interpreter does not count as such), so you need some man-years to build a reasonable software collection. Haxe had another approach. Create a library and transpile it to be used with Lua/Python/ Java and other options.
Have you seen Nimpy[0]? It allows for a nice integration between Nim and Python. At least for the examples I have tried, it could be used in place of Cython, when there's a need for extra speed in some hot loops and similar situations. [0] https://github.com/yglukhov/nimpy
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…
You can do that in Nim in a readable way.
import macros
macro genMacro(name: untyped): untyped =
result = quote do:
macro `name`: untyped =
result = quote do:
echo "Foo"
genMacro(bar)
bar # Generate and perform the echo
In one of my projects I use a macro to parse a set of types for fields and generate constructor macros for them.
The generated constructor macro passes through the parameters it's given to the default built-in constructor but does some setup before.
The final generated code is a normal built-in construction without proc calling yet with special fields initialised automatically.
Earlier quoted context omitted.
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.
Sorry I was wrong it's asm.js for rust. Scala does have an amazing first party backend that I love using
Earlier quoted context omitted.
Nim performance is really really good. Like, maybe C - 5%. Comparable with stuff like Rust or D... way way faster than Go or anything interpreted.
I think it depends on the nature of the code. For a side project of mine, I recently re-wrote the same code in a dozen or so languages. The application reads input data from text file and does a bunch of conversions to integers and floats (atoi and atof). It then runs through an algorithm that does calculations and identifies proper actions. Finally, it writes the output data as formatted text file. Regardless of imp…
Earlier quoted context omitted.
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…
> Something I don't see here is macros that generate other macros, but the question is how much you really want that anyway You can do that in Nim in a readable way. import macros macro genMacro(name: untyped): untyped = result = quote do: macro `name`: untyped = result = quote do: echo "Foo" genMacro(bar) bar # Generate and perform the echo Surprisingly I've actually used this kind of thing! In one of my projects I…
Funny, I did a similar thing! :)
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…
> I'm not sure how big of an issue this is in reality I agree - embedded programming is a sufficiently separate world that you'll always need a different foundation with different assumptions. Rust which doesn't have a GC at all, but stillhas this problem to some extent. On a microcontroller you generally don't want to use the standard library with all its assumptions about heap allocations always succeeding. This is…
I agree, but there is a big difference between not being able to use almost any library, and being able to use most libraries.
There are many many libraries on embedded Rust, and my embedded and not embedded projects do share many libraries.
Earlier quoted context omitted.
Nim compiles to C, so you can use any existing C toolchain to generate a native executable for whatever platform you care about. That's a big advantage over Rust, D, OCaml, and similar languages without this feature.
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).
If you care about the assembly a piece of code generates, you can just look at that.
The generated C code that Nim emits looks like what it is: boring automatically-generated C code.
If you wanted to debug the compiler, you could take a look at that, but most users don't have to.