The implication is that all remote work is part time effort for full time pay?

> The implication is that all remote work is part time effort for full time pay?

Which wouldn't match my experience. It is exactly the opposite unless you count being present physically somewhere as work.

I think that’s a bit of a stretch to say go will implement all the features of c# and Java because of a few new features. Go isn’t a frozen language, they just take a lot of time and discussion before committing to a major change.

The point isn't implementing all the features of c# and Java, rather doubling down on their simplicity mantra against all programming language complexity, only to revisit such decisions years later, because after all the other programming languages had good reasons to have such features in first place.

If you look back at the mailing list from earlier in the Go development you'll see that this was the plan. To start with as small and simple a set of features they felt was a necessary and evaluate more advanced features as the language evolved while trying to keep with the simplicity mantra when adding them. They wanted to evaluate the potential features in light of real work with Go.

I have a feeling that in the future developers are still going to be needed, but in an architecture and debugging/optimization fashion. Not in a writing boilerplate code aspect. There is also an issue with validating the output before it gets released to production.

Not surprising. Every company is going to take the opportunity to trim costs when it doesn't affect their PR as much as it would any other time.

And not doing so could affect their IR (investor relations) negatively, which is a higher concern than PR to most companies

Why can't a company do offense on the IR front with literally any action other than cutting workforce?

"Our products are better than ever" "Our revenue per employee is better than ever"

Why does cutting costs have to be the only way to please investors?

Because most investors are investing in more than one company. If someone has a stake in Google, Microsoft, and Confluent, and their ROI for the first two are great this quarter, but Confluent is lukewarm or even in the red, they're going to want an explanation.

They can be told that products are great, or employees are producing a lot, but the only thing that matters to investors is the money. And so, when you're underperforming compared to others in your market, you have to do what appeases the shareholders, and that involves culling employees.

This needs to be a video game, not the way we organize humanity :(

I have no unique insight into their perspective but if I had to guess they're starting to worry about the lack of easy money and want a signal that management is going to play it safe with their current cash reserves instead of banking on another infusion. They probably could, you know, tell them as much, but sacrificing your employees really adds oomph to your commitment.

Every company that mishired.

You don't cut costs if they aren't costs.

If you hired employees to do something and they're making you money hand over fist, you don't fire them. They're not an expense. They're a profit center.

It's going to take a little more than a sed statement to make this change

I think this one difficult subject does not take away from the common feeling that overall Go is simple. This is like looking at a small scratch on the car and claiming the entire car is damaged.

“Simple” means the definition has been kept compact, which should suggest problems went unaddressed. Gabriel’s “Worse is Better” essay reminds us that making a system do the Right Thing™ is rarely simpler.

But making the runtime go out of its way to store the exact type of an object you don’t have is damn weird. In theory a method could accept a nil receiver, but in practice they never seem to.

But as products evolve, their boring names become misleading. At least with non-boring names you can re-define what they represent in your company.

Do products/components really evolve so much that the name frequently become outdated?

Half the article is like, "There was a component called YamlParser, which is now a browser-based stable-diffusion renderer!"

I've worked on tools that were slightly misnamed after 6 months, and completely misnamed after 2 years. At that point they were also usually just nearly useless due to feature bloat and/or lack of scalability, so deprecated or replaced with something better.

They didn't change names, but their successors would get a new one.

Yep, enough that they need a caveat every time someone new is told of the product. It happens, and it's gotten worse due to Agile.

Look at IBM "Watson". It had evolved from an AI jeopardy and Q&A engine into basically whatever salespeople make up.

Isn't it even harder to re-define names in a company? There might be 3 people involved in re-definition, but it affects 15 people.

How are we going to notify those 15? Do we even know who those 15 are? Are we going to create a weekly redefinition newsletter?

I think in most cases new meaning deserves a new name. Everything else is just hacks.

How hard is it to change a name is a actually a really good metric for a company. If a simple rename takes several days, multiple approvals, rounds of QA, and a scheduled release next quarter, then you probably need those hacks.

I think that's very extreme. Products grow at a gradual pace. I don't think there are defining moments when a product no longer supports something, or is no longer used in a way that it was intended to.

I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.

I appreciate the ingenuity of the solution. But I still prefer Tailwind-esque style of css styling.

They did in the article? They're not asking it to change, they're just expressing their opinion.

To me this reads as a positive to the default handlers, as it shows how easy it was to make it work into a format that works for the programmer's preference. I appreciated the solution to the complaint