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).
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).
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).
It is a point, just a very "sad point" on top of a long series of nonsense ones. Open offices are AWFUL, but so is that article. Just because I agree with the underlying point doesn't mean I have to agree with tortured logic.
Focus on noise isolation. Using ER-4P (https://www.etymotic.com/consumer/earphones/er4.html) with triple-flange tips is about the best you can get. Better even than $1000+ customs (exception made for Noble silicon customs).
I HATE open offices, but man is this article full of absolute nonsense. I mean that in a very literal way -- it has lots of stuff that can not be made sense of because it lacks context or any actual meaning.
> I stress to my patients and the parents of my patients that if you can’t hear anything going on around you when listening to headphones, the decibel level is too high.
This is just stupid. It ignores type of headphone entirely. IEMs like the ER-4P (https://www.etymotic.com/consumer/earphones/er4.html) have insane noise isolation (up to 42 dB). When using them, I can't hear someone talking to me, standing right next to me, with no music! They physical block the ear canal and create a seal blocking outside noise.
> As a rule of thumb, you should only use [personal audio] devices at levels up to 60% of maximum volume for a total of 60 minutes a day. The louder the volume, the shorter your duration should be. At maximum volume, you should listen for only about five minutes a day.
Again, idiotic. "60%" is entirely meaningless. It might as well be "Don't listen above FALASFDABURAGA". Headphones vary in sensitivity vastly, on some sets of IEMs -- 60% would be ear bleeding, deafeningly, painfully loud. On a high impedance, low sensitivity set of big headphones, 60% is a whisper. As a "rule of thumb" all it does is reinforce that the person who gave that quote is an idiot.
> If you listen to music with earbuds or headphones at levels that block out normal discourse, you are in effect dealing lethal blows to the hair cells in your ears.
... again, quotes from people who have no understanding that there are different types of headphones. MAYBE you could claim with fully open headphones this to be the case... but what is the level of "discourse"... sigh. Again, literally nonsense because it is impossible to make sense of...
> ... Music Is Distracting (entire section) ...
There exists multiple categories of music WITHOUT WORDS! Shocking I know. Most developers I know listen to these types of music because, lyrics are distracting. That isn't a cut against headphones.
> ... Feeling of Vulnerability ...
Getting to some sad points. Again, I hate open office plans, but come on -- really -- the feeling of vulnerability being caused by headphones? It is caused by an open office layout.
> In the rare chance that your true love coincidentally happens to be in a class you teach...OK, stranger things have happened in life. So do the adult thing: quit your job, then continue the relationship. True love should be stronger than the benefits of a tenured position. Don't screw it up for all the other poor students whom the gods did not make to be your soulmate.
It doesn't even need to be that extreme. I don't think a student and professor can't be on the same campus, the only thing that would need to happen is the student to drop the class.
That trivial, that simple, that easy. If you are screwing a college teacher, you can't be in that class. In the RARE case were the class is absolutely essential and only taught by a single person, then yeah, might need to quit for true love... or find a way to get that credit elsewhere.
> if you would like to add your company to this list...
Sadly, in the near term, the Rust boat has sailed. LTS releases would give a real good reason to reconsider if they ever come about. What support durations are you considering for LTS, and where can I read more?
Well -- if we are going into what I would have preferred. I would have preferred a rest period after release. No ongoing changes across 3 trains on a 6 week cycle. Give the community time to accept, adapt, bitch, moan, whine, create workarounds, and then better workarounds. Let enterprises have time to buy in, test, accept or reject and give feedback. Deal with critical issues and focus on stability as a deliverable... and don't break anything during the rest period (even if that means being on a single version of LLVM and no new traits or modules or functions or whatever). But, that ship has sailed.
> I'm not sorry for doing so much development in the open instead of behind closed doors
Who asked you to be? I was simply pointing out the reality that Rust has a reputation to contend with -- you can't change that be being righteous about it, it just is.