Looks like Auckland NZ is planning on following this trend by building two tram lines over the next 10 years (CBD down Dominion Rd to Airport, another CBD to West), 60 years after following Sydney's lead of tearing out the trams (first replacing them with electric trolley buses, then removing the overhead lines 20 years later).

I don't see either line making a financial return on the investment, but the NZ government is financing it all by plundering the NZ Super Fund, which was originally intended to provide super payments for NZ's over-65-yr-old retirees. Of course, they're framing it all as "the Fund is making a long-term investment in the country's transport infrastructure", making the eventual huge losses some other goverment's problem.

> I don't see either line making a financial return on the investment

Do they get a financial return on the roads they build?Infrastructure (and practically all government services) never make money, that doesn't mean they aren't worthwhile.

If you're putting the country's pension fund into it you need a financial return. Otherwise you're not making an investment, you're just withdrawing money from the pension fund.

> At some point I switch to full Groovy projects, switching on static compilation

If you let your Apache Groovy scripts get too large before switching on static compilation, you often have to modify the types and logic in your programs before they'll even compile. This problem occurs because static compilation was only bolted onto Groovy for version 2.0 and there's an impedance mismatch between what's required for its dynamic and static modes.

We usually call it "imagination". Not always exact though

Um... what?

Although Mandarin isn't "influenced" by Latin, it is also influenced by English. In China most everyday writing would just insert the letters "DNA" into the text.

But even for scientific writing, my dictionary translates DNA as 脱氧核糖核酸, where 脱 means peel off, 氧 means oxygen, and 核糖核酸 means RNA, so DNA = de-oxy-RNA. As for RNA, 核糖 means ribose and 核酸 means nucleic acid. And in 核酸, 核 means nucleus/core/pip and 酸 means sour/acid, so again the meaning of the characters joined together are simply the sum of their parts. That's always been the case in my limited experience with medical words in Mandarin.

You seem to be leaping to a lot of conclusions and making a lot of assumptions based on conjecture as the premise for your questions. It would be off topic and probably pointless to pursue them.

You are wrong. Groovy had lambdas even before Java 8. Netflix used Groovy only because of that exact feature.

No, I am right, because I didn't say Apache Groovy didn't have lambdas, I said it still didn't have the Java 8 lambda syntax in response to the comment that Groovy was so "ruthlessly" Java-syntax compatible. So you are wrong about me being wrong.

> Netflix used Groovy

Does Netflix still use Groovy? You make it sound like they no longer use it for new coding projects. If they do, you should have written "Netflix uses Groovy" and said what they still use it for.

> the most valuable skill a programmer can have isn't technical, but rather social: empathy

You should say "a programmer needs social skill as well as technical skills to be valuable". If a programmer doesn't have a basic aptitude for programming-like tasks, they won't be able to understand how the language works, anticipate technical problems, or organize and design systems. Until you've worked in a group that's filled with "programmers" who don't have the aptitude for coding, you won't really understand this. The social skill must complement the technical aptitude and skills, but is not more important than them. In fact, I'm even suspicious of people who say "the most valuable skill a programmer can have isn't technical, but rather social" because they often turn out to be aptitudinally-challenged programmers themselves.

"Social skill" and "empathy" are very different things. An awkward person can be empathetic. A charming person can be callous.

In fact, I'm even suspicious of people who say "the most valuable skill a programmer can have isn't technical, but rather social" because they often turn out to be aptitudinally-challenged programmers themselves.

In my experience the programmers who are saying that are usually engineering leadership. If you believe the endgame is becoming engineering leadership, then it's absolutely true that soft skills become more important.

While I don't agree that "social skills" are the most valuable skill for a programmer, I do sincerely think it is the most common reason why competent programmers hit an invisible ceiling in their careers. I've seen plenty of programmers who are technically talented and hardworking, but who get stuck in their careers at the junior end of "senior" because nobody wants to work with them no matter how right they are. If person A is right 90% of the time but nobody wants to deal with them, and person B is right 80% of the time and people are willing to listen, I would rather keep B over A because those junior developers who are running at 60% will turn into 80%-ers under B, but they'll stay 60% under A.

I think the difference is that empathy often correlates with teach-ability, and it's much easier to teach someone technical skills than it is to teach someone empathy.

Having a runaway hit isn't just about creating it, but also successfully maintaining it. Strachan abandoned Apache Groovy only 2 years after creating it so he doesn't really count. Unfortunately he let in someone without any programming aptitude into the Codehaus despotry, and was eventually eased out with stirred up conflicts like the one over builder syntax in Dec 2005. He even had his commit privileges stripped from him afterwards.

Too bad Apache Groovy itself didn't remain popular after popularizing the name "it" for the much older idea of contextually-defined pronouns in programming languages. Using the names of pronouns in English (like "this" and "it") is easier for an English-speaking programmer to understand than symbols like "$1" or "_". But because of Groovy's bad project management, another programming language (Kotlin) is becoming widely known for introducing the "it" name.

They're talking about "Go 2" the brand, not Go 2.0 being a new major version having breaking changes to Go 1.x. There are no plans for a breaking-changes Go 2, only occasional additions to Go 1.x under an ongoing "Go 2" developer relations effort.

There was discussion of a breaking Go 2 in the early days (though it would be opted-into by individual modules -- similar to the Rust edition system but with more significant changes). I think the plan now is to only have minor breaking changes -- the originally-proposed (outright breaking) syntax changes aren't in the current proposals.

But yes, the current Go 2 proposals are much nicer than the originals. But they do still contain some subtle breaking changes (though they have said they'd add vet warnings beforehand so it shouldn't be too bad).

> active COBOL use that continues today [...] 220 Billion LOC

That 220b LOC is because most newly-written COBOL programs today are copied and pasted from some other large existing program, then some small parts of it changed. I know in one large corp I once worked at, a manager ordered that instead of a new code being created for a new customer in the program suite as was usually done, every program in the suite was cloned and the new customer's name was hard-coded into the strings in the program text. That manager got the new system up and running in record time and was well regarded by his peers. The maintenance programmers and computer operators got some extra job security in the years ahead too.