We take moderation very seriously in Gleam, and I assure you this poster has omitted much of the context here. If you have any concerns please do get in touch with the moderation team either on discord or via "hello at gleam.run". Thank you.
Hey, glad to see you here! I've been following Gleam from the sidelines for a while and I'm really excited to see where it ends up.
I can tell that you take moderation very seriously, and that's part of my concern—there's a trend among a certain newer crop of FOSS projects to moderate in a way that is opaque, passive-aggressive, and somewhat self-righteous. This is usually done in the name of creating safe spaces, where "safe" means "things that make anyone uncomfortable get erased".
It starts out fine with erasing hate speech and similar. But then you get in the habit of removing things and you start removing content that isn't hateful but is uncomfortable for some other reason. I've seen projects (Forgejo) remove evidence of reasonable dissent about the appointment of a moderator (going so far as to erase that dissent from the internet archive).
One anecdote isn't enough for me to believe that you've gone that far, but it's a trend that I've seen and your rhetoric falls into that concerning pattern. I'm not interested in having a private conversation (as I said, opaque moderation practices are part of the problem I'm identifying), but I would caution you against going too far down this safe spaces route. Keep out the hate speech, but be wary of deleting things that aren't.
We go quite a bit further than keeping out hate speech. For example, we have a policy of "good vibes" in the chat so we don't permit bashing other languages and will publicly ask folks to take it elsewhere if they start.
It's been a few years of using these policies and it's going great! The community and discord server have been consistently praised as one of the highlights of Gleam.
The main drawback is that we tend to attract a lot of criticism from right-wing social media posters as a result, bizarrely including one brief smear campaign from one of the founders of Trump's Truth Social.
It's not just the far right that's uncomfortable with this kind of policy and rhetoric—I'm glad that the relatively small subset of the population that you're interested in supporting has enjoyed the environment you've created, but know that you're severely limiting the growth of your community and excluding people who could really contribute.
There are a lot of people from every part of political manifold that are uncomfortable with the growing tendency towards sheltering oneself and others from all emotional discomfort, and those people aren't interested in participating in a community where everything has to have "good vibes".
For myself, I love the quote in dang's profile:
> "Conflict is essential to human life, whether between different aspects of oneself, between oneself and the environment, between different individuals or between different groups. It follows that the aim of healthy living is not the direct elimination of conflict, which is possible only by forcible suppression of one or other of its antagonistic components, but the toleration of it—the capacity to bear the tensions of doubt and of unsatisfied need and the willingness to hold judgement in suspense until finer and finer solutions can be discovered which integrate more and more the claims of both sides. It is the psychologist's job to make possible the acceptance of such an idea so that the richness of the varieties of experience, whether within the unit of the single personality or in the wider unit of the group, can come to expression."
— Marion Milner, 'The Toleration of Conflict', Occupational Psychology, 17, 1, January 1943
> but know that you're severely limiting the growth of your community and excluding people who could really contribute.
Quite the opposite. By not having the usual sources of annoyance and tedium Gleam's community has grown much faster and larger than similar technologies in the same space.
Being tolerant of abrasive behaviour has a cost to the technology project, and I'm not interested in paying it, especially not for ideological "everyone is welcome" reasons.
> Gleam's community has grown much faster and larger
I hope I’m the anecdotal exception then! I personally watched this exchange happen and left the community within 24 hours. I respect your right to run your community how you’d like, but I unfortunately didn’t experience any “good vibes” from how you handled this situation.
To me a good moderator handles situations without patronization or condescending, is respectful but clear, and doesn’t care how people feel about them.
You're occupying a very special niche (typed BEAM language), so if I were you I'd be wary of attributing your growth to your moderation practices. Correlation and causation and all that.
My prediction is that you grow rapidly because of natural interest in the niche you occupy. Your community will get larger and more diverse than you expect in spite of your efforts to keep people out. Then, when you run into your first major point of conflict about language development, the community will be divided on what to do and your efforts to moderate in this way will only fan the flames. Then Gleam will go the way of Elm—it will go back to being something that a very small niche group keeps using, but the bulk of the excitement will go back to Elixir as it slowly starts to occupy your technical niche.
A community with no mechanism for dealing with conflict cannot last long. If being an Elm sounds fine to you—it's not a bad fate after all—then that's fine! Just don't expect more unless you're willing to start developing conflict tolerance in the community.
I think you're misunderstanding here. We have very robust mechanisms for dealing with conflict and we have been successfully employing them for years. We have also consulted with moderators of much larger communities and very confident with how it is going.
Not sure what you mean about the Elm remark. They took the approach you're advocating for and have seen less success than we have financially and in terms of community growth metrics.
You must have missed when Elm was you [0]. They had far more excitement than you currently do and it lasted a few years.
And they didn't take the approach I'm advocating for (though they didn't take yours either). Their conflict management approach was "we do what Evan says". I'm not saying you're making their mistakes, I'm offering them as a cautionary tale—language success can be fleeting.
> We have very robust mechanisms for dealing with conflict and we have been successfully employing them for years.
If I'm understanding the approach correctly it's basically "we delete it". Feel free to elaborate if that's not what you meant.
> have seen less success than we have financially and in terms of community growth metrics.
You're barely starting to pick up speed, and there are so many ways left for you to fail. Much of your recent growth is due to Elixir starting to implement types but not having really arrived yet—sparking interest in the competitor who already has them. How long do you think you can ride that wave?
You've come off in this thread as rather arrogant and self assured, which are good traits for a lone wolf but dangerous traits for a community leader. I've been on the fence on whether to adopt Gleam, but I've honestly seen enough here to know that it's not worth investing the time right now. You may course correct and save the project, but the way you talk about your success as though it's something you achieved in the past through your own efforts doesn't make me think it's likely.
You've also likely seen enough of me to know that I'm not someone you'd want in your community, so I'm content at this point to part paths amicably.
I'm sorry but I don't think you're right here, I've not detected any increase in any Gleam growth metrics when Elixir type related things happen.
If anything we see Elixir have a bump when big things happen in the Gleam world, such as their GitHub start count increasing when Gleam v1 went viral.
I do agree though that we're only just picking up speed! Watch this space!
> It's not just the far right that's uncomfortable with this kind of policy and rhetoric
It really kinda is though. HN commenters generally lean a lot harder right than they are aware of and/or want to admit. This belief about a "growing tendency towards sheltering oneself and others from all emotional discomfort" is straightforwardly a right wing view.
> HN commenters generally lean a lot harder right than they are aware of and/or want to admit.
That's a perception that is common among left-wing commenters who find themselves exposed here to right-wing ideas for the first time. As someone who actively seeks to represent whichever perspectives are underrepresented in a given context (down to specific threads), I can assure you that HN leans pretty firmly left. I very rarely need to take the left-wing perspective here when trying to provide balance.
(Obviously you only have my word for it, but my friends and family all think I'm a raging liberal because I represent the left to them.)
> This belief about a "growing tendency towards sheltering oneself and others from all emotional discomfort" is straightforwardly a right wing view.
If Jonathan Haidt is a right-wing activist from your perspective, then sure. I don't think most people see Haidt that way, and certainly don't think he sees himself that way.
The guy whose writings the american right loves and quotes constantly? IDK how he views himself. But his argument is a modern variant on "the weakness/degeneracy of contemporary youth" which has an inherently reactionary heart.
Your way of thinking is so... polar. Does everyone need to be sorted into progressive or reactionary? Could concern for the state of youth be simply a humane reaction to the doubling of teen suicide rates [0]?
Are you really going to ignore the calls of 'fire' just because some reactionaries cried 'fire' in the past?
I think the political right likes to quote Haidt slightly more than the left because the right is slightly less prone to blindness about this issue than the left—their priors line up. But that doesn't exclude willful blindness on the part of the left—sometimes the youth really are in crisis, and there's a lot of evidence that our natural antifragility is the problem.
FWIW I don't even neatly fit into progressive or reactionary: I'm deeply religious and it's not one of the accommodating ones. So I'm sympathetic to the right wing view on this, holding it to a significant extent myself.
I'm not dismissing this position because of similarity to other reactionary movements in the past, I'm rejecting it because of how this reactionary movement is using it to mobilize a revanchist assault on the rights of minorities, women, queer people. An issue that "rational centrists" like Haidt and the general consensus of HN commenters certainly seem blind to and sanguine about their part in.
We can't just abandon teens to suicide because right-wing revanchists use the same data to attack other teens. That's exactly the kind of dodging of uncomfortable truths that I'm concerned about—we plug our ears and pretend it isn't happening so as not to hurt one group of people. Because we can't deal with the dissonance everyone gets hurt.
They're both functional and on the same runtime, but they're very different languages. I think the best way to understand the different experiences they offer is to try them both.
I don’t think that Elixir’s types and Gleam’s have much in common, they will provide very different experience. Coupled with there not being much crossover from the Elixir community to the Gleam one I don’t think it’ll have much impact on Gleam.
First, let me make it clear: I'm not trying to knock Gleam and it's type system—it's really cool what you've done.
> Not much crossover from the Elixir community
Interesting! I didn't know that. For the die-hard ML-style type system fans (of which I am one) Gleam will absolutely be the most attractive thing on the BEAM block. I think there is a small contingent of developers who would really rather have a type system who might choose Gleam, but that Elixir's new type system (when it matures to support user-supplied annotations and whatnot) might suffice. I think it's an interesting case to see how adding a type system might shift people's preferences between two established languages.
That said, again please don't see this as a knock on Gleam or me trying to say "well now Gleam is obsolete"—I'm not trying to say that. I hope Gleam has an illustrious future. :)
I thought would be the case too originally, but now that Gleam has been known long enough to get an idea for the sort of people who are attracted to it I don't see Elixir getting types having any real impact on Gleam's uptake.
Elixir and Gleam are very different languages offering very different things.
I think you may be thinking of some other language.
Gleam adds no overhead to the target platform used and both the Erlang VM and JavaScript runtimes have respectable performance. The Erlang VM specifically outcompetes F# for networked services, which is its main use case.
This applies to the entire BEAM family. HN loves to sign praises to it yet never looks into the detail nor has performance intuition to know that the use of predominantly interpreted languages is frequently inappropriate (note how Erlang is next to Ruby):
With that said, I had no idea it could target JS and will need to look into that, thanks (V8 is surprisingly competent at number crunching if it can inline everything, otherwise still subject to harsh limitations of dynamic nature of JS).
Also, F#, building on top of .NET, has rich ecosystem and a set of its own async abstractions with all kinds of actor patterns being popular (within very small F# community that is). It’s fast, and so is its networking stack.
Why am I criticizing Gleam? Because we had two decades of programming languages built on slow foundations imposing strict performance ceiling. There is no reason for nice languages like Gleam to be slow, yet they are. I’m not sure why, maybe because of the myth of compiled languages requiring more effort and interpreted languages being more productive to write in?
I suppose if you want to do some distributed mandelbrot in Erlang, you'd just use NIFs to use an actual systems language for compute.
> maybe because of the myth of compiled languages requiring more effort and interpreted languages being more productive to write in?
Erlang focuses it's ergonomics around distributed processing, dispatch, and communication. Some of that is really in the decisions around the language (e.g., fully functional, hot-swappable and remote dispatchable modules (using message passing), metaprogramming, pattern matching), the runtime (e.g., genserver, the supervisor, lightweight processes with isolated garbage collection), and the core libraries (e.g., ETS, http client/server), but also it's the ecosystem that has built around the Erlang because of its soft real-time flavor. If things like soft real-time, high process count, network dispatch, etc. aren't really interesting to you, and the language isn't your cup of tea, then you aren't the target market for Erlang and its ilk. But certainly it is useful and productive for a number of people/orgs who've made the leap to OTP based on actual business value (e.g., Discord and (historically) Whatsapp)
"Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!"
This together with misunderstanding Donald Knuth's quote (it was talking about not hand-writing ASM rather than throwing the baby out with the bathwater) is why we don't have nice things in places we are ought to.
You have a set of tools with comparable degrees of features and productivity*, but one of them comes at a steep performance cost, perhaps you might want to pick the one that is snappier and easier to use?
* Though one could argue F# offers more in regular niceties at the cost of not having distributed framework built-in, requiring you to reach for Akka. I certainly find F# significantly easier to read and write than Erlang.
Or write it in a language where you don't even have to think about it.
(you have to maintain separate toolchain and exports in Rust, to achieve this, and complex types cannot be easily exported/imported - it is subject to limitations of C ABI, and FFI is not free either, even when as cheap as it gets - .NET has that with P/Invoke yet still it is a deoptimization in data-intensive algorithms, which benefit from being rewritten in C#/F#)
Complex Rust types are absolutely supported with Rustler. And with one command I can have Elixir pull a Rust crate and do 80% of the work setting it up for me to be able to use it in a project.
Picking Erlang for number crunching is a Bad Idea™. You can use NIFs in C or Rust though for expensive computations. If you play to its' strengths it outshines the competition eg WhatsApp and 99.999999999% of uptime (that is a few seconds of downtime per year). Horses for courses.
> HN loves to sign praises to it yet never looks into the detail nor has performance intuition to know that the use of predominantly interpreted languages is frequently inappropriate (note how Erlang is next to Ruby):
And you seem singularly focused in your belief that .Net is "the answer" every time a post promoting a BEAM ecosystem language comes up. It's clear you like .Net - good for you. It's solid and has nice features. But you're painting performance as some sort of absolute. It's not.
> Also, F#, building on top of .NET, has rich ecosystem and a set of its own async abstractions with all kinds of actor patterns being popular
What if I don't want "all sorts of async abstractions", but just one that works well?
> Why am I criticizing Gleam? Because we had two decades of programming languages built on slow foundations imposing strict performance ceiling.
And those programming languages have been used to develop sites like GitHub, WhatsApp, Facebook and countless other internet-scale apps. Every language and ecosystem imposes some form of performance ceiling. If performance was all that mattered, we'd all be writing assembler. It's about trade-offs: some of them technical, some of them social.
.Net is a mature, stable, and performant ecosystem. You do it a disservice by rubbishing alternatives per your original comment ("Impossibly slow, just use F#").
You're not seeing the fundamental trade-off that BEAM is taking.
They're not focusing on maximizing througput (number crunching) but on minimizing latency for the 99th percentile (keeping the server highly responsive even under heavy load).
You really need to understand the pros- and cons of each tool. Dismissing the BEAM family because of a single attribute strikes me as a bit ignorant.
> Maybe one of the next BEAM languages will handle that automatically for us.
It not being automatic is a feature as that pattern is only what you want in the trivial case, but in real programs you are going to want more control.
In early Elixir there was a relatively popular macro library[1] that offered what you ask for (see code example below) but as Elixir matured and started being used in more than toy projects it was largely abandoned.
Great. That was basically all we used of GenServers in the Elixir projects I worked on. I remember one or two handle_info but nearly all our GenServers were (in OO parlance) objects with methods to update their status, trigger actions and sometimes read the status.
We take moderation very seriously in Gleam, and I assure you this poster has omitted much of the context here. If you have any concerns please do get in touch with the moderation team either on discord or via "hello at gleam.run". Thank you.
reply