"No other budget laptop can compete on offering MacOS" is certainly a correct statement, but it's not a particularly interesting one. If they're missing the point, it's because it was exaggerated to the point of not being recognizable.
It's hard to that this objection seriously. The publication is literally called the Financial Times. It's not exactly crazy for them to think that their readers might care about the entity that shows up the stock ticker rather than how the company happens to divide up things internally.
Even if it weren't a finance publication, I have trouble imagining you making this argument if a headline said something like "Google deals with outages in the cloud" because of the idea that it's misleading to refer to it as anything other than GCP. I think you're fundamentally not understanding how people communicate about this sort of thing if you actually think that someone saying "Amazon" is misleading in any meaningful way.
They literally ended the comment by asking. I don't get why you're criticizing them for providing context that they're not an expert. You're literally distracting from the comment you're telling them has useful information on it, but in a weirdly aggressive way.
If I'm reading their chart right, they have barely half as much memory for their RISC-V machine compared to any of the others? I don't know enough to know whether it's actually bottlenecked by memory, but it's a bit odd to claim it's slower, give those numbers, and not say anything about it. I'd hope they ruled that out as the source of the discrepancy, but it's hard to tell without confirmation.
The number of people who will recognize that will only go down over time. I'm not exactly ancient (at least outside tech) at 32 but have no recollection of ever seeing that icon or confidence that I'd recognize it, which I'd argue puts a rough lower bound on how old someone can be while considering it "well-known". Maybe if people only a few years older than me consistently recognize it then my instinct here is wrong, but I'm skeptical that there are enough people who consider this well-known for the supposed renaissance to take place purely from that.
(It's possible I'm entirely missing that this was intended in sarcasm, but it at least seems like it's was intended seriously to me)
I don't know about that. For me, f-strings were the last great quality-of-life improvement that I wouldn't want to live without, and those landed in Python 3.6. Everything after that has not really made much of a difference to me.
This reads like you think that "major" version bumps should ony happen when things make a big difference to you personally. At least that's where you land when you follow the logic of your statement. I think you may overrate the importance of your particular use case, and misunderstand what GP meant by "major".
The gist of what GP meant is that Python does not exactly follow SemVer in their numbering scheme, and they treat the middle number more like what would warrant a major (left-most) number increase in SemVer. For example, things will get deprecated and dropped from the standard library, which is a backwards-incompatible change. Middle number changes is also when new features are released, and they get their own "what's new" pages. So on the whole, these middle-number changes feel like "major" releases.
That being said, the Python docs themselves [0] call the left-most number the "major" one, so GP is not technically correct, while I'd say they're right for practical, but easier to misunderstand, purposes.
> A is the major version number – it is only incremented for really major changes in the language.
> B is the minor version number – it is incremented for less earth-shattering changes.
> C is the micro version number – it is incremented for each bugfix release.
> That being said, the Python docs themselves [0] call the left-most number the "major" one, so GP is not technically correct, while I'd say they're right for practical, but easier to misunderstand, purposes.
That's ultimately the point I was trying to make; my inner pedant can't help but feel the need to push back on people using versioning terminology inconsistently, but in practice I don't think it really made much of a difference in this case.
Oh, you are right, I forgot that "major version" is a technical term and incorrectly read it as "For Python, 0.1 increases make a big difference". My bad!
If you want your code to run, you need a python interpreter that supports the newest of your dependencies. You may not use features that came after 3.6 (though you obviously do), but even if just one dependency or sub-depdendency used a python 3.10 specific feature you now need interpreter at least this new.
That is true, and it is also a huge pet peeve of mine. If more library maintainers showed some restraint it using the newest and hottest features, we'd have much less update churn. But on the other hand, this is what keeps half of us employed, so maybe we should keep at it after all.
They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case.
Or at runtime, you can import things from the standard library which require a minimum 3.x. - .x releases frequently if not always add things, or even change an existing API.
> They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case.
Are you saying that you'd get an error using the new feature on an old version, or that code that used to parse on old versions would not longer work on the newer version? The former is pretty much a textbook example of a minor version update in "traditional" semver; a single new API function is enough to potentially make new code not work on old versions, since any calls to that function will not work on versions predating it. The latter is what would constitute a "breaking change" in semver; old code that used to work can't be made to no longer work without a major version bump.
I say "traditional" semver because in practice it seems like there are fairly few cases in which people actually seem to fully agree on what semver means. I've always found the "official" definition[1] to be extremely clear, but from what I can tell most people don't really adhere to it and have their own personal ideas about what it means. I've proposed things in projects that are fully within both the letter and spirit of semver quite a few times over the years only for people to object on the basis that it "isn't semver" because they hadn't fully read through the description before. Typically I'll mention that what I'm suggesting is something that semver allows and bring up the page and show them the clause that specifically allows what I'm saying but clarify that I recognize we still might not want to do it for other reasons, and the other person will end up preferring to stick with their initial instinct independent of what semver actually says. This is totally fine, as semver is just one of many versioning scheme and not some universal optimum, but my point is that it's probably more confusing for people to use the same term to describe fairly inconsistent things.
True - I don't think I really had my head screwed on there. It just 'feels different' because it's language level, the actual syntax, I suppose, but no - you're right.
> if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.
In practice though, there's not nearly as many cases where someone needs to repeat `if x > y { return x }` a bunch of times in the same function. Whether the issue is "about errors" specifically doesn't really change the relatively common view that it's an annoying pattern. It's not surprising that some people might be more interested in fixing the practical annoyance that they deal with every day even if it's not a solution to the general problem that no one has made progress on for over a decade.
> there's not nearly as many cases where someone needs to repeat `if x > y { return x }` a bunch of times
In my evaluating of a fairly large codebase, if err != nil makes up a small percentage of all if statements. I think you may have a point that branching isn't great, but I'm still not sure trying to focus that into errors isn't missing the forest for the trees.
> it's an annoying pattern.
But, again, if it is so annoying, why is it the pattern you are settling on? There are all kinds of options here, including exception handlers, which Go also supports and even uses for error handling in the standard library (e.g. encoding/json). If your design is bad, make it better.
> It's not surprising that some people might be more interested in fixing
If they were interested in fixing it, they'd have done so already. The Go team does listen and has made it clear they are looking for solutions. Perhaps you mean some people dream about someone else doing it for them? But, again, who is that person going to be?
Philip Wadler, the guy who they eventually found to come up with a viable generics approach, also literally invented monads. If there was ever someone who might have a chance of finding a solution in this case I dare say it is also him, but it is apparent that not even he is willing/able.
> In my evaluating of a fairly large codebase, if err != nil makes up a small percentage of all if statements. I think you may have a point that branching isn't great, but I'm still not sure trying to focus that into errors isn't missing the forest for the trees.
I don't agree with the premise that a frustrating pattern has to comprise a large percentage of the instances of the general syntax for people to want to change it. I can tell you do, but I don't think this is something that people will universally agree with, and I'd argue that telling people "you can't have the opinion you have because it doesn't make sense to me" isn't a very effective or useful statement.
> But, again, if it is so annoying, why is it the pattern you are settling on? There are all kinds of options here, including exception handlers, which Go also supports and even uses for error handling in the standard library (e.g. encoding/json). If your design is bad, make it better.
Empirically, people don't seem to think they have better options, or else they'd be using them. If you try to solve someone's problem by giving them a different tool, and they still say they have the problem even with that, you're probably not going to convince them by telling them "you're doing it bad".
> If they were interested in fixing it, they'd have done so already. The Go team does listen and has made it clear they are looking for solutions. Perhaps you mean some people dream about someone else doing it for them? But, again, who is that person going to be?
> Philip Wadler, the guy who they eventually found to come up with a viable generics approach, also literally invented monads. If there was ever someone who might have a chance of finding a solution in this case I dare say it is also him, but it is apparent that not even he is willing/able.
I'd argue there have been plenty of solutions for the specific problem that's being discussed here proposed that are rejected for not being general solutions to the problem that you're describing. My point is that there's a decent number of people who aren't satisfied with this, and would prefer that this is something solved in the specific case rather than the general for the exact reason you pointed out: it doesn't seem like anyone is willing or able to solve it in the general case.
My point is that I think a lot of people want a solution to a specific problem, and you don't want that problem solved unless it solves the general problem that the problem is a specific case of. There's nothing wrong with that, but your objections are mostly phrased as claiming that they don't actually have the problem they have, and I think that's kind of odd. It's totally fair to hold the opinion that solving the specific problem would not be a good idea, but telling people that they don't care about what they care about is just needlessly provocative.
I like nice things. You've identified a clear pain point that I agree with. If something can be better, why not make it better? "I am not able to think beyond the end of my nose, therefore we have to stop there" is a silly response.
> Empirically, people don't seem to think they have better options, or else they'd be using them.
I have read many Go codebases that do a great job with errors, without all the frustration you speak of. I've also read codebases where the authors crated great messes and I know exactly what you're talking about. That isn't saying Go couldn't improve in any way, but it does say that design matters. If your design sucks, fix it. Don't design your code as if you are writing in some other language.
> My point is that there's a decent number of people who aren't satisfied with this
Including the Go team. Hence why Ian Lance Taylor (who isn't on the core team anymore, granted, but was at the time) went as far as to create a build of Go that exhibited the change he wanted to see. But, once it was tried, we learned it wasn't right.
Nobody has been able to find a design that actually works yet. Which is the same problem we had with generics. Everyone and their brother had half-assed proposals, but all of them fell down to actual use. So, again, who is going to be the person who is able to think about the bigger picture and get it right?
Philip Wadler may be that person. There is unlikely anyone else in the world with a more relevant background. But, if he has no interest in doing it, you can't exactly force him — can you? It is clearly not you, else you'd have done it already. It isn't me either. I am much too stupid for that kind of thing.
> I am not able to think beyond the end of my nose, therefore we have to stop there" is a silly response.
This is exactly what I mean by needlessly provocative. You're almost directly saying that people who happen to care more about one specific case than you do are stupid or naive rather than having a different technical opinion than you. If you genuinely think that people who disagree with you are stupid or naive, then I don't understand why you'd bother trying to engage with them. If you think they aren't, but their ideas are, I don't think you're going to be effective at trying to educate them by talking down to them like this.
> Nobody has been able to find a design that actually works yet. Which is the same problem we had with generics. Everyone and their brother had half-assed proposals, but all of them fell down to actual use. So, again, who is going to be the person who is able to think about the bigger picture and get it right?
Whether a design "actually works" is dependent on what the actual thing it's trying to solve is, since a design that works for one problem might not solve another. This is still circular; you're defining the problem to be larger than what the proposals were trying to solve, so of course they didn't solve what you're looking for. You're obviously happier with nothing changing if it doesn't solve the general problem, which is a perfectly valid opinion, but you're talking in absolute terms as if anyone who disagrees with you is objectively wrong rather than having a subjectively different view on what the right tradeoff is.
> Philip Wadler may be that person. There is unlikely anyone else in the world with a more relevant background. But, if he has no interest in doing it, you can't exactly force him — can you? It is clearly not you, else you'd have done it already. It isn't me either. I am much too stupid for that kind of thing.
Once again, this is exactly the reason that I'd argue that it's reasonable to consider a solution to a specific subset of the problem than trying to solve it generally. If nobody is capable of solving a large problem, some people will want to solve a small one instead. The issue isn't that I can't personally see beyond the end of my nose, but that unless someone comes up with the solution, it's impossible to tell the difference between whether it's a few hundred yards outside my field of view or light-years away in another galaxy we'll never reach. I'd argue that there should be some threshold where after enough time, it's worth it to stop holding out for a perfect solution and accept one that only solves an immediate obvious problem, and further that we've reached that threshold. You can disagree with that, but condescending to people who don't have the same view as you isn't going to convince anyone, so I don't understand what the point of it is other than if you're just trying to feel smugly superior.
> This is exactly what I mean by needlessly provocative.
This doesn't make sense. You might be mistakenly anthropomorphizing HN?
> so of course they didn't solve what you're looking for.
What I am looking for is irrelevant. They straight up didn't solve the needs of Go. It was not me who rejected them, it was the Go community who rejected them, realizing that they won't work for anyone.
> Once again, this is exactly the reason that I'd argue that it's reasonable to consider a solution to a specific subset of the problem than trying to solve it generally.
The Go project is looking for a subset solution. Nobody knows, even within that subset, of how to make it work.
Which clearly includes you. Me too. Obviously if we had a solution, we'd already be using it. But who?
No matter how much you hope and pray, things cannot magically appear. Someone has to do it.
> This doesn't make sense. You might be mistakenly anthropomorphizing HN?
You're a human talking to other humans. Yes, you're online, but there are still a range of ways you can phrase things, some of which are more polite than others. I don't understand what doesn't make sense about it, although as always you're free to disagree.
> What I am looking for is irrelevant. They straight up didn't solve the needs of Go. It was not me who rejected them, it was the Go community who rejected them, realizing that they won't work for anyone.
Go is not a monolithic community, and for obvious reasons the people making decisions are a much smaller group than the community as a whole. Not everyone in the community will agree with every decision, and my impression is that there's a sizable group of people who would have been happier if one of the proposals had been merged. You're stating it as fact that this isn't the case, and obviously I'm not going to convince you otherwise, but it's clear you don't have any desire to provide any more context because you think your claim is self-evident.
> Which clearly includes you. Me too. Obviously if we had a solution, we'd already be using it. But who?
Sure, if you think that the people who make the language are infallibly able to both know and care about what's good for 100% of Go programmers and every proposal will somehow be either something that will strictly fit what with every single one of them wants or be bad for all of them (regardless of what they say they want). Alternately, maybe there's nuance where different people have competing technical views on what would make sense or disagreeing views on subjective matters, and the lack of a solution having been adopted doesn't mean that it's impossible for someone to think that anything that's been discussed would be a good idea without being objectively wrong. Given that you'd rather refer to any other viewpoint as akin to magical hopes and prayers, you obviously don't think that it's possible anyone else could have something reasonable to say on the issue if it disagrees with your opinions, so I guess we've both been wasting our time here.
Okay. Let's put that to the test. Describe my human features. What do I look like, sound like?
> and my impression is that there's a sizable group of people who would have been happier if one of the proposals had been merged.
Fair enough. What do they say to the specific criticism that brought rejection?
> Sure, if you think that the people who make the language are infallibly able to both know and care about what's good for 100% of Go programmers
They satisfy 100% of Go programmers, but not all programmers. Those who aren't satisfied are already using another language or have forked Go to make it what they actually need. Even Google uses their own fork, funnily enough. If something doesn't work for you, you can't sensibly continue to use it.
> One that's most silly to me, the tires have huge branding but the actual useful info, what pressure they need, is nearly impossible to read without perfect lighting and then me taking a photo and zooming in.
Sadly, the writing isn't there for (only) you. Anywhere you go and park your car now has a billboard for the tire company. Far more eyeballs that interest the ones putting the writing on it will be looking at it for reasons other than looking for the pressure than ones who are actually trying to get anything done with them.
reply