What is the best language to build _fast_, _low memory_, _static binaries_ and why is it Nim?

Nim is so exciting! Anyone build anything with Nim or work with it in their day job?

Attached: nim.png (453x293, 25K)

Isn't it just a javascript with slightly different syntax?

the allocator has poor realloc performance and doesn't work with virtual memory well

>static

* Unless you meant fast _build time_.

Attached: dancing-ferris.gif (734x490, 258K)

Nim is poor man's Crystal.

Crystal is poor man's Nim.

We found one of the 4 human beings that are excited to use Crystal 2 months after it came out.

What?

> GC
nah

Rust

Are you the /dpt/ nimshill?
How's concurrency, good enough to replace go?

They seem to be trying to achieve exactly the same. Can you tell me about the differences?

Nim compiles through C. It has a case- and underscore-insensitive (fooBarBaz == foo_bar_baz) indentation-based syntax inspired by Python and Pascal. It is a multi-paradigm language. It emphasizes programmer freedom. Crystal compiles through the LLVM. It has a Ruby-like syntax. It encourages OOP. Following its Ruby roots, it emphasizes a good UX for the programmer. Both have an unusual, fairly advanced type system. Both have macros. Nim compiles to JS. Crystal has a type-safe Rails clone. Both have compiler bugs. Crystal's open source libraries seem to be better quality. Neither is 1.0 yet. Nim has been around since 2008 and Crystal since 2014.

Too add to that, Nim is pretty focused on Windows while Crystal doesn't support Windows at all.

>It emphasizes programmer freedom.

Attached: GgSSEQf[1].png (192x174, 43K)

Oh shit thanks for reminding me nim uses python style tab shit. dropped. I'm now a crystal fan

>They seem to be trying to achieve exactly the same.
Not quite. Crystal has a more narrow focus. It is meant to replace Ruby (for web applications) and Go (for network daemons and command line utilities). Nim tries to compete with C++ like D before it. Nim's GC is optional and low-latency, etc.

It seems like Nim would be a better lang for me to pick up then, as I'm used to thinking functional and it seems to have all necessary FP features.
Also I don't care about compiling to JS, I'm liking it for it's portability.
What you didn't address is concurrency.

>Crystal's open source libraries seem to be better quality
The last time I checked, both seemed okay to me. What libraries made you think so?

Nim has async/await. Crystal has fibers, which are like goroutines, and channels. Nim supports parallelism and has per-thread GC. Crystal doesn't support parallelism yet. While Nim can do pattern matching (implemented via a library!), for FP I'd look at OCaml before either of them.

Nimquery and other web stuff.

What's up with their window's support though. One of their unique selling points flat out doesn't work.

OCaml has no multicore and performs like Nodejs

>It has a case- and underscore-insensitive (fooBarBaz == foo_bar_baz)
That's fucking stupid

Nim has nothing like goroutines/green threads?

Thank God no. Otherwise calling a C API would take 40times as much time

But does it matter to you?
>performs like Nodejs
On what tasks?

I don't think so. If there are libraries/extensions for it, I haven't seen them.

>But does it matter to you?
Sounds like a cope to me, why don't you go back to your ML academic wankery and leave us alone?

you don't need a bulky runtime to have greenthreads friend. For example pretty sure there are rust libraries for greenthreads, i.e. zero overhead C FFI and greenthreads in the same language.

Do you have a use case in mind, though? As important as multicore is, there are ways around its lack. In many cases the choice between multicore and multiprocess doesn't matter.

Once you are talking about typed FP, it is a bit too late to complain about ML academic wankery. The people writing your libraries must be pretty into it. If you ignore it, you'll just end up with an ad-hoc, informally-specified, bug-ridden, slow implementation of half of it.