maattdd

"Stay hungry, stay foolish"

On VSCode, I use the Gremlins extension which highlight all those suspicious characters.

https://github.com/nhoizey/vscode-gremlins

Going from Nim to C is clearly lowering the language. The general agreed definition of a compiler is going from a certain level to a lower level.

The added typing on the stdlib can break stuff, but it's really minor and in most cases it makes visible a potential bug in your program.

TIL another project started by Fabrice Bellard (well for him it's just a side project for the real project JSLinux).

The last published package on opam is 12.0.1 https://opam.ocaml.org/packages/llvm/

I like Crystal for this, the standard library has support for the most common stuff (HTTP server, JSON/XML parsing, logging, templating), installing additional packages is easy and the build step also.

Nice bonus: the resulting app is native and fast.

It's true if you don't have any other files such as HTML templates or CSS or whatever; which is fairly rare (don't even get my started on stuff like Packer which embed binary content inside the binary executable...).

Nowadays, deploying any project should just be one docker build . away whatever the language.

Performance

There is, for example https://bellard.org/quickjs/

I use AWS Cloudfront on top of my static blog to get basic analytics (and some edge caching). It is almost free.

Can you elaborate ?

"Slow" can be subjective indeed, but not "slower".

Thanks for the nitpick, I should have been more precise and write move value from memory to abstract register otherwise it is indeed confusing. I will fix the article and mention your comment.

I don't think I've ever heard that. Ocaml performance is surprisingly very predictable.

It doesn't scale well to triple dispatch, quadruple dispatch...

I'm not a native speaker, but shouldn't it be "33% increased performance" or "133% performance" instead ?

You mean parallelism ? JS has good concurrency support (event, async..)

Maybe get out of your place sometimes?

You also need to handle the event loop yourself ; otherwise you end up using a language which is sub-Crystal.

I have no idea how you ended up with this completely wrong statement. Rust is closer to C++ replacement, and Crystal and Go are something else (GCed to begin with).

It's possible, just not officially supported nor straightforward. You need to run the GC yourself and all this kind of stuff.

https://stackoverflow.com/questions/32916684/can-a-crystal-l...

https://gist.github.com/Papierkorb/02d6ba53c28b5035a80bf7695...

Unfortunately no, it need some runtime (libevent, boehm gc) which is hard (impossible?) to integrate inside a shared lib.

Crystal is one of my most productive language for small project web oriented (Slack bot): a cleanup Ruby with added benefits (performance, type safety, null safety, proper concurrency).

My only complaints: * compilation speed * type inference is sometimes not intuitive (class members * too OOP oriented (no constness, no UFCS/pipeline, no general monad operator,...etc)

Crystal doesn't use significant whitespace (like Ruby).

Hence Cupertino style

The main reason not to use OCaml but Rust is imho "no runtime needed" (aka better-C). This is why they considered Rust complementary to OCaml (which would not be true with F#, the multicore issue will be addressed soonish).

A Slack bot to subscribe to keywords and alert you when there are matching comments on HN and Reddit tech.

It works but need (a lot) of polishing: www.newsbutler.io

This seems high for Paris, is it ABC.A ?

Dunno, but one of their employee (Laurent Mazare) is actively making OCaml bindings for various data science libraries (such as https://github.com/LaurentMazare/ocaml-torch or https://github.com/LaurentMazare/ocaml-matplotlib)