191–200 of 308 posts
Earlier quoted context omitted.
Fortran has had pure functions and subroutines since well before any of the cool languages. Not that I recommend it in particular.
Fortran had nearly everything before nearly all languages. And I'm sure Fortran was cool back in the day, I'm sure it's due a comeback any day now.
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…
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 why 'nostd' and libraries like heapless exist.
Earlier quoted context omitted.
And it turns out Crystal 0.31 [1] is released! And it is ( or should be ) closing to 1.0 release as well, once Windows Support and MultiThreading matures. May be 2020? On the list of languages I only know the first few up to Zig, will need to check out the others. There is also one noticeable missing and that is Elixir. [1] https://crystal-lang.org/2019/09/23/crystal-0.31.0-released....
Curious why you're adding Elixir in this list ? It operates is in a completely different space than nim / zig, as far as I know (Not statically checked, heavy but powerful runtime, much "higher level" abstractions, etc...) Not to prevent you from trying it, of course - to each and everyone their own...
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…
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 strength. It's just so productive! It puts the fun back into a day job.
It's as easy to develop in as Python (great type inferrence and strong, static typing), but fast as well written C, yet (AST based) metaprogramming allows it to be higher level than even Python.
On top of low developer friction, it outputs stand-alone executables for effortless distribution. It's my first choice for scripting, for CRUD work, web stuff, game development, and embedded coding.
Doesn't hurt that it can compile to c, c++ and javascript so you can write your backend and frontend in the same language.
Also since the FFI is so great, you can effortlessly use the entire library ecosystem of C and C++.
Of course, it's not perfect, but for me it's getting pretty close.
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…
I think that the [nim github tagline](https://github.com/nim-lang/Nim) expresses well the philosphy: "Nim is a compiled, garbage-collected systems programming language with a design that focuses on efficiency, expressiveness, and elegance (in that order of priority)."
also Araq's blog post on 1.0 explains well how the guiding principles remained the same over time:
"When I started Nim's development I had a small simple language in mind that compiles to C; its implementation should not be more than 20,000 lines of code. The core guideline has always been that Nim should be a small language with a macro system, which should be capable of extending Nim with all the features that the small core is missing.
The current compiler plus the parts of the standard library it uses has roughly 140,000 lines of code, runs on a plethora of operating systems and CPU architectures, can also compile Nim code to C++ and JavaScript, and Nim's meta programming capabilities are top of the class. While the language is not nearly as small as I would like it to be, it turned out that meta programming cannot replace all the building blocks that a modern language needs to have.
For example, while Nim manages to implement async via its macro system, the macro system needs to be able to compile code into a state machine. And these state machines need some form of goto and a way to capture their environment. So Nim's core needed to grow so called "closure iterators" to enable this.
Furthermore, we don't really know yet how to leverage a macro system in order to give us extensibility on the type system level, so Nim's core needed generics and constraints for generics."
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).
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 according to Nim's CGen spec. The compiler is fully open source though and easy to dig into.
Having said that, the CGen output is fairly readable if you're familiar with C and I must say I've investigated it when I wasn't sure how something was generated.
Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :) It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work. Grab a copy he…
Earlier quoted context omitted.
> yet another slightly different take on Rust or Go From Wikipedia article of each language: Rust: First appeared July 7, 2010; 9 years ago Go: First appeared November 10, 2009; 9 years ago Nim: First appeared 2008; 11 years ago
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…
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
The only other type that use GC is `seq` (equivilent to C++ vectors) IIRC.
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.
However in my experience all you need to do is just not use refs, and make your own ptr based seq (there's probably a library for this but its trivial to implement).
Nim's GC is thread-local (so no stop-the-world issues), only triggered on allocate, and has realtime support via enforcing collection periods. Plus you can use other GCs if you wish (eg Boehm).
More info about the GC here: https://nim-lang.org/docs/gc.html
Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :) It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work. Grab a copy he…
Aw, I missed it by a couple of hours.. :/