nwalkr

i'm not much into ethics usually, but this is kinda low.

ethics aside, where is the profit? rust/tauri is same electron except with rust. legally questionable "open-source" label?

maybe it's time to embrace the enemy and go "clanker, this is uv-build source, rewrite it in portable C". rewrite it in C FTW!

btw, I know of a guy who using extensive amounts of tokens to make his fork of mrustc usable via "claude, make this rustc compile 99% of crates.io", I think this also can yield some results.

yeah, this escalated quickly.

i hope to see fm-1.5 with sd card soon to make it sampler. or is it time for hardware mod?..

> all the Erlang formats can be decompiled into Erlang source code

Nope, I'm not buying. This is roughly "any executable binary can be decompiled to C" which is kinda true, but we both know it's not how the real world works. Compilation is lossy, parsing to AST is almost lossless.

> the cost of compiling to source

But now you paid this cost a second time. To build textual Erlang source programmatically, you need some kind of AST anyway, as I highly doubt you were using direct text templating. So you had an incomplete copy of Erlang Abstract Format, which is THE Erlang AST, but had to write your own pretty-printing.

If I were to implement code generation targeting BEAM in language X I would start with making some tool(in Erlang) to fetch abstract format definition from erl_parse typespecs and make code generator to X emitting matching definitions and ETF serialization code. It is relatively simple, it is unavoidable anyway, and it lets me avoid bothering with textual Erlang puctuation.

I just don't get it. It's not even fun!

Also I'm currently playing with idea of compiling Core Erlang via OCaml backend, there is a mirror problem - parsing of Core into OCaml terms. And no way I'm implementing proper lexing/parsing of Core, I'm going with ETF right from start.

idk, i'm not sure about wording. erlang abstract form still is erlang source, it's ast of erlang source text. one call to erl_prettypr:format and text source is back. word 'transpiler' is still there and there is nothing "pejorative" in it, it's transpilers all the way down everywhere.

but talking pejorative, i was surprised. my opinion of gleam was already pretty low, but i did not expect to see post-1.0 compiler emitting text erlang source. maybe it's not that good of idea to implement compiler in language completely foreign to target ecosystem.

it's somewhat alive.

they do some releases, they have a somewhat big project of rewriting vm in zig.

like we could expect something other than that from DDV

being written in rust is clear disadvantage for web-app.

Small remark: Go I/O layer is safe to use only with network I/O. Only network I/O plays nice with goroutines.

File I/O or everything else treated as syscall by Go runtime might turn you program into 10k-os-threads-monster. Scheduler will be creating new OS threads to replace those locked on syscalls until thread limit is reached and whole program crashes. Only way to prevent it is to restrict your syscall layer into fixed-size goroutine pool.

I had an interesting case recently - my app serves some data from tons of files laying in NAS, accessing it by NFS mount and one day NAS hunged completely, every I/O call to it was lasting forever. Even 'ls /mount-point-of-nas' was just doing nothing forever until Ctrl-C. In my case I've applied poweroff-poweron cycle to NAS, and everything went right in minutes, just as NAS booted. And after it I wondered, what if my server was written in Go, instead of Erlang...

And, BTW, you can never be sure, that underlying libraries of your code are safe to use.