51–60 of 132 posts
I tried it and it is easy and fast. But the ecosystem is still not very large. I think that it should support building libriaries directly accessible from python including passing numpy arrays directly to nim. That would make a lot of people to jump right in creating libraries and thus extending its own ecosystem.
What exactly does that mean? Does the end-user of my binaries require a C compiler? Which operating systems are "we" interested in. I'm interested in Windows and specifically Windows CE.
> That means you end up with a single binary that depends solely on the standard C library, which we can take for granted on any operating system we're interested in. What exactly does that mean? Does the end-user of my binaries require a C compiler? Which operating systems are "we" interested in. I'm interested in Windows and specifically Windows CE.
I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.
Why would you say it's not competing with D and Rust? Performance-wise Nim should be in the same ball-park, and you can do systems programming in it. For me Nim is a universal language which I can use for almost anything.
It's easy to write (a) an unsafe language that has no GC, or (b) a safe language that relies on GC for safety. It's also easy to write a language that is in category (b) but lets you drop down to category (a) in an unsafe dialect. It's a very difficult problem to write a safe language that does not rely on GC, and I know of no other industry language that has done it. Unfortunately, people often lump Rust into categories (a) or (b), without realizing that what makes it interesting is that it isn't in either. Nim may be in category (b) (if the thread safety issues in the GC have been solved, or you use Boehm, or your app is solely single-threaded) with the ability to drop down to category (a), but it is not in Rust's category.
Earlier quoted context omitted.
This is not an unique feature today, you can do the same in D and Rust and even C++14, I think.
Rust is planning to add that eventually, but in the meantime: fn foo(n: i32) -> i32 { n * 2 } const y: i32 = foo(3); error: function calls in constants are limited to struct and enum constructors [E0015]
Earlier quoted context omitted.
Better metaprogramming, significant whitespace, generics, etc.
> significant whitespace That's not an advantage
Yes it is. I have been programming Python, C++, Java and C# over the last 10 years.
Python's convention for white-space beats the other ones hands down both when writing and reading large code bases.
Earlier quoted context omitted.
If (and I haven't been interested enough in Nim to investigate) it is indeed compiled to C and then compiled down to platform specific code, unless they are implementing functions differently, nested functions are not a standard part of C; they are a compiler extension (which GCC supports). Not necessarily a problem, but unless implemented as something other than nested functions in C, there may be some portability i…
As unwind suggested, they just get transformed down to global functions with unique names. Here's the actual C code generated: https://gist.github.com/def-/0fe87bf1d35102c62d3b#file-nest-...
Nim has some good ideas but I can't get over the syntax: - Significant whitespace, but tabs are forbidden - No block comments, save for `discard """ ... """` - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)
In the language design stages who in the world thought this would be a good idea? Even PHP doesn't do that.
Earlier quoted context omitted.
Rust is planning to add that eventually, but in the meantime: fn foo(n: i32) -> i32 { n * 2 } const y: i32 = foo(3); error: function calls in constants are limited to struct and enum constructors [E0015]
You can do it with a compiler plugin; I suspect that's what the parent comment was referring to. Admittedly compiler plugins are pretty experimental at this time.
> That means you end up with a single binary that depends solely on the standard C library, which we can take for granted on any operating system we're interested in. What exactly does that mean? Does the end-user of my binaries require a C compiler? Which operating systems are "we" interested in. I'm interested in Windows and specifically Windows CE.