Hacker News Reader

Comment by lll-o-lll | Hacker News Reader

This is interesting. When I think of a programming language I tend to consider it a tool to express an idea. The ideas from Erlang Behaviours (not being an Erlang developer), seemed to be a fairly generalisable. So I would have thought the language is not so important.

The example of C as the de facto cross-language standard (it’s not just in Linux), is also interesting. Creating a C interface imposes on a library author a set of restrictions in expression, but is anything truely lost in doing this?

I am much more interested in the concepts/ideas being expressed than I am the language being used to express it.

View on HN

Re the C part. Yes. A lot. You lose all the expressivity of your type systems and the way you manage memory. Plus you have to deal with the lack of specification of the C ABI.

See https://faultlore.com/blah/c-isnt-a-language/

You loose the expressiveness, no argument there. The poetry is not visible. Still, that’s just a matter for a wrapper in the consuming language.

E.g. beautiful Rust wrapper -> “Ugly C interface” -> “Ugly C interop layer” -> beautiful Go library

I mean, it’s a pain to maintain “ugly C interop”, but as these tend to be built after the fact anyway, other than cost I don’t see anything lost.

Nope, you cannot because there is information lost in the middle that means that some of what you wanted to express in order to make it beautiful in Go is not there anymore. The medium is lossy and you cannot recover from it.

What is beautiful in one language is often hideous in another. Translation is required.

Much like with human translations of poetry. A good translation is not word for word, the translator captures the essence and re-expresses it in the other language. When done well, it is frankly a work of genius.

So the C interface is just a medium a “translation dictionary” if you will. To do it well requires the author of the wrapper to express the ideas in a form palatable to users of the other language. I get that this is not always done well, requires a bunch of work, and may raise the question “why not re-write?”. I’m happy to consider better alternatives.

You realise that the medium language is incapable of expressing that?

And yes, there are wip to a superset ABI

The example for OPEN(2) isn't for Linux, it's for glibc. Languages are free to implement system calls and bypass glibc if they wish. This isn't the case on BSD as the libc implementation is the official interface, but nobody is forcing anyone to write C. The fact is, lot's of interesting software is written in C, and most people want to use it rather than re-implement things that have worked for decades.

Yes and no. In a way, yes we are forced to interact with C. The syscall are in C and the ubiquitiness of C has made it de facto the thing you need to limit yourself to.

syscall's are not in C. They are an interrupt instruction and some parameters in registers, and these can be emitted in a variety of languages. You only need to use C if you want to use libc of the platform.

They are fairly generalizable, to a point.

The thing about Erlang behaviors is that they rely on several other pieces of Erlang to work well.

One big one is being able to be notified when another process goes down, or is aborted.

The other big one is being able to reason about state in the face of such failure.

Erlang decided to go with immutable data structures, shared nothing processes, and the OTP behaviors generally expect you to decompose the behavior of the various bits into functions that represent a single atomic step.

The more of those properties that you don't share with Erlang, the harder it will be to adopt OTP style semantics in your system.

The other thing about behaviours is... Especially if you have a synchronous API, you can mock it with a stateful system, for example calling out to a GenServer or calling over the network. This is why GenServer.call doesn't emit an error tuple; an network or interprocess error by default is considered to be unrecoverable. In most other systems you'll fumble around with colored functions transitioning between a sync system or async call, or, have to do annoying error handling, or even worse stack unwinding with an exception or get stuck in a panic.

In Erlang, a sync API behavior can safely have a failable async implementation, and that is powerful

Reply on news.ycombinator.com