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.

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?

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.

You can either remove "Source Code Pro" from your box, or use Tampermonkey / Greasemonkey to remove it from the markup.

If I could go back and edit I would -- but it has been too long.

> 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.

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.

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.