i mean marketing in some sense “feels” like fraud when presented in some very specific way, no? at some level it’s: generate interest about a thing when there didn’t exist any interest before. sometimes they generate interest about something that has no substance and that feels kind of fraudulent (this isn’t that case)
but in this case, this is product extremely boosted for super viral marketing, and this is the first time i’ve read about this boost since hearing of the product whereas everybody only really talks of its substance. feels like a magician kept a trick going for a very long time, people forgot they were watching a magic show, then the curtains come down and they reveal the deceit after (i’m being slightly melodramatic)
> For qualifying devices purchased today whose 10-year support lifecycle extends beyond 2034, Google is committed to supporting your transition to Googlebook OS, with many devices offering direct migration paths
The word "many" feels like it's pretty much explicitly saying it's not "all". If it's not "all" then I'd say the promises were broken.
It's possible those devices will offer indirect migration paths (e.g. you have to reinstall the OS). While annoying/inconvenient, that would probably still qualify as keeping the promise in my book.
I know plenty of people who use Apple products such as iPhones and Macs and have to stop using them and throw them into landfill basically because there are no further security updates, although the device works fine and is fast enough for their needs.
Shortening security updates absolutely has an environmental impact.
This. I have an old 2012 Intel Retina Macbook Pro which is already several MacOS versions behind and I’m unable to update it through normal means any longer. It works fine and it still has the best looking screen of any laptop I ever owned.
I keep it at my parents’ house and I maybe use it 3/4 times per year, but it’s enough for my needs when I’m visiting and it feels wasteful to throw it away or store it for good. I fully understand that it is a 14yo machine and it is unreasonable for a company to support old hardware indefinitely, but still, it does feel like a waste.
>it is unreasonable for a company to support old hardware indefinitely
No it absolutely is not, and especially not for a company like Apple. A bunch of hippies make Linux drivers for museum grade hardware. The only reason Apple does this is to sell you new crap that looks and works the same as the old crap.
In the 90's and 00's a 10 year old computer was literally unusable. Today it's different, despite everything that web devs do to ruin it. My home file server is using 2011 hardware (except hdds).
> The more countries trade with each other and depend on each other, the better things are for peace
I previously thought the same, with Europe and Russia doing lots of trade e.g. Germany buying lots of gas from Russia, and many western companies being present in Russia. It seems obviously true.
But Russia still started a war anyway, so I guess it's not actually true.
I think it's true but only in equitable societies.
Putin or Trump are totally isolated from economical and political consequences so they have no problem severing ties. If there are genuine co-dependencies, including for the leaders, they it's much harder to break peace.
I imagine the ideological aspect is the deeper motivation but it only matters with the right circumstances.
Putin and Trump sits in the opposite side of the political spectrum, so as the country they lead, and yet they still managed to archive something similar.
It's not that hard to manage the country to a point where nothing in the country, even law, can hurt it's leader anymore. Sometime a bit of time and patient is all it takes.
You can never rule out irrational acts. Merkel was ignoring the writing on the wall for much too long, it was pretty obvious that russia was on the war path long before she was still happily inking contracts that financed russia's machinery. You can not get a country that is already waging irrational wars to change their way by trading with them. But I'm pretty sure that for instance Trump right now is restrained to some degree by the certain knowledge that the US economy is at the mercy of outsiders.
None of that stopped Trump raising the gas price to $10, or ending the petrodollar, either. It seems to have been empirically demonstrated that economics cannot restrain powerful idiots.
We can only live in one world, but I can easily imagine a much worse alternative where there had been no restrictions at all. The question here is a matter of degree, it isn't an on-off switch.
I mean, we in europe did a a lot of trade with US too, and between other (then and still) EU countries, but the americans (and brits, and a few others) decided to attack Iraq for example ("Iraq has WMDs!"), and there were no sanctions and trade went on. And many other conflicts and bombings all around the world.
So it's not actually caring about the war and dead people (if we did, we'd do something about what israel is doing in gaza), but "us vs them", and russia is "them" while US was traditionally "us", until daddy Trump came along.
Someone probably told the EU politicians that russia will cave after a month or two of sanctions, there will be some kind of a "revolution" there, someone "pro EU" will be set there, and gas would be even cheaper.... A similar scenario was probably given to Trump for iran (just bomb the government, they'll cave, and you can set up a new pro-US leader there again).
One thing I think generics in Go is missing is the concept in Java.
If you're taking a List[T] and all you want to do is to call list.size() then you don't care what type of list it is. In Java you can write a function which takes a List but in Go you have to write List[T] so then the question becomes what is T?
You have to make the function (or type you're a method on) generic. If you make the type generic then every user of your type also needs to specify T, etc.
I don't think it would be impossible to add that to Go. Allow List[?], which matches a List with any type parameter. Calling functions which don't involve the type parameter like list.size() would be fine, calling a method returning the type parameter like list.get(n) would return "any", and methods taking the type parameter like list.set(n, obj) would probably not be callable.
Go Generics work differently than those in Java. They are specialized, meaning that they are not generic at runtime anymore. Instead, the compiler creates a different implementation for each type.
At runtime, there are only List[int], List[string], etc. List[T] is not a thing anymore.
The one thing I hated about Java's generics was type erasure. It worked for the JVM but it had such stupid limits, like not being able to switch on a type, like go. (interfaces are types, this is exploitable)
You need this in Java because interfaces are explicitly implemented. You don't need this in Go because interfaces are structurally implemented. The way you spell "anything that has a method named Size which returns int" is interface{Size() int}.
> What people want generic methods for is to do deeply nested call chains
I don't see that as the only use of generic methods.
The example in the article is a "Map" method that transforms e.g. a List[A] to a List[B], by taking a function that takes an A and returns a B. To be able to transform a list like that is a useful operation.
It was possible to do the same with a global function like MapList but the syntax is nicer if you use methods. You don't need the type in the name (function MapList vs method Map) and it is an operation on the List after all so list.Map(..) is nicer than MapList(list, ..).
People advocate for Go's error handling because it forces you to deal with errors.
But in the cases I do want to catch a specific error, the signature only tells me that a function returns an error, not which type. So I do feel that returning (int, error) is strictly worse than Java's checked exceptions if you care about errors.
This is elegantly solved with sum types. (And arguably needs sub typing.)
If instead of just returning (int, error) the function would return (int, parseError | outOfBoundsError) you would know that the parser function can fail on reading a number at all and on the number being to big/small to fit the type and handle then accordingly.
Saliently, Java in a sense has supported sum types in the throws declaration and the subsequent catch statements forever. Unfortunately it has not landed in other places where you can use types so you cannot use it for returning errors. Scala 3 supports this but has tiny adoption it seems.
It's helped, but that's runtime behaviour. The compiler can't help you with questions like "you didn't handle certain errors" or "the error you're trying to check can never occur".
Nor does that help with documentation, I'm guessing if I read a file then it might raise the error that the file does not exist. But what exactly is the technical type of that error? You have to search through the function's implementation, and functions that function calls, etc., to find out.
And it doesn't help with refactoring. If you create new.FileNotFoundError and change your function to return it, existing code which checks for old.FileNotFoundError will start to silently fail.
I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention.
I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.
Fairly sure it would predate even that, and go all the way to lambda calculus, and predicate logic before that, and that's where my knowledge stops and somebody else can tell us where the current conventions around variables in logic and mathematics come from.
I often use whole word for type annotation, when I can find meaningfull ones. I just type them in all caps to stay close to the convention.
I guess the single letter thing is laziness for a part. It's not simple to find words that represent the abstract idea behind the generic type without narrowing the possibilities. For array function, the Key Value from the sibling comment work but for more complex use case, it get complicated.
I'm not necessarily disagreeing, but I'm following the single-letter convention because "TIn" or "InputType" looks too much like an exported symbol. Whenever I tried to write type arguments like that, this threw me off, so I reverted to single letters.
It's a mix, because some stuff tends to just use `T`, but there's better descriptors elsewhere.
There's IList but Task
There's Action but also Dictionary and Map
This stuff kind of "makes sense" once you're used to it, because it's difficult to say what IList ought to have been called otherwise, IList is a mouthful, and Action simply suffers from the inability to specify an unknown number of generic parameters.
