adrianmsmith

[dupe] https://news.ycombinator.com/item?id=50245524

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

> Because jj's conflict resolution is fundamentally better

I don't know jj well so its merge algorithm may well be better in some aspects but it currently can't merge changes to a file in one branch with that file being renamed in another branch. Git can do that.

https://github.com/jj-vcs/jj/issues/47

> keeping the old one around would be embarrassing

On the other hand this is the company that sells a Mac Pro for $7k and it comes with an M2-based chip...

Macbook Nano will probably be supported with security updates for a lot longer.

Apple try to provide updates for a certain number of years after the model was originally released. The M1 Air was released many years ago now.

> Replacing human hesitation with machine confidence removes the one safeguard that has prevented nuclear war since 1945. Until militaries implement documented human authorisation...we are blindly automating our own destruction

In the scenario described there literally is a human in the loop: the president is a human?

GH literally say in a parent comment:

> we can (and do) take action against those accounts including banning the accounts

> You end up working for shitty Fortune 500 company, work on useless/mindless shit, grind for 8 hrs, collect paycheck, eat, sleep, and repeat.

I used to think like this but what if it isn't the case? Maybe the market is making the right decisions after all? Maybe contributing a tiny amount to a successful business really is worth more to society than contributing a huge amount to a project with barely any customers, and that's why we get paid more working for large companies?

(Not suggesting OP's projects have barely any customers, I am more talking about my own forays into small business.)

This is research from Microsoft that goes into more detail: https://www.microsoft.com/en-us/research/wp-content/uploads/...

> Can anyone recommend a music discovery service that isn't garbage?

I enjoy using last.fm, although it's not their focus these days. Sign up, connect it to Spotify or whatever you use (incl. a long list of players of local music), after a day or so it'll learn what you like and you can create playlists with suggestions and export them, or browser around recommended artists etc.

> As I dug deeper into these feelings, I realized I was feeling pressured. Except they're not saying this, I am.

That's a great insight.

Once you've realized that, I think the best thing to do is to talk to the person whose pressure you imagine. Then you can find out what they're really thinking. Perhaps they really are thinking that (in which case the pressure is real and you can act on it) or they aren't (hearing them say that will alleviate the pressure).

Once when freelancing I asked a customer what they liked and disliked about my work. They had previously seemed happy with me, so I was pretty sure I know what they'd say. I believed I wrote good stable software. What they actually said was they were a small company, and they had had previous developers who, when there were server problems etc., just shrugged and said they didn't know how to fix it. They felt I wasn't like that, that I'd sit there and get it fixed, call up friends if necessary, etc. So yeah, they were happy, but not for the reason I'd imagined.

So my learning was: So you always have to talk to people to find out what they think. You really can't guess.

Thanks. We're doing all that.

But that doesn't help when you do "git rebase" and there's a large conflict which you have to resolve manually, caused by two people changing different lines, and one or both of those lines caused the formatting of the whole block to change. That's the source of my frustration.

Im not sure I understand the readability benefits. Is code like line 286 here, which doesn’t align values in assignments, difficult to read?

https://github.com/gohugoio/hugo/blob/master/commands/comman...

Even if there were readability benefits, I’m not sure they’d be enough to offset the extra effort in reviewing, diffing and merging.

Interesting. Yeah I did think maybe this could be solved by more tooling. But at my place it work it isn’t, at least at the moment. Perhaps I could change that.

Do you have any info on what I could use to make the command-line “git diff” and “git rebase” handle this style of formatting? Ideally so the latter merges and produces code which matches “gofmt” output?

On the other hand I suppose my point is that even if there were such tooling, using style of formatting doesn’t offer enough (any?) benefit to justify the effort of introducing the tooling.