It's easy to take yourself out of this equation, but it only makes everything worse. The trick is that they make you think that it couldn't get worse. But this is always false.
2,050 karma · joined December 29, 2022
It's easy to take yourself out of this equation, but it only makes everything worse. The trick is that they make you think that it couldn't get worse. But this is always false.
But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?
Nothing, absolutely nothing about the design is a compromise that would detract from the project if it was for any other language.
You could judge them for bringing “complexity to an easy topic” but it really is far from that and the idea of a value type being a distinct dichotomy from an object is just a convenient tradition.
The push for immutability and value-ness has been going on for a long time and the motivation of the project was to bring performance benefits that align with semantic statements about the underlying data type. Which is of course a more nuanced take than “go value, go faster”.
1: Classical Object
2: Object without identity
3: Atomic Value
4: Classical Value (Tearable)
Each bucket has clearly defined performance characteristics and semantic constraints. So depending on the nature of your data, you can always get some benefit from values even if you couldn't go all the way. This is a work of art.
This is the strength of Valhalla. Instead of a binary object/value choice you have different levels of semantic guarantees that will give you better performance characteristics, depending on what your type will be able to give up.
You can have tearability for a complex/quaternion number without problem. But if you have something such as a Range-type class, that gets more problematic because cross-field constraints can be violated.
This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
It started out as a highly invasive, highly disruptive and highly experimental branch that eventually turned into a beautiful specification that put semantics and performance payoff first and syntax seconds.
1. Past policies don't dictate current policies. And current policies are wildly different from policies of 5 years ago, which are again different of policies of 20 years ago and even before that.
2. Amount of immigrants doesn't say anything about standard of living. And we all know immigration (and even illegal immigration) was promoted by all parties because this meant cheaper labor costs. And often also, exploitable labor.
And finaly... it's not a surprised that the third largest country in the world, who was considered an immigrant nations for well over 2 centuries has the most immigrants?
Sure, none of these are a problem if you earn a shitton of money... but where doesn't this apply?
Look, I'm not saying the US is necessarily a bad place to live in but I really enjoy live in a high wellfare societies and will happily trade away a good chunk of my salary for higher quality of living.
For over a year it has actually been the official recommendation to bring a burner phone to the US if you area a European citizen. To me personally, this feels like an invasion of privacy that makes me feel deeply resentful.
I am mostly comparing these places to all first world countries, rather than just the anglosphere.
To me, it would mean a significant reduction in quality of live and I am low-key scared of all the ingredients and additives in food that are pretty much banned everywhere else. Not to mention all risks regarding healthcare.