Gleam 0.15(gleam.run)
gleam.run
Gleam 0.15
https://gleam.run/news/gleam-v0.15-released/
79 comments
The doc contains cheatsheets such as "Gleam for X users" where X is currently Erlang, Elixir, Rust and Python. I think this is a fantastic idea and could be adopted by other language communities!
Might I ask for some more guidelines on how to incrementally incorporate Gleam into existing projects in BEAM languages? A guide on interpolation with a phoenix codebase and toolchain would be wicked cool.
Might I ask for some more guidelines on how to incrementally incorporate Gleam into existing projects in BEAM languages? A guide on interpolation with a phoenix codebase and toolchain would be wicked cool.
This is certainly something I want to have in future. Being able to add Gleam to an existing Elixir project is something a lot of people have asked for. It is possible today (Quinn did a great talk on this[1]) and there are libraries to help[2], but it's all a bit rough and ready currently.
The focus for now is on Gleam tooling, but once we have that down we can work more on Elixir tooling for Gleam.
[1]: https://www.youtube.com/watch?v=UCIcJBM_YDw [2]: https://github.com/gleam-lang/plug/
The focus for now is on Gleam tooling, but once we have that down we can work more on Elixir tooling for Gleam.
[1]: https://www.youtube.com/watch?v=UCIcJBM_YDw [2]: https://github.com/gleam-lang/plug/
> The doc contains cheatsheets such as "Gleam for X users" where X is currently Erlang, Elixir, Rust and Python. I think this is a fantastic idea and could be adopted by other language communities!
The Rust ndarray library as a "ndarray for numpy users" [0] which I thought was a very nice idea to help people from the python world convert their numpy code to Rust.
[0]: https://docs.rs/ndarray/0.15.1/ndarray/doc/ndarray_for_numpy...
The Rust ndarray library as a "ndarray for numpy users" [0] which I thought was a very nice idea to help people from the python world convert their numpy code to Rust.
[0]: https://docs.rs/ndarray/0.15.1/ndarray/doc/ndarray_for_numpy...
Is there a good Rust for Python developers tutorial anywhere?
Edit: In my experience almost all Rust tutorials are either for complete beginners or for developers with systems programming experience (like C/C++).
Edit: In my experience almost all Rust tutorials are either for complete beginners or for developers with systems programming experience (like C/C++).
https://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/
This is an intro blog post though, perhaps you expected some more depth.
This is an intro blog post though, perhaps you expected some more depth.
There's not really any tutorials yet I'm afraid. I'm working on it though!
Wow, thank you so much. Can I sign up somewhere to get updates on that?
It will be announced on the gleam-lang twitter account, on the /r/gleamlang reddit, and on the Gleam Discord https://discord.gg/Fm8Pwmy
I agree, the cheatsheets are great. As a Python developer. the python sheet makes me file like I could dive write in and write a gleam program by having python in mind mind and looking up the gleam equivalent for each line of code.
But where it describes the map-dictionary duality, it says: "There is no map literal syntax in Gleam, and you cannot pattern match on a map. Maps are generally not used much in Gleam, custom types are more common."
But it doesn't say why or how this would be done. It seems that, if this point is going to be mentioned, there should be enough context to make it actionable.
But where it describes the map-dictionary duality, it says: "There is no map literal syntax in Gleam, and you cannot pattern match on a map. Maps are generally not used much in Gleam, custom types are more common."
But it doesn't say why or how this would be done. It seems that, if this point is going to be mentioned, there should be enough context to make it actionable.
A good point, thank you! We'll have to refine that.
If you like the direction Gleam is heading, you should really
support Louis! https://github.com/sponsors/lpil
@lpil - What's the status of OTP interop? Seamless integration of Gleam GenServers (for instance) into an Elixir/Erlang supervisor tree would be important for usage on most projects (particularly if you want to do incremental adoption).
The last thing I read was that the plan was to re-implement a GenServer alike from scratch in Gleam rather than anything built over the top of the existing GenServer implementation. I can see why that might be necessary but that's slightly concerning given how battle tested the existing GenServer implementation is and all the edge cases it handles.
The last thing I read was that the plan was to re-implement a GenServer alike from scratch in Gleam rather than anything built over the top of the existing GenServer implementation. I can see why that might be necessary but that's slightly concerning given how battle tested the existing GenServer implementation is and all the edge cases it handles.
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 Erlang core (~200 lines). 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.
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 Erlang core (~200 lines). 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.
Shot in the wind, but is there a plan for different syntax? For those who've become comfortable in different fp camps, I can't really see myself picking up curly brackets and C-style code again. I really like the idea(s) of this project, but it's the thought of staring at that kind of code that's just a bit too much. I'd rather do something like [Nim,Scala,Clojure,F#]->JS if I needed to have that.
I've always kinda felt that there's a lost opportunity for extensible syntaxes by doing things this way rather than having the main surface of a language be some sort of intermediate representation (A la Wasm, LLVM IR, JVM, et al)
Congrats on the release regardless. It's good to see big stable projects in this niche in the BEAM-verse. The world needs more type safety.
I've always kinda felt that there's a lost opportunity for extensible syntaxes by doing things this way rather than having the main surface of a language be some sort of intermediate representation (A la Wasm, LLVM IR, JVM, et al)
Congrats on the release regardless. It's good to see big stable projects in this niche in the BEAM-verse. The world needs more type safety.
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.
[1] https://github.com/alpaca-lang/alpaca [2] https://blog.erlang.org/core-erlang-by-example/
[1] https://github.com/alpaca-lang/alpaca [2] https://blog.erlang.org/core-erlang-by-example/
Right, I see. I wasn't aware of Alpaca, that's quite cool. I've read a little bit about Elixir and about how it's basically a big box of macros and magic dust that goes down to simple, straight erlang in the end, if I had more time I'd love to dig into their compiler.
Alpaca looks very neat, and ML is right up my alley. thanks again for showing this!
I can admit I am no BEAM expert and it seems my thought offended the experts, but I just like the aesthetic of modularity played out to the logical conclusion of syntactic extensions unto intermediate forms.
Alpaca looks very neat, and ML is right up my alley. thanks again for showing this!
I can admit I am no BEAM expert and it seems my thought offended the experts, but I just like the aesthetic of modularity played out to the logical conclusion of syntactic extensions unto intermediate forms.
Sadly Alpaca development has stopped. One of the reasons I started Gleam is that I was working on the Alpaca standard library and realised that the bugs I was reporting were not getting fixed.
> 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.
[1] https://github.com/lfe/lfe
[2] https://github.com/hamler-lang/hamler
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.
[1] https://github.com/lfe/lfe
[2] https://github.com/hamler-lang/hamler
Purerl is another good one to look at. It's an alternative backend to the PureScript compiler, which is quite a popular language!
There's also Caramel https://caramel.run/
That looks like a really interesting thing to potentially combine with rescript/bucklescript.
That's a good point, I always forget about PureScript.
Unlikely I'm afraid. We used to have an ML style syntax but once we switched to a more mainstream syntax we had a big surge in popularity and interest.
I am very fond of the ML syntax, but I think it is the semantics and type system that really matter, so I am very happy to sacrifice syntax in order to make Gleam more widely accessible.
I am very fond of the ML syntax, but I think it is the semantics and type system that really matter, so I am very happy to sacrifice syntax in order to make Gleam more widely accessible.
Thanks for the response!
That's very cool, I wouldn't have thought that the trend would swing that way. I suppose it makes sense in a conventional wisdom kind of way.
How long ago was the switch? I'd like to read (code or prose, idc) about your experiences switching the syntaxes out. That's a hard thing to do right, but maybe not so much if it was really early on?
That's very cool, I wouldn't have thought that the trend would swing that way. I suppose it makes sense in a conventional wisdom kind of way.
How long ago was the switch? I'd like to read (code or prose, idc) about your experiences switching the syntaxes out. That's a hard thing to do right, but maybe not so much if it was really early on?
The big switch was maybe about 3 years ago? v0.5 had a few more changes away from the ML style too https://gleam.run/news/gleam-v0.5-released/
Is it possible that the popularity increase albeit being correlated to the syntax changes, was not caused by it?
There certainly were other factors, but people have been quite vocal in their enjoyment of the new syntax.
I think the ML people like me are kinda used to not getting their favourite syntax. Alas!
I think the ML people like me are kinda used to not getting their favourite syntax. Alas!
It is possible, but would be an interesting co-incidence. More anecdotal evidence, but Elixir has an easier time with adoption that Erlang and a big part of that reason is syntax.
It's superficial, you get past it quickly, but it's the first thing you encounter and that can affect whether people give a language a 'proper' go.
It's superficial, you get past it quickly, but it's the first thing you encounter and that can affect whether people give a language a 'proper' go.
It’s still super early on but I think this is one of the motives behind Lunatic:
https://github.com/lunatic-solutions/lunatic
https://github.com/lunatic-solutions/lunatic
This is an absolutely fascinating project. I'll be keeping a close eye on it for sure!
I had hoped that Go would eventually kind of serve this role in the PLT world, years ago when it was first announced. Sadly, it's morphed a lot over the years into something entirely different.
I had hoped that Go would eventually kind of serve this role in the PLT world, years ago when it was first announced. Sadly, it's morphed a lot over the years into something entirely different.
The todo keyword https://gleam.run/book/tour/todo.html is brilliant. Are there any other languages that have this?
Probably based a little on this: https://doc.rust-lang.org/std/macro.todo.html
it's not the same, but it's almost idiomatic to leave unfinished python code with "..." (the ellipsis object)
def foo(bar, baz):
...
Yeah, but this is best used for abstract methods or type stubs. I think in 'real code' you would want to raise NotImplementedError, or even (if you use mypy) potentially return a NoReturn
ie: from typing import Any, NoReturn
ie: from typing import Any, NoReturn
def foo(bar: Any, baz: Any) -> NoReturn:
raise NotImplementedErrorPerl has ellipsis which will die on use.
Oh, interesting. I’ve always used “pass” for this.
Elm has `Debug.todo`. If you were to use this, it allows your app to compile in development but the app would crash should it hit this code.
Elm's compiler will prevent you from creating a production application with a `Debug.todo` still in place.
Elm's compiler will prevent you from creating a production application with a `Debug.todo` still in place.
kotlin has TODO("reason")
AFAIK there's no reason support, but you can make a whole in Scala using ??? as the right-hand side.
Rust has the `todo!()` macro: https://doc.rust-lang.org/std/macro.todo.html
Haskell has "typed holes": https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_gu...
Haskell has "typed holes": https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_gu...
You can get a similar effect in Elixir with # TODO comments if you're using Credo.
It's just a code comment, but by default Credo will exit non-zero if it sees one so if Credo is part of your CI pipeline it will fail it by default.
I'm one of those annoying people who puts # TODO comments all over my code though, so I set Credo so that TODO's wouldn't fail the build.
It's just a code comment, but by default Credo will exit non-zero if it sees one so if Credo is part of your CI pipeline it will fail it by default.
I'm one of those annoying people who puts # TODO comments all over my code though, so I set Credo so that TODO's wouldn't fail the build.
Scala has `???`, which does a similar thing.
Ive been following this project for a while, it is extremely promising considering theres an interop between elixir and rust ecosystem. Lack of first-class typing and somewhat implicit resolutions/imports are my current annoyances with Elixir although its still my go-to until deno/ts tools mature. Some people mentioned already but dedicated docs for how to run phoenix/ecto with gleam, run any rust code with gleam would be super useful for understanding & adoption. Lastly rust-like “local” docs generation from types would be amazing, biggest thing missing currently in TypeScript in my view, existing tools are very premature.
Being able to build and view docs locally is a good idea, thank you. If you have some ideas as to what that workflow would be like it would be great if you could open an issue on GitHub
Pleased to see this release, looking forward to getting JS compilation soon too. Exciting times.
Aye, I am very much looking forward to that feature
I wasn't tracking that JS compilation was an intended feature. Is there any documentation regarding a plan / expected timeline for that?
Nothing has been officially announced but it is something that is being worked on. There is a milestone for it on GitHub https://github.com/gleam-lang/gleam/milestone/17
I expected we'll have an initial offering within the next half year.
I expected we'll have an initial offering within the next half year.
Curious, how are you planning to translate processes to the browser?
We likely will not attempt to port the Erlang concurrency model to the browser, at least not to start. Some Gleam users have been experimenting with an actor model library in JavaScript, this could be the basis of future research.
More generally, Gleam doesn't have any concurrency primatives in the core language currently. We have a type safe OTP library, but it implemented in userland with a core of ~200 lines of Erlang rather than being built in to the compiler.
More generally, Gleam doesn't have any concurrency primatives in the core language currently. We have a type safe OTP library, but it implemented in userland with a core of ~200 lines of Erlang rather than being built in to the compiler.
That is amazing. Thank you!
Is there any documentation on "Zero cost interop with Erlang, Elixir, etc" mentioned on the home page? I'd definitely be really interested if it can be integrated with eg. a Phoenix project.
You might be looking for https://gleam.run/book/tour/external-functions.html
In the other direction, to quickly discover how to call Gleam functions from Erlang/Elixir, one option is to explore your project with IEx's auto-complete functionality; it's the same as using Erlang functions in Elixir, as Gleam compiles to Erlang.
In the other direction, to quickly discover how to call Gleam functions from Erlang/Elixir, one option is to explore your project with IEx's auto-complete functionality; it's the same as using Erlang functions in Elixir, as Gleam compiles to Erlang.
If you're familiar with Elixir you can call Gleam functions the same way as Erlang functions. Gleam compiles to typical Erlang code, and you can even read the compiled output to get a better idea of how it works.
Later we will have more docs on how to work with Gleam from Elixir specifically, thank you.
Later we will have more docs on how to work with Gleam from Elixir specifically, thank you.
What is the "case" for Gleam? In general, and specifically for the choice of using the Erlang virtual machine?
I read the "Why Gleam" page, and it reads like "Why have static types" and "Why work on a virtual machine" + "Why we're as good as Erlang". That's not much of a pitch (especially if you're not already into Erlang.)
I read the "Why Gleam" page, and it reads like "Why have static types" and "Why work on a virtual machine" + "Why we're as good as Erlang". That's not much of a pitch (especially if you're not already into Erlang.)
That's a good point, thank you. I am a long time Erlang/Elixir user and I've mostly been trying to attract that community in the past, so the docs are very biased towards already knowing the value of that ecosystem.
It's tricky to condense into a short reply, but the Erlang virtual machine and way of programming are in some respects second to none. It is build with scalability, concurrency, distributed computing, and fault tolerance in mind. It's really good at handling high load. It uses the actor model and it's not uncommon to have hundreds of thousands of actors in an Erlang programs (in fact the creator of Erlang says that's a "boring" scale) without any deadlocks or fiddly race conditions.
Erlang programs also have mechanisms for self healing when errors arise (bugs, hardware failure, whatever). Kind of like k8s style system but very fine grained and baked into the very language and with 35 years production usage.
This is a bit of an off-the-cuff fanboy-y ramble, but basically it's just a really nice ecosysem to work in when making networked services. I've personally found it makes things a lot easier than most other ecosystems I've worked in.
It's tricky to condense into a short reply, but the Erlang virtual machine and way of programming are in some respects second to none. It is build with scalability, concurrency, distributed computing, and fault tolerance in mind. It's really good at handling high load. It uses the actor model and it's not uncommon to have hundreds of thousands of actors in an Erlang programs (in fact the creator of Erlang says that's a "boring" scale) without any deadlocks or fiddly race conditions.
Erlang programs also have mechanisms for self healing when errors arise (bugs, hardware failure, whatever). Kind of like k8s style system but very fine grained and baked into the very language and with 35 years production usage.
This is a bit of an off-the-cuff fanboy-y ramble, but basically it's just a really nice ecosysem to work in when making networked services. I've personally found it makes things a lot easier than most other ecosystems I've worked in.
> scalability, concurrency, distributed computing, and fault tolerance in mind
would somebody use Kubernetes to get the same benefits in a non-fault tolerant language? or do people still use BEAM in kubernetes?
would somebody use Kubernetes to get the same benefits in a non-fault tolerant language? or do people still use BEAM in kubernetes?
k8s offers some of the same benefits but not to the same extent because the restarting and state shedding happens at the level of the a container on k8s. On the Erlang VM it happens on a per-process (what Erlang calls coroutines/green-threads/fibers), so rather than losing all state and all requests currently happening in a single instance, you only lose the 1 of potentially millions of processes in your program. This means you can handle failure much more gracefully, and within nanoseconds rather than seconds.
I like to say that Erlang's supervisors are to k8s what k8s is to datacenter failover. Similar things, different level of abstraction.
And yes it's common to use Erlang with k8s, though there is a little redunancy. It's still good for all the other k8s features.
I like to say that Erlang's supervisors are to k8s what k8s is to datacenter failover. Similar things, different level of abstraction.
And yes it's common to use Erlang with k8s, though there is a little redunancy. It's still good for all the other k8s features.
Ok, so...
1. I'm not much of a VM person, but I'm always doubtful of claims by VM-based languages to be "fast".
2. "the ... virtual machine and way of programming are in some respects second to none" - We don't easily notice any of those respects on the "Why Gleam" page.
3. "It is built with scalability, concurrency, distributed computing, and fault tolerance in mind" <- That's rather vague. Also, is this a benefit of Gleam, Erlang, or the Erlang VM?
4. "It uses the actor model" <- Many, perhaps most, languages, don't "use the actor model", so I wouldn't know why this it is superior to other ways of programming.
5. "it's not uncommon to have hundreds of thousands of actors in an Erlang programs" <- Well, I didn't see actors in the examples, so I can't tell why this is impressive.
6. If Erlang is so nice, what's wrong with it to make me prefer an non-Erlang, but Erlang-sih language?
7. "Erlang programs also have mechanisms for self healing when errors arise" <- In the most general interpretation, this is Turing-complete, so such a feature is impossible. But perhaps you mean something like exceptions and error codes? Transactional data structures? Something else?
I'm not trying to be facetious, just to understand why this is interesting. Also see my comment about the project CoC, it's pretty scary.
1. I'm not much of a VM person, but I'm always doubtful of claims by VM-based languages to be "fast".
2. "the ... virtual machine and way of programming are in some respects second to none" - We don't easily notice any of those respects on the "Why Gleam" page.
3. "It is built with scalability, concurrency, distributed computing, and fault tolerance in mind" <- That's rather vague. Also, is this a benefit of Gleam, Erlang, or the Erlang VM?
4. "It uses the actor model" <- Many, perhaps most, languages, don't "use the actor model", so I wouldn't know why this it is superior to other ways of programming.
5. "it's not uncommon to have hundreds of thousands of actors in an Erlang programs" <- Well, I didn't see actors in the examples, so I can't tell why this is impressive.
6. If Erlang is so nice, what's wrong with it to make me prefer an non-Erlang, but Erlang-sih language?
7. "Erlang programs also have mechanisms for self healing when errors arise" <- In the most general interpretation, this is Turing-complete, so such a feature is impossible. But perhaps you mean something like exceptions and error codes? Transactional data structures? Something else?
I'm not trying to be facetious, just to understand why this is interesting. Also see my comment about the project CoC, it's pretty scary.
1. For sure, "fast" is a bit of a vague term. To be more specific it's not fast at number crunching, but it has a low latency, low standard deviation concurrent garbage collector and it's quite memory efficient. More details can be found online, and WhatsApp etc provide some good case studies.
2. Yes! More documentation will come as the language matures. For now we will have to defer to Erlang and Elixir documentation and studies.
3. All three. Gleam aims to provide scalability with development through excellent tooling and static analysis, Erlang and the VM provide runtime scalability with fault tolerance, concurrency, parallelism, and distribution at runtime.
4. Quite a tricky one to explain quickly but it's concurrency model based around the idea of having many sychronous subsystems working together in a system similar to how people work together. It's often said to be one of the easiest to use concurrency models. To paraphrase one of Erlang's creators: "It's hard to write a web server that can process 1000,000 concurrent requests, it's easy to write a web server that can handle 1 request and run 1000,000 of them".
5. Most languages will only have 1 thread or 1 per CPU on the machine, so having millions is quite unusual. Golang is another language that has this property and it has proven very valuable.
6. I'm sorry, I don't understand this question. What do you mean?
7. It's not analysis, so turning completeness isn't an issue! The fault tolerance is purely a runtime behaviour. It covers exceptions and such, but also works for hardware failure, network issues, memory corruption, etc.
2. Yes! More documentation will come as the language matures. For now we will have to defer to Erlang and Elixir documentation and studies.
3. All three. Gleam aims to provide scalability with development through excellent tooling and static analysis, Erlang and the VM provide runtime scalability with fault tolerance, concurrency, parallelism, and distribution at runtime.
4. Quite a tricky one to explain quickly but it's concurrency model based around the idea of having many sychronous subsystems working together in a system similar to how people work together. It's often said to be one of the easiest to use concurrency models. To paraphrase one of Erlang's creators: "It's hard to write a web server that can process 1000,000 concurrent requests, it's easy to write a web server that can handle 1 request and run 1000,000 of them".
5. Most languages will only have 1 thread or 1 per CPU on the machine, so having millions is quite unusual. Golang is another language that has this property and it has proven very valuable.
6. I'm sorry, I don't understand this question. What do you mean?
7. It's not analysis, so turning completeness isn't an issue! The fault tolerance is purely a runtime behaviour. It covers exceptions and such, but also works for hardware failure, network issues, memory corruption, etc.
Now if you could just integrate some of this information into the "Why Gleam" page...
Anyway, about No 6: The why Gleam page and your previous posts do not differentiate Gleam from Erlang. The benefits you described are seemingly shared by Erlang and Gleam, and yet a non-Erlang language was created.
Anyway, about No 6: The why Gleam page and your previous posts do not differentiate Gleam from Erlang. The benefits you described are seemingly shared by Erlang and Gleam, and yet a non-Erlang language was created.
Most the details on the home page are specific to Gleam rather than Erlang. If you'd like to hear more this talk from CodeMesh may help -> https://www.youtube.com/watch?v=HaKR2kt-DXI
This talk by Saša Jurić (author of Elixir in Action) should answer most of your questions regarding the benefits of the BEAM (Erlang VM).
https://youtu.be/JvBT4XBdoUE
Seriously, if you're even the slightest bit curious you should watch the talk, I'm very confident that you'll find impressive what the BEAM brings to the table.
https://youtu.be/JvBT4XBdoUE
Seriously, if you're even the slightest bit curious you should watch the talk, I'm very confident that you'll find impressive what the BEAM brings to the table.
I will (even though I have no idea what Elixir in Action is). Thanks!
As mentioned elsewhere in the thread with more substance; Gleam runs on BEAM and uses curly brackets. I'm not into types, but I might consider it because I like curly brackets. I'm only partly joking.
[deleted]
Would love to see some highlights of differences between Gleam and Elixir as someone who has never used something Erlang based but has been wanting to try
Gleam is typed, for starters.
Gleam is type safe, for starters.
Syntax-wise, this is a pretty great comparison: https://gleam.run/cheatsheets/gleam-for-elixir-users/
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.
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.
Any code of conduct violation or accusation will be taken with the greatest level of seriousness and will be investigated by myself.
Rest assured that violations nor CoC trolling will not be tolerated in any way.
Rest assured that violations nor CoC trolling will not be tolerated in any way.
You're saying that the failings of the formal procedures will be made up for by the benevolence of the person exercising investigatory and judicial powers.
Perhaps the way the project actually runs is fine - after all, I don't know you nor the project. But generally, that's not the case. When I consider collaborating/contributing significantly to a project, and I see something like this CoC, it is a large red warning light. (Which is a bit ironic considering it's supposed to enforce inclusiveness and a welcoming atmosphere...)
Perhaps the way the project actually runs is fine - after all, I don't know you nor the project. But generally, that's not the case. When I consider collaborating/contributing significantly to a project, and I see something like this CoC, it is a large red warning light. (Which is a bit ironic considering it's supposed to enforce inclusiveness and a welcoming atmosphere...)
In which case I would encourage you not to participate in Gleam, thank you.
I think you're reading too much into this. It doesn't say "you will be judged and punished". It says "All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances."
> Gleam is a type safe and scalable language for the Erlang virtual machine, and today v0.15.0 has been released! Let’s take a look at some of the highlights.