Seeing that the team behind Nim is accepting Bitcoin is not a good sign.
tin foil hat andy right here
Nim 1.6.2
51–60 of 162 posts
Re: Nim 1.6.2
#52Earlier quoted context omitted.
Thank you for the link but it doesn't address the issue I have. It's not about types, or about the compiler being "unsure". It's about me, as a developer, reading code someone else wrote, not knowing directly what package a call is from. I need to leave my current context to have the answer. I can do `mypackage.mymethod` but it will only be in my own code, because it's not the convention
There are plenty of cases in Python and similar languages where it's not clear where a method is defined, consider `myClassInstance.myMethod`, how do you find its definition? You do not immediately know which class it belongs to, nor where that class is defined. This is especially the case when you've got classes inheriting from multiple levels of other classes.
To put things in context, I don't come from a Python background but from a Go background, where methods are always called with their package (unless it's in the current package). I got used to it because it makes the context clear.
Re: Nim 1.6.2
#53Earlier quoted context omitted.
Nothing says "realistic benchmark" quite like the "-d:danger" flag.
It's the normal compilation flag for performant code. The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.
I suppose the makers of Nim named that flag for a reason - giving up memory safety by disabling bounds/overflow checks should be never be the default for networked software in a production setting, so benchmarking in that mode would paint an unrealistic picture.
What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable all brakes". Which, to be fair, is the default for C anyway, but this is not a desirable default. I'm sure you can similarly game Rust bechmarks by using "unsafe".
Re: Nim 1.6.2
#54Something I'm excited about: v1.6.2 integrates support for (not yet released) Nimble[1] v0.14, which will introduce project lockfiles. I've had terrible experiences with lockfiles in JS land, but they are sorely needed for Nim projects as (fingers crossed) they'll allow for reproducible builds without having to resort to the nimbus-build-system[2]. The latter isn't completely horrible — a lot of much appreciated hard…
> reproducible builds without having to resort to the nimbus-build-system[2]
A giant makefile shudder, that's the complete anti-thesis of Nim :)
Lock files have definitely been needed for a while though, I agree.
Re: Nim 1.6.2
#55Earlier quoted context omitted.
which benchmarks? I play the language benchmark game sometimes and I can always get within 10% of the fastest contender. Beating the fastest contender,though, is rarely possible without using the unsafe subset of Nim, hence `-d:danger`
I've digged some more, and indeed in numeric tests Nim is often close to C. Its hard to find good data though, with documented compiler flags and recent versions.
There are definitely slow bits of the Nim stdlib; json parsing for example. String-heavy code is easy to make slow in Nim, too.
Re: Nim 1.6.2
#56Earlier quoted context omitted.
Do these activate -funsafe-math on the underlying C compiler? Because if so that's not a fair comparison, since this breaks a lot of code.
no, -d:danger turns off runtime bounds/overflow checks, assertions, and debug info, and passes '-O3 -fno-ident' to the C compiler
Ah ok, that's fair then.
Re: Nim 1.6.2
#57Seeing that the team behind Nim is accepting Bitcoin is not a good sign.
We accept Euro, Pound Sterling and Dollars too. Any denomination really.
Re: Nim 1.6.2
#58Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?
I was a interested in Nim until I learned that getBlochenAngle and get__B_L_O_C_H_E_N_ANGLE are the same identifier. > https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
I personally still use Python because I miss list and dict comprehensions.
I know there is a `collect` macro in `sugar` module but it is nowhere close to the python comprehensions. The code is too verbose and basically is just the same multiline for loop :-(
Re: Nim 1.6.2
#59Earlier quoted context omitted.
It's the normal compilation flag for performant code. The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.
I suppose the makers of Nim named that flag for a reason - giving up memory safety by disabling bounds/overflow checks should be never be the default for networked software in a production setting, so benchmarking in that mode would paint an unrealistic picture. What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable a…
I'm sure Rust also has a way to disable bounds/overflow checks for speed. Do benchmarks utilise it?
Re: Nim 1.6.2
#60> Macros cannot change Nim's syntax because there is no need for it — the syntax is flexible enough.
Erm, what? How about letting the user decide that?