Earlier quoted context omitted.
Nim beats D on metaprogramming.
I said 'better than any other language without macros '. Nim has macros.
And I said something else.
Nim 1.4
141–144 of 144 posts
Re: Nim 1.4
#142Earlier quoted context omitted.
The performance shouldn't be surprising, as it compiles via C (So it benefits from 50 years of work on C compilers), and almost all of the language constructs compile to essentially equivalent C code.
Python is written in C, and yet ... Compiling to C really isn't relevant. "50 years of work on C compilers" is not at all relevant--languages that compile to LLVM get all the advantages of the optimization work.
Written in C is not the same that compiled via C. If you want Python compiled via C you can use Cython, and without much surprise, you usually get a huge speed up (e.g. https://notes-on-cython.readthedocs.io/en/latest/std_dev.htm...).
Re: Nim 1.4
#143So one of the biggest improvements to my day-to-day life as a programmer was having compiler-checked nullability in Kotlin. It is the most significant feature that makes programs more reliable and code more readable compared to Java. I never want to miss it again. Why did Nim decide to allow null pointers? They must have had a very good reason, given its young age?
You need null pointers for system programming.
That said you can already declare `type MyPtr = ptr int not nil` but the compiler is still clunky on proofs and needs a lot of help.
it is planned to have a much better prover in the future and ultimately Z3 integration for such safety features: https://nim-lang.org/docs/drnim.html
Re: Nim 1.4
#144Earlier quoted context omitted.
Well Rust's complication is memory safety and the lack of garbage collector. You see similar issues in a language like Swift, but Swift lets you create a memory leak very easily if you're not aware of the issues. Which can be fine when you're just starting out, you can always learn about it later. But Rust isn't so charitable: you must learn about memory safety upfront. The plus side is that it's significantly more d…
I've only played with Rust a little bit, but I think something that often goes under-remarked is that its ownership system doesn't just give you "static GC" -- it also guarantees no data races for multithreading. This is pretty awesome.
> no data races for multithreading
This is simply not true. Rust borrow checker has no notion of memory models: i.e. sequential consistency, acquire, release or relaxed semantics.
The Tokio team needs an additional model checker to ensure no data race in Tokio:
- https://github.com/tokio-rs/loom
If you want to ensure no data races you need formal verification not a borrow checker, I've compiled my research and a RFC for Nim formal verification here: