Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Please take a moment to read the project's Code of Conduct:
https://github.com/gleam-lang/gleam/blob/main/CODE_OF_CONDUC...
It says that if you're a contributor, people can make anonymous complaints about you, and you will be judged and punished without being afforded the right to face your accuser and full access to the accusation and the evidence (that is, a "confidential" adjudication procedure).
Naturally, you can be punished for very vague offenses, under the title of any "conduct which could reasonably be considered inappropriate in a professional setting". It's not even any conduct which _is_ inappropriate in the setting of the project - it's enough that someone could subjectively consider it inappropriate, and in a different professional setting. In other words: Very easy to cook up charges as necessary.
If all of that is not enough - anyone who is deemed not to follow the code of conduct in good faith - i.e. it's not enough that you follow it, you have to show good faith about it - is an offender automatically. Even failing to actively _enforce_ the CoC is an offense.
Now, Gleam may not the only project with this kind of repressive project-criminal code; but this is quite saddening to see in a Free Software project.
You may prefer alpaca[1] which is in the ML family and on the BEAM. Someone could target Core Erlang [2] or BEAM byte code directly and offer a pluggable frontend for different syntax, Mix would almost allow that. I think it's just a huge lift to make happen and get everything to play nicely with BEAM semantics. But that's just like my opinion.
> I can admit I am no BEAM expert and it seems my thought offended the experts
Who knows? I didn't find the musing particularly off putting.
As Alpaca is apparently dead there's also LFE[1] and Hamler[2]. Most devs in the space stick to either Elixir or Erlang so ymmv.
> I can admit I am no BEAM expert and it seems my thought offended the experts
Who knows? I didn't find the musing particularly off putting.
As Alpaca is apparently dead there's also LFE[1] and Hamler[2]. Most devs in the space stick to either Elixir or Erlang so ymmv.
We have a fully type safe and Erlang compatible OTP library! It is used in production today.
https://github.com/gleam-lang/otp
It is not a wrapper around gen_server etc, but instead it is a full implementation from the ground up using a very small core. This was done because:
a) Erlang OTP cannot be typed, we need different abstractions are designed with types in mind
b) We want to be confident that our abstractions are powerful enough to build something like OTP, rather than cheating by relying on type casts.
I'm very happy with how Gleam OTP is going, but it is not the focus now that an initial version is out. Tooling and documentation is more important at the moment.
It’s still super early on but I think this is one of the motives behind Lunatic: