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.

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

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

Comments URL: https://news.ycombinator.com/item?id=48233764

Points: 8

# Comments: 11

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

Comments URL: https://news.ycombinator.com/item?id=48021368

Points: 484

# Comments: 807

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

Comments URL: https://news.ycombinator.com/item?id=47375051

Points: 24

# Comments: 2

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

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.

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

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

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

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.