I'm really impressed by the syntax. I have yet to find a piece of syntax I wouldn't like. Labelled arguments for example are delightful:
pub fn replace(
in string: String,
each pattern: String,
with replacement: String,
) {
// The variables `string`, `pattern`, and `replacement` are in scope here
}
replace(in: "A,B,C", each: ",", with: " ")
> The pipe operator will first check to see if the left hand value could be used as the first argument to the call, e.g. a |> b(1, 2) would become b(a, 1, 2).
Optimizing for one less _ typed is a really bad trade-off in terms of clarity here.
Gleam did used to have this, but the community collectively decided that it was actually quite annoying in practice to always have to write `_, ` after every function
I actually agree, this is the most questionable piece. I prefer (and have argued for in JS) Hack-style pipes, where the value "placement" always has to be specified.
That allows arbitrary expressions on the RHS of the pipe, so for example this would be valid Gleam:
Gleam doesn't have auto currying! Often folks find this (currying) a bit confusing to wrap their head around when learning functional programming and we don't feel like it really affords you much that couldn't already be achieved with just a little bit more work by the programmer.
Applicative builder APIs are the only thing we've found would be much much better if we had auto currying.
Having shipped code in nearly two dozen different programming languages, there were very few times when I wanted my internal parameter name to be different from my external parameter name. The reasons are very simple:
- if your function is simple, you just use the params immediately, like in your `replace` example. It doesn't matter what they are called as long as their names make sense
- if your function is not simple, the parameters are usually immediately transformed into something else (mapped to different data, split to different data etc.), and their original name doesn't matter.
So this leaves a small weird case of "somehow parameter names don't make sense for the caller of the function", and I can't for the life of me come up with such an example (the example with replace in Gleam docs is not convincing, to say the least).
Two dozen programming languages shipped in or not, almost no languages support this.
It is something that you start appreciating a lot more once you have used it significantly. It helps a lot with writing more self-documenting interfaces that are legible at a glance.
Another detail I did not mention is that _public names are part of the interface_. This means that two functions that differ only in the public names are distinct overloads.
To give an extremely simple example (taken from Apple's docs):
This starts becoming even more valuable when you have more complex objects, and allows you to move (e.g. on some kind of repository class) mangling of overload names into more readable named argument overloads.
Does it? Instead of a single parameter you now have two names, and a type info to boot
pub fn replace(
in string: String,
each pattern: String,
with replacement: String,
) {
// The variables `string`, `pattern`, and `replacement` are in scope here
}
replace(in: "A,B,C", each: ",", with: " ")
When argument variable names and labels are combined you have two problems:
1. Labels are accidental. If all arguments automatically create labels then the programmer has not considered and deliberately designed the API. Gleam is designed to make sure that APIs are always carefully thought about and designed as appropriate.
2. Renaming a variable becomes a breaking change. We don't believe that renaming a variable should ever result in a semver major version bump.
3. Since Gleam doesn't enforce labels or check labels in any way, it doesn't "make sure APIs are carefully thought out". Labels will be just as random and accidental as parameter names following the whims of the programmer who decides to use them
1. Every class/method/function/whatever declaration is an API, doesn't matter if it's internal or which language it's written.
2. Why do you think it's better? It looks like it tries to cater to everyone, and leads to inconsistent API usage and requires teams to agree on linting rules and use tools to enforce consistent coding standards.
3. It's a tool for _you_ to design good APIs that are clear. Languages without named arguments don't give you this tool.
> So does renaming a label.
In languages without this feature, any renaming breaks the API, unlike the ones with distinct internal and external names. This is not the same.
the idea is that within the function body you would rather refer to the variables as e.g. `for s in string.match(pattern)` than `for s in in.match(each)`
In this example, the local variables are `string`, `pattern`, and `replacement`, and are implementation details; only the names `in`, `each`, and `with` are part of the public API. Renaming the local variables doesn't break anyone. Renaming the labels would break callers, just as changing the names of keyword arguments in other languages.
Without labels—i.e., with only traditional positional arguments—the example would simply be a function taking three string parameters:
replace(String, String, String)
Of course, the documentation should specify which arguments are which, but still at call sites it would be easy to accidentally permute the arguments:
replace("https://[^/]*", "", url) // wrong!
(In this case, the problem is exacerbated since different languages/libraries pick different orders here! For instance, the incorrect ordering above is correct for Python's `re.sub`, so it's easy to see how mistakes might arise.)
Labels solve this problem by making the binding explicit at the call site:
replace(each: "https://[^/]*", with: "", in: url) // now correct!
(Looking at the Gleam docs [1], it seems that labeled arguments "can be given in any order".)
Now, how does the implementation of this function look? The obvious first approach is to require the labels to be the same as the local variable names, but this often leads to awkward "grammar", because (in the convention of Gleam and some other languages, like those in the Smalltalk/ObjC/Swift heritage) good label names tend to be more like prepositions, whereas variable names like to be nouns:
Isn't this solvable just by using types and instances rather than just calling top level/static functions? If you have a "replace" function off of String and use a Pattern type instead of a raw string, the compiler will enforce the correct type and ordering.
val p = Pattern("https://[^/]*")
val in = "https://google.com/some/path"
val path = in.replace(p, "") // /some/path
In fact this specific example is solved just by having a dedicated type, for example URI:
val path = URI("https://google/com/some/path").path; // /some/path
This feels like to me an answer in search of a problem.
Looks decent. I somehow missed the previous thousand discussions.
I’d love to hear from anyone running it in production.
I have always been BEAM-curious, but never felt comfortable running it in production, as it feels like a big black box, and I’m not confident that I’d be able to diagnose problems as readily as I can in .NET, Go, or Node. I’m not sure why I feel that way about BEAM.
I think it might actually be easier to inspect the BEAM over those other VMs. For one, it is much older and stable. And secondly, the BEAM has a lot of self-introspection features.
I highly recommend the talk The Soul of Erlang and Elixir by Sasa Juric which shows off the essence of the BEAM.
Since you brought up Sasa Juric, I will second that and also mention their book Elixir in Action. It really helped me get from toy examples to feeling confident running the BEAM in production. This is of course Elixir-centric, but the parts about OTP, inspecting running applications, etc. are really about the BEAM.
Yes, that book is excellent, and I definitely recommend it to anyone new to Elixir. I'd also recommend Joe Armstrong's Erlang book, even if one is eventually wanting to use Elixir.
I transferred from Node.js to elixir for that reason.
Uncaught throws, hanging errors - while someone much smarter than I could have done it better, I was doing a lot of async/retry of APIs with high failure rate and the BEAM just made it easy.
You can put node into debug mode after launch (SIGUSR1) and remote debug it as well, with sources, which is really incredible. This BEAM demo is rad, but chrome/v8 debug is actually really good too if you take the time to learn all the remote debug tips n tricks.
WHAT. I will catch up with you after the rabbit-hole.
I’ve got massive hopes for things like Bun, but especially Deno’s architecture of message passing, but I’m now humbled by my not knowing that existed in V8.
If you compare running a monolith on a singel server then you
might be better off diagnosing problems in .Net.
Though I think that is uncertain.
If you are writing a distributed system with plenty of microservices
BEAM will be magnitudes easier to debug if you write the same system
in BEAM native
I haven’t used Elixir but I used Ruby as my main programming language for a few years and my biggest complaint with Ruby syntax is decision fatigue. There’s almost never a single clear and obvious way to do something. Overall I find Ruby syntax to prioritize cutesy aesthetics over practicality.
If you use Elixir for a while you may find that there is a lot more consistency, and almost no ‘cutesy’ code around. Elixir’s syntax only looks a little like Ruby at first glance.
Yeah, as a seasoned Ruby dev I found the "similarities" between Elixir and Ruby to be surface-level. They're very different languages. Even the syntax isn't that similar once you get past your first impression.
But don't listen to me - take it from none other than José Valim, Elixir's creator:
> Folks tend to understate the influence of Erlang and overstate the influence of Ruby on Elixir. … Ruby did influence the syntax and the names in the standard library, but the latter was also done in a more "democratic" fashion: I would look into Ruby, JavaScript, Clojure, Haskell, and choose a name that was common and closer reflected the semantics that would fit Elixir (for example, the term "protocol" come from Clojure).
The ambiguity caused by optional elements is what bothers me most. For this reason Ruby doesn't even have first class function calling syntax, since you are forced to use invoke on block objects.
I browsed the docs and found no mention of OTP. I might have missed it but it would be strange to have a language on BEAM with no native interface to those modules. I looked for examples of supervision trees and gen servers.
OTP is a work in progress available in the gleam_otp [0] package, supplemented with the lower level gleam_erlang [1]. Or you can call OTP things manually with FFI.
This is what I wrote regarding using otp in gleam. One of the issues I'm working on next is to send typed messages to processes, which has me a little stumped.
At the moment the typed channels work, you can't register () a channel or a pid.
I will likely continue working on this document once I have my current project completed.
Mmm... Erlang isn't particularly good for scripting. It has an elaborate deployment process. It doesn't like OS interfaces very much, and usually tries to offer alternatives, which are often better designed, but it also means there's a thick layer between you and the system you are scripting. While Erlang support for native code is a lot better than, say, in Python, it's better in terms of quality of the output not in terms of how easy it is to accomplish. In scripts you rarely care about quality or generalizations.
I don't see how working with types in scripts would be helpful. To me this looks like a bad idea. Everything being a string is a very valuable feature of Unix Shell. Once you have to spell out types interactively your life becomes a misery. I had similar experience having to do some testing for a mostly Linux-based product on MS Windows (an iSCSI portal that I needed to check if the MS side can connect to).
Using PowerShell is like talking to a very pedantic and a very stupid army bureaucrat, where each time you speak you have to define every word you use afresh, declare the titles of all people involved in a conversation up-front and in the end, all while being unable to connect two obviously related pieces of information because the said bureaucrat has no folder that can contain both.
So, IMO, Erlang or any other Beam language would be awesome for infra automation, and it only gets better the bigger is the organization that infra is supporting. I'm not sure there's any benefit to having ML-style explicit typing in a Beam language though. To explain this better: in the times Flash was relevant, AVM -- Flash' virtual machine was written in such a way that it had to perform runtime type checks almost every other instruction. If you could prove types statically (which Haxe did), then you could generate much tighter bytecode which lead both to smaller memory footprint and somewhat faster execution.
I don't think Beam works in the same way. So, being able to statically prove something about your code doesn't give you the same kind of benefits. And the remaining benefits could be eclipsed by the effort necessary to support the code containing type assertions (i.e. the extra testing that you need to do to assure the type assertions are correct, the increased refactoring cost and valid functionality prevented by lack of insight on the part of the programmer writing type assertions might not be worth the correctness guarantees given by these assertions).
Rust was partially inspired by F# and OCaml and actually had a much more ML-like syntax early on. Probably something similar goes for Typescript. And actually, the same for Gleam as well.
F# doesn't really relate to Haskell at all. They are very different languages. F# is a multiparadigm language that easily supports concise code in the imperative, OOP, and functional styles.
It sounds like you maybe don't know much about F# if you think it's like Haskell, which is okay. But that's also why I would recommend checking it out.
F# is not Haskell at all. If you want to write non functional code you can. It's functional first but it has side effects, mutable variables and a host of features you get in other languages. I really recommend trying it.
However, to script something small/casual I would like all the rest of Rust but with automatic garbage collection, without having to worry about lifetimes.
Gleam is written in Rust and is a nice example (besides Rust itself) of what it looks like to write a language in Rust. By my own tracking (https://github.com/alilleybrinker/langs-in-rust) Gleam is one of the most popular languages written in Rust and is one of the few top languages in that list which isn't a reimplementation of an existing language!
I feel like making programming languages is an area where Rust can really make use of its advantages without the commonly cited pitfalls. You won't be dealing with any I/O other than filesystem APIs (outside of making a standard library or something), so you can entirely avoid needing to decide whether to use async or not, and you can go pretty far just using value types and copying without it being a likely performance bottleneck. Most languages won't use much concurrency in their compiler either; Rust itself parallelizes builds per crate with Cargo, which invokes rustc separately for each compilation unit.
I'm sure some people might read all this and conclude that they might as well just use OCaml or Haskell, and those are really good languages for compilers too! The tooling and ecosystem make Rust more appealing to me personally though, and I suspect that there are probably others who would find Rust's ecosystem a bit more approachable as well.
> Rust itself parallelizes builds per crate with Cargo, which invokes rustc separately for each compilation unit.
Rust’s frontend now has support for running in parallel on nightly (they haven’t announced on the blog yet). But your point stands, Rust got pretty far all these years while keeping things simple and single threaded.
I think Haskell or OCaml would do a better job on the ADTs for a parse tree. When doing this, I found Rust's enums... anemic... and got very annoyed by the awkwardness of having to Box recursive types. I was reaching for the ability to continue to be able to pattern match on nodes while attaching common attributes (line numbers, etc.) and ended up having to bury everything 1 level deep in a struct which ended up feeling awkward.
That and Rust's iterators are terrible at introducing ownership agony.
Can you link some of those libraries? I’ve always found it harder to find well-maintained libraries that solve compiler problems in Haskell as opposed to Rust.
There are a lot of new languages coming out these days,
which I find interesting and positive.
It gives hope for evolution and better solutions to come along.
A problem is that on the surface they have similar syntax and
keywords.
I can get confused as to what language I am programming in since
some syntax nearly transfers between more than one programming language.
There are of course differences, and those differences can be
profound which is what gives us a richer eco system but my brain
gets confused by it.
Can I write time critical functions in Rust and make it available to gleam as a module? This would be an interesting way of building a distributed framework (e.g., on a cluster for scientific computing like ML) in rust.
Yes, the BEAM VM allows you to write native code in a few different ways and call it from BEAM-native languages. For Rust there is a library called Rustler that simplifies the process a lot.
To expand somewhat on the other comment. The experience of writing such functions is quite different if you have ever done this for something like Python.
Processes are central to how Beam works, and you would have to incorporate this notion into design and execution of your bindings when interfacing with Beam from native code. I.e. you'd have to consider that the scheduler needs to be able to suspend / resume your function, think about how work can be done in small time slices, preferably w/o blocking and w/o starting own processes or threads.
If you are interested in practical guidance, search for Erlang port drivers and NIFs. Often times when interfacing with eg. Python from native code, you'd run into marshaling problem. I.e. when you need to pass large and/or structured data to the native code, you'd have to do a lot of packing and unpacking of Python objects before you get something usable out of them in the native land, similarly, the other way around.
Erlang's ports are designed with some idea about how to deal with this problem. NIFs are intended for simpler things, where continued / stateful communication between two worlds isn't necessary.
It really is. A typed BEAM language (that also compiles to Javascript), a fantastic community, and a growing ecosystem. I’m really excited for the future of Gleam!
Gleam is a fantastic language but I didn't see much about testing apart from a very small package called gleeunit which is a binding to Erlang eunit. If I don't know anything about Erlang, how do I do tests in Gleam? I need some more guidance on this.
Gleeunit seems a bit sparse. I just see a few functions. For example how do I do mocks? Is this the the whole testing story assuming I am not targeting JS?
Mocks are deliberately not supported by Gleeunit as I (the maintainer) believe they are strictly worse than using dependency injection, and often result in dramatically lower quality code.
Fair enough. In your opinion, is Gleeunit sufficient as a testing framework for Gleam or is it a work in progress which is also understandable as the language is still relatively young?
I know a company that has built their entire technology stack on some Erlang VM based language.
There was really no reason to do so at all - it's an ordinary company building an ordinary application. But some CTO or dev lead years ago thought it important to use whatever the fancy tech of the day was to build a fairly ordinary business application.
But now they have trouble hiring people because there's a tiny pool of people who know that language. And it is years down the track and all their technology is built with whatever that language/framework is - too expensive to easily bail out, but probably necessary anyway.
In 2023 you've got to have really good reasons for not using C#, or Java, or Python, or TypeScript for building your web project. Maybe Golang - it's getting some good traction in the DevOps space.
If you make decisions about technologies and this latest thing appeals to you - maybe use it for your personal projects. The CEO has employed you to make responsible decisions not play toys.
>> go on any elixir forum and you will find lots of highly talented developers looking for jobs
Sure, in a downturn after a year of waves of layoffs, and maybe in San Francisco, but the non-mainstream tech will live longer than a few economic employment ups and downs.
Last 2 companies I’ve worked at have been elixir shops. Both of them had no trouble at all hiring elixir devs. At my previous company we hired close to 30 in a 6 month period in 2021. At my current bigco job we had more elixir devs pass the interview process than we have open slots (and we had a ton of slots).
I’ll also add that over many years of doing this, the elixir devs I’ve interviewed tend to be far above average, which makes up for the lower number of candidates.
If you want to hire thousands of fresh grads each year and don’t want to spend any time on training, sure go for something they teach in school.
Now with Liveview I can even ditch the grotesque React toolchain entirely.
Also, in my experience as defacto CTO of a unicorn YC company (Papa), hiring was not insanely difficult. I hired about ~45 engineers Great Ruby/Go devs translated pretty easily into Elixir after minimal training. The language is beautiful and simple.
It’s very easy to teach a good developer a new language. We use Nim for embedded firmware development at my work, and have been expanding our team. It’s been simple: hire good C/C++ devs who are interested in learning something new but related, and teaching them. Takes about two weeks before they’re comfy, sometimes less (python experience seems to help a little due to some surface level syntactic similarities)
You are describing the honeymoon period of choosing a non mainstream approach.
In time, it starts to become clear that this non mainstream thing hasn't really picked up the steam to become mainstream. Your developers are starting to realise there are no jobs advertised for Nim, so this isn't good for their career. Then the Nim project starts to stagnate. But you've written so much code in it that it's hard to turn back. But the person who decided on the non-mainstream technology - if they are still there they are defending it to avoid losing face. if they have moved on and left you the problem then the new CTO is explaining to the CEO the bind the company is in. Time to start planning the budget for a complete rewrite in the language that is standard practice for the industry for this sort of thing.
At this point, C++ ain't looking so bad for this sort of project.
You are describing programming as if the language being used is the primary work skill and as if devs are somehow “trapped” by the language they happen to be paid to use at the time.
I live in a very different world and over the past 13 years have been paid to write Obj. C, Python, PHP, CSS, JS, Ruby, Elixir, Golang and a small amount of Rust. All are still useful skills that I’m likely to encounter again.
In a few cases, I used languages that later lost steam (Flash, CoffeeScript and Elm). It wasn’t a disaster, though. I just took what I’d learned and moved on.
Whereas not a single shop has gone down the road of picking some Javascript framework which stagnates or significantly changes over major versions and requires a lot time/money/effort to migrate.
The point of Nim is that we’re exercising all of their C and C++ skills as one of its venefits is being able to leverage existing drivers and modules for peripherals. Nim is C, at the end of the day.
I’m not some fresh faced 20 something, I’ve got nearly two decades in industry at this point, and I just frankly disagree with your assessment.
Where did the rest of the code come from, or who made the decision to start that way? They should at least be able to spearhead it. Obviously it's different for tiny organizations, but generally, if someone inexpertly made architectural decisions without building the institutional knowledge to continue without them, the language they chose will just be one of many big problems.
And those people shouldn't be in executive roles, even in smaller organizations. Being able to mentor people is a basic management skill and is why blindly making engineers into dev managers based on seniority is idiotic. If you have someone incapable of mentoring people unilaterally making those decisions without a counterpart that can, that's not a problem with the stack-- that's a problem with management that will manifest itself in countless other ways.
i've shared this story on here before, but years ago i worked for a startup where we had a janky homegrown distributed system cobbled together from a mix of python, rabbitmq and state stored in postgres tables. four of us, two senior and two junior engineers, decided to see if we could learn erlang and build a more coherent and well-engineered replacement for it. it took us four months, starting from never having used the language, to learn our way around it and set up a proof of concept that was both more performant and more stable than the existing system. and this was all while doing our regular work as well. erlang is an extremely simple language to learn and become productive with, especially if the task you're trying to do fits the grain of the language and beam environment.
(ironically, the erlang solution never went anywhere because management decided they did not want to take a chance on a lesser-used language. but from a getting employees standpoint it's perfectly feasible to hire people who are simply good engineers in whatever language and give them a month to learn erlang.)
>But now they have trouble hiring people because there's a tiny pool of people who know that language
>In 2023 you've got to have really good reasons for not using C#, or Java, or Python, or TypeScript for building your web project. Maybe Golang
In my country, very few people know Go, so we hire devs without requiring them to know Go - we teach them the language, and after a few weeks, they already feel pretty confident with it. In fact, most devs are actually interested in trying something new, some new language.
Maybe your employer's problem is that they are only looking for CVs where the language is mentioned as a keyword, and don't consider anything else?
There's always a good reason not to use C#. That's actually the number one language that is crossed out of the candidate lists due to the company behind it and very "uneven" platform support.
As for using a unpopular language. My (mostly untested) conviction is that if this unpopular language is still popular among an albeit small group of programmers, it's a blessing. While hiring is difficult, you get much higher quality human resources. You get to enjoy working with smart people.
I've known a company whose business was to track real estate values. They had a Web site and some backend that did somewhat complicated statistics trying to predict prices or rent based on all kinds of factors they aggregated. A lot of the functionality of the backend was in scraping local news, city authority documents etc.
They wrote everything in Clojure (including front-end, which was Clojure-script). Great people, created a great, useful and successful business.
I've worked in companies early adopters of Go and Rust. It was a great experience. I've learned a lot during that time from my coworkers. I also briefly worked for a company whose main product was written in D. It was another great place to work in terms of quality of human resources and the quality of code I had to work with.
This sounds fun until your entire stack is on Perl in 2023 (which, is fine-ish when your CTO was the perl project lead). But then you have a bajillion dependencies that aren't really updated anymore, you end up owning most of the Mail::Toolkit libraries, etc. and nobody really knows perl that well. I mean, a lot of us can jimmy around in Perl, but of the real Perl Gurus in the world, you will end up hiring 50% just to keep your company going
>> I hire based on ability/intelligence, not knowledge.
Well, yeah that's really your only choice if the experience you need is not easily available.
Don't tell me, you are the guy who puts in the not mainstream technology and needs to defend that with justifications such as "when we use (non mainstream technology X) we get super motivated job applicants because anyone with an interest in non mainstream technologies is inherently passionate and interested".
And you are the guy who left Visual Basic, COBOL, Perl, and FORTRAN off their "obviously safe choices for hiring in the future" list, despite them all having once been perceived as such.
These inconvenient counterexamples blow up the entire thesis. In practice, the "safe choice" for longevity is only evident in hindsight.
If anyone is hiring for TypeScript in 2050 I'll eat my hat
I'm in sympathy with your main argument, but given that people still, in 2023, hire for COBOL, a language made in 1959, makes me think you'll be eating your hat.
Notwithstanding that I'm effectively forecasting the decline & fall of TypeScript as javascript-flavour-of-the-month, note that I shrewdly also granted myself the better part of three decades to launch an edible headwear startup
Most of the perceived value that Typescript brings will probably fade once js gets type annotations [1], though Typescript will always have more advanced syntax and capabilities.
There are interesting discussions about Typescript becoming more of a run-time type checker, which would be opt-in and have significant performance penalties, but would give more guarantees of type safety.
"Ability" by itself is a bit vague here, but I will say that having a proven trackrecord in their ability to learn is something I specifically look for in a candidate. Not only learning new tech, but also learning from mistakes and experiences over time.
However, I don't think raw "intelligence" is the right metric for hiring. Unless you specifically mean emotional intelligence, which can curtainly contribute to improving communication skills on the team.
I've also found that when hiring someone with mostly expertise outside your current stack it's critical to provide good feedback loops and mentoring early on so they can "get up to speed" and contributing valuable, idiomatic code as fast as possible without feeling as though your entire onboarding experience is trial by fire. This mentoring takes up extra resources and is a net drain on your team in the short term, but pays off in the long term.
Just curious, what are some of those footguns your team is encountering? Only thing that comes to mind is the somewhat tedious error handling imposed by the language. Which language would you say had _less_ footguns than go? Or was this sarcasm and it went straight over my head?
I can't speak for Discord, but at WhatsApp, we chose Erlang for a very good reason: ejabberd is a very clear base to start with if you want to run a chat server, and ejabberd runs on Erlang. At least Facebook, WhatsApp, Riot Games, and Discord have done it, and I think there's plenty more.
While I was there, I was the third most Erlang knowledgeable server hire, because I rememebered Ericsson open sourcing it decades ago, but hadn't used it before. We hired two people I can recall who were experienced with Erlang (well, and a client developer who used Erlang in school but didn't use it for WhatsApp).
This wasn't a big deal, Erlang is a small language, and smart developers pick up enough to be useful pretty quickly. There's a learning curve for distributed systems challenges, but IMHO, message passing concurrency makes a lot of things a lot simpler than shared memory concurrency, and you can get a lot of good work done where the new person does the bulk of the work and a mentor helps with distributed systems bits.
Anyway, Facebook chat decided to abandon Erlang for hiring reasons, and transitioned to a C++ server, and I don't think it was that hard; Erlang wasn't some boat anchor holding them back when they decided to switch, like the GP suggested. Even if it was, that's kind of an amusing complaint: this thing is so awful, and we can't even replace it because ??? it's too good?
> Even if it was, that's kind of an amusing complaint: this thing is so awful, and we can't even replace it because ??? it's too good?
Obviously they were suggesting that rewrites/changing your tech stack for a project is expensive and not everyone has the luxury to do it. Facebook does.
An important recent learning about programming adoption is that a good community is absolutely key to drive growth. Makes sense to establish the principles.
this has nothing to do with community or even inclusivity and everything to do with signaling political allegiance & telling people who don’t agree that they aren’t welcome
It is quite literally the opposite of what you and others supporting this are claiming it to be
All you have to do is remove the weird bit about “nazis”, which is irrelevant and adds nothing of value to the statement anyways, and you’re not really going to scare any normal person off. But this is just over the top and literally the only purpose it could serve is as an exclusionary political signal.
From what I've encountered, the main principle of this activism seems to be around reorganising society by 'gender identity' in place of sex, and redefining language to further this aim. I'd be interested to hear your perspective on this.
Casually using “Nazi” like this in context of American politics just means “anyone to the right of me”
it’s ambiguous but the implications are clear
If you are a Christian, someone who would use this phrase would likely call you a Nazi. If you don’t want to abolish the state of Israel, they might call you a Nazi. It could be any issue really. But to actually be “safe” in an environment like this you have to align yourself roughly to the politics of the DSA or you aren’t welcome.
I guess you could say at this point that “Nazi” has devolved into being a sort of a political slur referring to anyone who is not sufficiently leftist.
That's a lot to bring to a random footer on a web page about something else. I get the distaste for sloganeering but the suggestion that 'the implications are clear' that this is.... the DSA? feels like a more than a bit of a reach.
It is a reach and that’s kind of the issue I guess. You have no idea whether or not people involved would call you a Nazi or what for, only that they might.
I am probably overreacting to this because I have encountered it in the workplace before. Politics constantly being brought up inappropriately & the only safe move was to go out of your way to signal to the right people that you were on their “team”. The occasional political witch hunt over nothing would happen. A good portion of the company spent most of the day talking politics instead of working but I assume nothing was done out of fear of retaliation. A lot of really bizarre things, but hopefully not the norm.
You have no idea whether or not people involved would call you a Nazi
You have no idea of that whatever footer they put on their page, short of one that is 'we like to call people Nazis'. The reaction is as if someone's already called you personally a Nazi and the footer doesn't do that.
Again, I get the discomfort with the perception you might have different political views from whoever wrote that footer. But that's the discomfort of difference that comes with everyday life. Nobody has called anyone a Nazi, that's not a reasonable extrapolation from either the footer or your unpleasant personal experience combined with the footer.
It is best understood as a social contract - in order for a group to function, people need to tolerate each other. People who don't obey that social contract are therefore not eligible for being in the group.
Yes, but in most cases I have seen that is just used as a justification for hostile behavior that has nothing to do with actual intolerance. The opposite tends to happen - you let people like this get power & their intolerance is then what is tolerated out of fear that they’d come for you next if you called them out on it.
An example: I once had someone tell me to my face that I shouldn’t have an engineering job at all because no white men without a college degree should be “allowed” to. At work. However, this person was involved in ERGs and close with people in HR, so I didn’t have much choice but to just accept it and move on.
Another good example I’ve seen personally: employer hires a new CTO. He sets up the second phase of our interview process to be a phone call with him, and out of dozens of candidates he only allows Muslim candidates through this process. This was the clearest case of discrimination I have seen. When someone on my team speaks out about this, he’s fired and we are all scolded about racism being unacceptable.
This isn’t a social contract, it’s organized harassment and abuse by politically obsessed weirdos and it has no place in any professional environment.
"Black lives matter", "trans rights are human rights" and "no Nazi bullshit" are completely uncontroversial positions though. Like, if you disagree with those, then there's something fundamentally wrong with how you view the world and interact with other human beings.
No they're not. They are common phrases used to shoehorn a lot of politics and meaning into a simplified message that doesn't really reflect everything it stands for.
Everyone knows this and it is highly controversial which is the point. I don't agree with any of these things because I know what they mean in reality.
Casually calling people nazi on a website for a programming language isn't really cherrypicking and I find it to be quite interesting and very influential in my decision NOT to use this language.
This message is right in your face, it isn't like you have to search for it.
the actual effect of enforcing this rule in this circumstance is basically to say that implicit political loyalty tests are a normal thing to have on a website for a programming language
on a surface level the statement isn’t controversial in any way, but the particular language that’s used signals something else entirely
No, the rule is about not going on irrelevant tangents and not dingleberrypicking stuff from submissions. Its actual effect is that such diversions get moderated by users and moderators, just like this one did by users.
Not sure what this was since it appears they just have a link to the code of conduct now.
The type of statement isn’t really the issue, but the specific language used being in the form of political slogans and the “Nazi” bit. I don’t remember seeing anything quite like that on the Go page. Or any other programming language’s page.
The daily standup is not the right forum, for example. The pub after work? maybe.
The previous part of the community statement gets the "we're going to be nice, and not discriminate, and focus on the language itself" point across just fine.
Signaling that you want to inject politics into an inappropriate context signals that you may be the type of project that will do unpredictable things when the political mood strikes and makes it less viable to depend on you.
I couldn't agree more. Injecting personal political advocacy into a professional context is itself unprofessional and raises large numbers of questions about fly.io and the Gleam project's ability to operate in solely professional context.
It's this "turn everything into activism" bullshit that people across the the political spectrum engage in on social media that got me to cancel all my social media accounts some years ago (present company excluded).
The other problem with these statements is they can never get rid of them, because the people that like them will freak out if they do that. It's like the land acknowledgements we have in Canada that keep getting longer and longer and will never go away unless the pendulum eventually swings
The moment someone raises a ticket that says "hey, maybe we should put 'no nazis' in the FAQ", you, as the FAQ maintainer, have to make a choice. Whatever you choose is a political choice, even ignoring the ticket. Fencesitting is a political choice too. It's just unavoidable.
If you came into my FAQ and wanted me to put medical advice in it we would not see my refusing to engage with the concept with it as medical advice in itself. (I would not be seen as either for or against the medical advice, in fact people would wonder why the heck you were suggesting I put medical advice in my software FAQ!)
"this isn't the place for that" used to be a very well understood concept, and everyone was able to respect that, whether it was in the workplace or over Thanksgiving dinner. We just stopped enforcing that and started treating "not here, not now" as though it were taking a side.
Have you read The Analytical Language of John Wilkins by Borges? It crops up here occasionally. If not, I'd totally recommend it.
When you draw up rules for an FAQ you're delimiting a box and saying "the stuff inside the box is part of my model, and the stuff outside it is not". The person suggesting you put advice about raising suckling pigs in your Emacs FAQ (picking the most extreme example I can think of) is suggesting you redraw the box - change the model. I'd still say the decision to redraw the model or not is a political decision. I'd also say that saying "no" is obviously the right decision. But still political.
I admit my definition of political (any action or decision that affects how people relate to each other or how resources and opportunities are allocated) is maximalist. We could, at root, be talking about different things.
I haven't read it, but I'll add it to my reading list!
I suppose I have to agree with you that the statement itself is political, given your definition. In which case I'd simply re-phrase my argument. We used to have political neutral zones, where we agreed that we'd try to avoid overt political discussion, and we'd politely ignore those little statements that are "still political". In your example we would all be able to agree that "no" is obviously the right decision regarding the FAQ additions, and we'll all politely ignore the fact that we have differing opinions about the politics of raising suckling pigs. Neutral territory where we can put aside our differences and focus on something bigger.
We've lost a lot of those spaces, which is sad because those neutral zones are critical for the functioning of any ideologically diverse group of people. We have a word for a space where everyone must agree, and must all say all the correct phrases: cult.
We need to build communities, not cults. And to do that we need to be able to agree to disagree about things.
(Back when I was doing a lot of Ruby "Matz is nice and so we are nice" seemed to me to be about the best community code of conduct you could hope for!)
Foucault wrote: "This book first arose out of a passage in Borges, out of the laughter that shattered, as I read the passage, all the familiar landmarks of my thought [...] breaking up all the ordered surfaces and all the planes with which we are accustomed to tame the wild profusion of existing things, and continuing long afterwards to disturb and threaten with collapse our age-old distinction between the Same and the Other."
Well sure, if weirdo runs up to me and starts asking me what I think of Nazis, anything I say or don't say could definitely be looked at with a political lens. Doesn't mean I'm being anywhere as political as the weirdo.
Suggesting to mention Nazis in the FAQ is extremely political. Closing, ignoring or fencing the ticket is much less political.
It's up to everyone whether you want to raise or lower the levels, keeping in mind what you actually want to accomplish.
The status quo is the progressive theology. If billionaires fund your advocates, you have most of the elected representation, and the state-sanctioned press amplifies your views, then you're not challenging anything.
You foster a positive community by accusing the person reading your webpage of potentially being a Nazi? lmao
All this sort of thing tells me is to avoid this community because accusations of bigotry are going to start flying over the smallest of arguments and I have no interest in having people try to ruin my life because of their unhealthy obsession with politics
People are ignoring (or pretending not to know?) that these are political slogans. They signal allegiance to a rather prickly segment of the political left.
I always take these things as a kind of warning. They're telling you what their politics are, and that they're upfront about it. If you agree with that or can at least ignore that, you'll be alright. If not, don't interact.
Personally I'll use any technology regardless of the politics, but engaging with people is another matter.
They're not very specific and quite open to interpretation. As a left leaner here in Norway, I find at least the last two to be quite problematic and a huge red flag. They make me feel significantly less welcome.
Trans rights are not well defined (ie what do the Gleam team put under that umbrella), and I've seen several statements in that context that I find problematic at best.
And they say "No nazi bullsh*t", which to me is a very loose phrasing with avtivist vibes, meaning I get unsure what exactly they put under the Nazi banner. Is it just actual Nazis or anyone they don't like, or something inbetween?
trans rights are incredibly well defined, actually. they’re human rights. trans people deserve the same rights as every other human. idk what “problematic statements” you’ve heard but it sounds like you need to listen to less ben shapiro. saying you’ve heard “several” without providing any examples sounds like you just don’t like trans people.
I think it’s safe to assume that when a community claims to contain “no nazi bullshit”, they mean that it contains no nazis or their associated bullshit. if you’re worried that that includes you or people you sympathize with, ask yourself “_why_?”, because it makes a lot of sense to everyone in the quite active gleam community.
I mean you say they’re well defined but your own explanation is a vague generalization. I don’t think any decent & rational person wants to deprive trans people of basic human rights, but that doesn’t mean they’re comfortable with every single demand of activists either, which is probably the actual intent of the message.
As for the “no nazi bullshit” part, this doesn’t tell me anything except that the community has some childish and unstable people who have a habit of calling everyone they disagree with a nazi. It’s not hard to be “worried that that includes you” when there are plenty of people who would call someone a nazi for just about anything or for being even slightly to the right of them on any issue.
It has very little to do with a literal interpretation of these words, which these types always hide behind because they are cowards, and everything to do with the implicit meaning given broader context.
again, I would really like to hear what the "activists" are demanding that you think is so unreasonable.
that's a lot to assume from a couple words on a website, but if you're this fun at parties we must really be missing out.
also btw, hi, it's me, the coward who wrote the prose for the website. tho it wasn't _just_ me that thought it was a good idea. it's done a terrific job of keeping "un-politic" buzz kills away.
When 'trans rights' are demanded by these activists, typically it's because they want self-proclaimed 'gender identity' to override sex in every circumstance.
This is particularly harmful to women who need female-only spaces away from any males. Any man who calls himself a woman would be able to enter any space designated solely for women, with impunity.
This has already happened in many places that have acceded to 'trans rights' activist demands. It is a political and ideological assault on women's boundaries and consent.
> trans rights are incredibly well defined, actually. they’re human rights.
Then why can't I readily find a well defined list of what they are? For reference, the human rights are fairly well defined[1].
Of course trans people should be covered by the human rights. They're human as well, so that goes without saying.
> idk what “problematic statements” you’ve heard
I don't keep an evidence folder, so to speak, so I can't provide references.
However, I think we can agree there are extremists on both ends. It's also not a well-established term, in that it's fairly recent and isn't solidified in the same way as older terms like "human rights". Thus the need to be specific when referencing it.
> it sounds like you need to listen to less ben shapiro
Never knowingly listened to (nor read) Ben Shapiro and I couldn't pick him out in a crowd. I generally don't listen to or read much political commentary.
> I think it’s safe to assume that when a community claims to contain “no nazi bullshit”, they mean that it contains no nazis or their associated bullshit.
No, that is not safe to assume at all because a lot of people misuse "nazi" to mean something very different from actual Nazis, typically someone they strongly disagree with.
It really shouldn’t be controversial to suggest that calling people nazis on the official website for your programming language is unprofessional, but here we are…
But the idea that it would even be a concern for there to be “nazi bullshit” in a programming language would require such an absurdly broad definition of nazi that i can only assume whoever wrote this would consider a large % of Americans to be Nazis. This is inherently exclusionary. The statement is bullshit. It isn’t “Friendly <3” as the heading would suggest.
Quite the opposite if you see my other comments, I think you may have misread what I said here. This statement is clearly a problem imo, its usage of political slogans makes it more of a declaration of political allegiance rather than actually being about inclusivity.
Only if you take it literally which you would only do if you were entirely ignorant of American politics or deliberately hiding behind this interpretation to pretend you aren’t actually taking about a broad % of the population
It should be safe. Still it seems some people get offended by it. What kind of people? I can only assume they are people more supportive of autocratic regimes than the rest of us.
You seem to be applying some kind of modus ponens rule to this list. To me, they read disjointly; you can agree with the status quo regarding police violence, and that trans people should not be welcomed in society, and still not follow Nazi ideology.
Thanks for the clarification. By that, do you mean that you have no issue with the exclusion of 'trans women' (i.e. men who identify as women) from female-only spaces?
> People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally.
Except that if you don't agree with the authors political opinions:
> Black lives matter. Trans rights are human rights. No nazi bullsh*t.
Yet another project run by people who shoves politics into unnecessary spaces. I would never dare to use a project run by people that pushes their personal agendas on their website for a programming language.
I do believe that there is only two genders, man and female. Am I a nazi now or what do Gleam mean by this message? Don't use projects like this.
Personal projects are driven by personal agendas. Also water is wet. If you don't like it and you can't find the motivation to build something better, perhaps that's because your agenda doesn't drive you enough.
Why would I build something better? I am maybe not in the business nor have the interest of making a programming language.
I don't really care that they have this message (except that I find it to be pretty insulting), I just think it's an unnecessary thing to do if you want people to use what you've made. I won't and I will encourage people not to use it just because of this.
> I don't really care that they have this message (except that I find it to be pretty insulting), I just think it's an unnecessary thing to do if you want people to use what you've made. I won't and I will encourage people not to use it just because of this.
Sounds like you care a lot if you're gonna actively discourage people from interacting with the project.
> Sounds like you care a lot if you're gonna actively discourage people from interacting with the project.
If someone would ask me in the future if I heard anything about Gleam, yes then I would actively discourage people from interacting with the project. If I read about it in a positive manner in the future here or in other forums, yes then I would probably write a comment warning people about it.
If you think that is caring a lot then I care a lot. I don't consider that to be caring a lot though.
But you're also inserting politics in a technical discussion. The real issue is not that someone is putting politics in a technical place, it's that it contradicts yours.
If I say I'm interested in using Gleam and you tell me there's only two genders, I do not see how that makes you any better.
> But you're also inserting politics in a technical discussion.
The discussion is about everything about the language not just the technical aspects so no I am not.
> The real issue is not that someone is putting politics in a technical place, it's that it contradicts yours.
No I wouldn't care whatever political agendas the author hadn't he put it straight on the website calling me a nazi.
> If I say I'm interested in using Gleam and you tell me there's only two genders, I do not see how that makes you any better.
Why would you assume I would say anything about genders if you asked me about gleam?
I would say it's run by political extremists that use their programming language to push political agendas and that due to that, they are probably untrustworthy. I would say I would refuse to use it because of that but encourage you to make up your own mind.
> Why would you assume I would say anything about genders if you asked me about gleam?
Because nobody asked you about Gleam and you still brought up gender. And then you said you would continue to bring up politics whenever the language came up.
> I would say it's run by political extremists that use their programming language to push political agendas
I find it comical you think a programming language can be used to push a political agenda. That's got to be the least effective way to spread political ideology I've ever heard. You make it sound so sinister.
> No I wouldn't care whatever political agendas the author hadn't he put it straight on the website calling me a nazi.
> Because nobody asked you about Gleam and you still brought up gender. And then you said you would continue to bring up politics whenever the language came up.
No I read on the website hacker news, someone submitted a link to the language website. The website brought up gender and centered in in the page about community guidelines.
> I find it comical you think a programming language can be used to push a political agenda. That's got to be the least effective way to spread political ideology I've ever heard. You make it sound so sinister.
Well it is because it is sinister imo. Maybe it's ineffective but it's still there which is kind of undeniable. A lot of technical projects have had political agendas on their websites. React, Go, Node.js, Emberjs etc etc. I kind of get it and support the anti-war stuff for Ukraine but for normal everyday politics that's mainly american? C'mon.
> Nobody called you a Nazi.
Yes the website kind of did, since I don't adhere to the ideology that they do.
Stop being so god damn naive dude, it's ridiculous.
