[adgasf]

Haha indeed!

My position is this: different programming languages have different strengths and weaknesses. C++ is crazy fast, but it lacks many high-level features (most notably do-notation). Efficiency and performance are its niche. Conversely, F# (or any ML) is very good at expressing complex control flow, but performance is a secondary concern.

Package management is an IO-bound SAT problem, so we are using the best tools for the job.

[ernst_klim]

ML could be as fast as C++ and even have manual memory management. Take a look at mlton [1] and manual memory management [2]. Most ml compilers just value compile time more.

[1] http://mlton.org/Performance

[2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.75....

[e12e]

Maybe the world needs a language that is like clasp is to lisp and c++, but for c++ and ml?

Curious about your deployment happiness - are you bundling the runtime with your program? Last I checked, such a bundle was large (compared to a static c++ binary), and didn't have a nice single/few file(s) "container"?

[adgasf]

PureScript has a C++ back-end, which is an interesting prospect: https://github.com/andyarvanitis/purescript-native

Our development process is very pleasant. We use VS Code, .NET Core and Ionide as an IDE. I find an IDE essential for languages with global type-inference.

For bundling, we use Core RT to create a self-contained application. This is then bundled using Warp (https://github.com/dgiagio/warp) to generate a single binary.

The script is here https://github.com/LoopPerfect/buckaroo/blob/866ae97ffc82ab8...

The final binary size is quite reasonable:

- Linux 66.1 mb

- macOS 63.9 mb

- Windows 35.4 mb

I haven't investigated why Windows is so much smaller!

[e12e]

Thank you. If I read that correctly, the last line runs your artifact - is that for CI or something? (I'd expect the purpose was to just create the artifact?)

Ed: then again, your artifact is a build tool - does that build distribution packages?

[adgasf]

Yes, the last line is for CI. It just runs the tool as a simple check that it built correctly. Cross-compilation does not work with Core RT anyway, so we can assume that you are always building for the host platform.

[e12e]

> Cross-compilation does not work with Core RT

Huh? I was sure I tested that after an announcement in... November? But it's supposed to have been supported a while longer? Eg: https://www.hanselman.com/blog/SelfcontainedNETCoreApplicati...

Perhaps a warp limitation?

[adgasf]

I tried Linux host compiling to Windows and it did not work. Perhaps I need to update.