6 ms·

This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dial

by haolez 7y ago

This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dialect of C++ :)

diggan 7y ago
Same with Clojure, where Rich and other core contributors decide for the rest of the community what should be worked on. I think Python is/used to be the same. Name of this leadership style is BDFL (Benevolent dictator for life) and seems to work for some projects, but you always have people feeling unfairly treated by it, while others enjoy it greatly. Guess that's the effect of being a human :) https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
- bcrosby95 7y ago
  Except those BDFLs give you escape hatches to do whatever you want. Elm removed it. It's the same as Clojure, if they didn't let you use your own Java libraries. Or if you couldn't write C extensions for Python. Rich Hickey isn't going to chastise you for resorting to a Java library if you have to, because despite Clojure being an opinionated language, at the end of the day he's pragmatic, which is why Java interop is so readily available.
  - haolez 7y ago
    Maybe this extreme limitation is necessary in the Elm's author vision. It's open source. You can always fork and implement your own vision. In fact, you're encouraged to do so.
    - tzjmetron 7y ago
      Forking is not the solution to every disagreement.
    - dbrgn 7y ago
      Did you read the blogpost? Apparently you're not encouraged to do so.
      - haolez 7y ago
        https://github.com/elm/core/blob/master/LICENSE https://github.com/elm/core/blob/master/LICENSE It looks like an open source project. I don't get your point.
        catach 7y ago
        An act being allowed legally is distinct from an act being encouraged socially.
        The_Colonel 7y ago
        Based on the core team communication, if you fork the project, you are persona non grata in Elm.
        haolez 7y ago
        But that's the point. The community close to the core team is toxic, according to this post. So, there are incentives for the rest of the community to fork the project and have it their own way. There is no need to be in good terms with the core team.
        The_Colonel 7y ago
        Burning bridges is a risky approach if you are heavily invested in Elm. I mean in normal communities it's OK to fork to experiment/support your use case but still participate in the mainstream community.
leshow 7y ago
You'll find examples on both sides. Rust is a great example of a successful language growing in the open.
- progre 7y ago
  Really growing, so much that it's kinda hard to keep up with
  - leshow 7y ago
    Oh please, maybe if all you're doing is reading hackernews articles. The language hasn't really changed that much in the last few years. The only major feature is async/await.
    - dragonsh 7y ago
      Rust is a complicated language and still has a very long journey ahead to prove its worth, I have yet to see it being used extensively in Mozilla to re-write Firefox which hasn't happened yet (may not happen as replacing C++ with Rust is a nightmare given most useful systems code is still either C or C++). Hopefully zig [1], picks up. It's compiled code is smaller and better in performance compared to Rust and also provides a mechanism to write safe code with allocator choices. Also the overall zig language design fits in brain as the grammar is not complex unlike Rust which has a steep and complex learning curve. Rust developer spend a lot of time learning language feature and fighting with borrow checker syntax and still need to rely on unsafe C library to do anything useful. Zig made a conscious choice to make it work with C and realize it needs to work with C rather than replace it unlike Rust which is relying on C and still trying to proclaim as C replacement, when its not yet ready. [1] https://ziglang.org/ https://ziglang.org/
      - iopq 7y ago
        Parts of Firefox are already written in Rust: https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation they are continuing the work to replace the least performant/secure components in Rust when it's easily possible to switch them out
d0100 7y ago
How are the Go leadership style and what OP described even remotely the same? Language safe-guarding, maybe. Imagine having your production code hostage to your relationship with the language authors... Go leadership makes me feel like the language is safe and reliable. The Elm leadership, as described by OP, just triggers my "its a sect" alarm
- haolez 7y ago
  Is it open source or not? I'm really confused about the answers.
ngrilly 7y ago
I read the post and I don't see the same behaviour in the Go community (the core team banning people who express disagreement or fork the compiler).
- ghayes 7y ago
  There are a ton of Go features that have been asked for by the community that have taken years to get mainlined. I think the most common examples are generics and package management. The authors of the language tended, at points, to be at odds with the desires of many in the community.
  - skybrian 7y ago
    Even in those areas, however, Go hasn't done the things that Elm did (according to this article). There have been a lot of experiments with Go package management, and some did get fairly widespread adoption. After many years, they are getting replaced with an official way, and there are some hard feelings, but experimentation and adoption of alternate solutions was never forbidden. Even with the official system, you aren't locked into the official package management infrastructure; there are flags and environmental variables you can set to use your own servers. There have also been a lot of experiments with Go generics, often implemented via a preprocessor. I don't think any of these got a lot of traction, but again, they weren't forbidden. Ultimately, the Go team decides based on what they think is right, but at the same time they aren't so insecure about competition that they need to suppress it.
  - ngrilly 7y ago
    Maybe, but the Go authors never banned people expressing disagreement or people forking the compiler or the tools. Almost all programming languages have features being asked by the community and not available as soon as one would hope. Modules in C++. Value types in Java. Removing the GIL in Python. Parallelism in OCaml. Higher kinded types in Rust. Etc. And most of the time there are pros and cons to adding these features or not, which sometimes evolve in a debate fracturing the community. It even happened to the otherwise peaceful Python community with Guido quitting after the decision of assignment expression: “Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”
asdfasgasdgasdg 7y ago
As far as I'm aware there are no features in go that are both fully implemented under a "for me and not for thee" compiler level guard. It's true that end users cannot have generics -- they are reserved for map, slice, array and chan. But that's not because the go team are hypocrites. They just dont have a general solution for generics yet.

by haolez 7y ago

This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dialect of C++ :)

diggan 7y ago

Same with Clojure, where Rich and other core contributors decide for the rest of the community what should be worked on. I think Python is/used to be the same. Name of this leadership style is BDFL (Benevolent dictator for life) and seems to work for some projects, but you always have people feeling unfairly treated by it, while others enjoy it greatly. Guess that's the effect of being a human :) https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

bcrosby95 7y ago
Except those BDFLs give you escape hatches to do whatever you want. Elm removed it. It's the same as Clojure, if they didn't let you use your own Java libraries. Or if you couldn't write C extensions for Python. Rich Hickey isn't going to chastise you for resorting to a Java library if you have to, because despite Clojure being an opinionated language, at the end of the day he's pragmatic, which is why Java interop is so readily available.
- haolez 7y ago
  Maybe this extreme limitation is necessary in the Elm's author vision. It's open source. You can always fork and implement your own vision. In fact, you're encouraged to do so.
  - tzjmetron 7y ago
    Forking is not the solution to every disagreement.
  - dbrgn 7y ago
    Did you read the blogpost? Apparently you're not encouraged to do so.
    - haolez 7y ago
      https://github.com/elm/core/blob/master/LICENSE https://github.com/elm/core/blob/master/LICENSE It looks like an open source project. I don't get your point.
      - catach 7y ago
        An act being allowed legally is distinct from an act being encouraged socially.
      - The_Colonel 7y ago
        Based on the core team communication, if you fork the project, you are persona non grata in Elm.
        haolez 7y ago
        But that's the point. The community close to the core team is toxic, according to this post. So, there are incentives for the rest of the community to fork the project and have it their own way. There is no need to be in good terms with the core team.
        The_Colonel 7y ago
        Burning bridges is a risky approach if you are heavily invested in Elm. I mean in normal communities it's OK to fork to experiment/support your use case but still participate in the mainstream community.

leshow 7y ago

You'll find examples on both sides. Rust is a great example of a successful language growing in the open.

progre 7y ago
Really growing, so much that it's kinda hard to keep up with
- leshow 7y ago
  Oh please, maybe if all you're doing is reading hackernews articles. The language hasn't really changed that much in the last few years. The only major feature is async/await.
  - dragonsh 7y ago
    Rust is a complicated language and still has a very long journey ahead to prove its worth, I have yet to see it being used extensively in Mozilla to re-write Firefox which hasn't happened yet (may not happen as replacing C++ with Rust is a nightmare given most useful systems code is still either C or C++). Hopefully zig [1], picks up. It's compiled code is smaller and better in performance compared to Rust and also provides a mechanism to write safe code with allocator choices. Also the overall zig language design fits in brain as the grammar is not complex unlike Rust which has a steep and complex learning curve. Rust developer spend a lot of time learning language feature and fighting with borrow checker syntax and still need to rely on unsafe C library to do anything useful. Zig made a conscious choice to make it work with C and realize it needs to work with C rather than replace it unlike Rust which is relying on C and still trying to proclaim as C replacement, when its not yet ready. [1] https://ziglang.org/ https://ziglang.org/
    - iopq 7y ago
      Parts of Firefox are already written in Rust: https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation they are continuing the work to replace the least performant/secure components in Rust when it's easily possible to switch them out

d0100 7y ago

How are the Go leadership style and what OP described even remotely the same? Language safe-guarding, maybe. Imagine having your production code hostage to your relationship with the language authors... Go leadership makes me feel like the language is safe and reliable. The Elm leadership, as described by OP, just triggers my "its a sect" alarm

haolez 7y ago
Is it open source or not? I'm really confused about the answers.

ngrilly 7y ago

I read the post and I don't see the same behaviour in the Go community (the core team banning people who express disagreement or fork the compiler).

ghayes 7y ago
There are a ton of Go features that have been asked for by the community that have taken years to get mainlined. I think the most common examples are generics and package management. The authors of the language tended, at points, to be at odds with the desires of many in the community.
- skybrian 7y ago
  Even in those areas, however, Go hasn't done the things that Elm did (according to this article). There have been a lot of experiments with Go package management, and some did get fairly widespread adoption. After many years, they are getting replaced with an official way, and there are some hard feelings, but experimentation and adoption of alternate solutions was never forbidden. Even with the official system, you aren't locked into the official package management infrastructure; there are flags and environmental variables you can set to use your own servers. There have also been a lot of experiments with Go generics, often implemented via a preprocessor. I don't think any of these got a lot of traction, but again, they weren't forbidden. Ultimately, the Go team decides based on what they think is right, but at the same time they aren't so insecure about competition that they need to suppress it.
- ngrilly 7y ago
  Maybe, but the Go authors never banned people expressing disagreement or people forking the compiler or the tools. Almost all programming languages have features being asked by the community and not available as soon as one would hope. Modules in C++. Value types in Java. Removing the GIL in Python. Parallelism in OCaml. Higher kinded types in Rust. Etc. And most of the time there are pros and cons to adding these features or not, which sometimes evolve in a debate fracturing the community. It even happened to the otherwise peaceful Python community with Guido quitting after the decision of assignment expression: “Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”

asdfasgasdgasdg 7y ago

As far as I'm aware there are no features in go that are both fully implemented under a "for me and not for thee" compiler level guard. It's true that end users cannot have generics -- they are reserved for map, slice, array and chan. But that's not because the go team are hypocrites. They just dont have a general solution for generics yet.