adrianmsmith

Why?

I read the attached links and it just looks like a marketing agency?

I would agree but Google's wording is

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

Exactly.

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.

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

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.

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.

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

No

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.

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.

The article gives examples of situations where projects have failed, and states a solution.

> The [solution] is to organize the work into the smallest possible learnable chunks and continuously alternate between doing and learning.

It would be more convincing if the article gave examples of where that solution had been tried and succeeded. I mean this must have been tried somewhere, surely.

I feel this article is saying people from UK/US/etc. want to maximize upside, and people from DACH (Germany etc.) want to minimize downside.

I was a bit shocked when I talked to an Austrian colleague once and they told me they wanted to get into investing, but losing any money at any time was completely unacceptable. They had looked at investing in S&P 500 ETFs etc., but felt they must have misunderstood something, as they didn't understand why anyone would invest in anything that might go down, even temporarily.

So the thesis of the article definitely feels plausible to me.

> But if you have side effects and need something to happen exactly once it seems a lot more useful to communicate this, rather than pretending you did the thing.

I think it depends on whether the sender needs to know whether the thing was done during the request, or just needs to know that the thing was done at all. If the API is to make a purchase then maybe all the caller really needs to know is "the purchase has been done", no matter whether it was done this time or a previous time.

And in terms of a caller implementing retry logic, it's easier for the caller to just retry and accept the success response the second time (no matter if it was done the second time, or actually done the first time but the response got lost triggering the retry).