True. But, open-source projects are in a bit of a pickle when it comes to tools. People always cry out for "professionalism" which I think is nonsense. In a "professional" environment, there are FAR more carrots and sticks, far more tools. There is training, promotions (carrot) and the risk of being fired (stick) and a lot of subtle tools in therebetween.
As someone who has shipped both Erlang and Go in production, I feel I can somewhat answer this.
Teams. Go does "teams" better. Shipping an Erlang app to production was simultaneously one of the happiest and most depressing points in my career.
Happiest because it did exactly what we intended with minimal code and it was done early and under budget (yey!). The initial group liked Erlang, already knew Erlang and simply were able to bang it out -- delightful!
Depressing because of everything that happened after... trying to teach DevOps crew was a nightmare, they HATED us -- all that introspection you can get on an Erlang system only makes sense after lots of experience. Trying to hire people who already knew Erlang was borderline impossible. Worse still, hiring people who didn't know Erlang and trying to train them up was swimming upstream in multiple ways -- it just didn't work. Erlang is really a bit of its own thing -- and if you are absolutely new to it, very hard to get over the hump... it is a weird pragmatic FP actor system and lacks any sense of purity or type niftyness.
... For initial development, Go was less elegant than Erlang, but due to simplicity and really solid tooling probably slightly more productive, but not so much that I would favor it over Erlang. But the magic happened when we involved other people. Handing off to DevOps was a DREAM... it was just a binary that logged stuff. They didn't need to know anything about what was in the black box. Hiring people is already relatively easy for Go, and training up developers in it is a AMAZING. You can hire basically any competent developer and a week later you have a competent Go developer... 50 page spec and dead simple language works wonders. No debates about code formatting, builds static binaries in seconds, super-easy to experiment with from minute one (versus getting your head around OTP).
I consider myself a programming language geek, I program in dozens and dozens of languages, and love building my own little DSLs. Go is -- breathtakingly boring as a language, "exceptionally unexceptional". Honestly, it isn't much fun at all to program in, it is a bit of a grind. However, Go as a tool (when the language isn't the point, the product is, your customers are) is amazing... it is viciously focused on getting things done on teams, and so far, it has been an incredible asset to our team.
I still follow and toy with Elixir in hopes that it will hit critical mass, but wasn't willing to bet my livelihood on it as a founder.
Thank you. I have long wanted to speak to someone who admits to doing this type of thing as it is very hard for me to understand.
I realize it might be painful to relive a bit, but would you be willing to go into some more detail (it is a throwaway anyway). What did you do, what were you thinking as you did it, and how could someone have reached you sooner to do 1/2/3?
That is exactly what I thought. "Stream" is the subject line. You mail to a group on some sort of listserve, which gives you a long-term history and a URL to give new people.
This exists in rather decent form in Google Groups already -- there is Google Groups for Business (with a Google Apps account) that gives you a great web interface as well as email interface all just for your company.
Rust core team has taken the approach of breakage without major version increments being acceptable as long as they deem the breakage "minor" (based on crates.io and companies they have close relationships to).
I don't want to relitigate this issue again, but that's not an accurate description of the policy. If you tell us that one of the changes in a point release broke your code, then appropriate action will be taken, regardless of who you are. No organization is given special privileges regarding breaking changes based on "close relationships" to the developers.
It is true that Rust, like all actively-maintained languages, can make changes that are theoretically breaking if all evidence strongly suggests that no code is actually going to break.
Qualifying with "close relationships to" is misleading, as every company using Rust is welcome to sign up to receive new versions of the compiler to run against their codebases to test for regressions. See the email address in my profile if you'd like to add your company to our list!
Interesting, how was the mod team picked? I think it is a good check to have it be separate from the Rust team (assuming it wasn't picked by and answers to the Rust team).
The moderation team was conceived and designed by Manish Goregaokar, an experienced moderator from Stack Overflow and a volunteer for the Servo project. The original roster for the mod team was picked by Manish and the core team, though moving forward the mod team can expand its ranks on its own. Also notice that the moderation team has no formal leader, every member has the same amount of authority. One of their explicit goals is to police the other teams, including the core team, hence the requirement for disjoint membership between the mod team and the core team.
What exactly is the goal of the group? What does it mean that they "police the other teams"? This is just out of pure curiosity, I find the idea of having a mod team for a large, public project interesting but a bit strange.
Well, policing the other teams is just part of the mod team's responsibilities.
The design of the mod team can be found in the RfC[1].
The driving philosophy is to try and deescalate any situations which may crop up, either in situ or by privately discussing with the involved parties. It's easy to forget that the People on The Internet are humans too, so a technical discussion that gets heated sometimes needs a reminder to keep civil.
The purpose is to make sure that the code of conduct[2] is upheld online. Rust has had a CoC for a while now, but it wasn't enforced. This meant that users violating it in reality were free to continue violating it without much repercussions. And this had happened a couple of times; users were warned after being abrasive but no action was ever taken and it just got worse. The mod team can enforce the CoC by temporarily blocking a user from the project if warnings are ignored. Deescalate whenever possible, and if it doesn't work out, warn/act on the warnings.
Policing other teams is a part of it; the core team and subteams are also subject to moderation; which is why no core team member is on the mod team. In case of an ugly dispute between a core team member and some other user the mod team is a more impartial way of resolving it. Though in practice I don't think the core team would ever be in such a situation.
People often say that technical communities should stay technical and not worry about civility or other social issues. In my experience this rarely turns out well, aside from Rust I've seen this idea cause problems in other technical communities. Technical communities are, in the end, communities, and community health is something that needs tending. Maintaining civility and avoiding the exclusion (active or passive) of other users is a part of it, and that's something the mod team handles.
That seems... less good honestly, but gotta start some where I guess. Friends-network effect should grow weaker with time (or at first big drama blowup).
To my expierience (since 2009), ANC works really great with steady tones such as the constant humming on a passenger plane or the motor sound of a sports plane.
But for voices, walking steps of folks, cars around you: not so much.
