It's hard to avoid, because (naming aside) the cognitive load is caused by higher order functions, which are hard avoid without causing massive code duplication.
I understand the desire to keep things concrete and avoid high level abstractions, but it's a decision not to automate stuff that can easily be automated. It runs counter to the basic instincts and purpose of our field/industry. That's why it never sticks.
Honestly, I’ve written some applications that, on paper, should be the perfect candidate for generics. And yet I can still count on one hand the number of times generics have saved me from massive code duplication.
Most of the time generics might be useful, I’ve ended up needing reflection too anyway. And at that point, I’m really no better off for generics.
The problem is generics only solve a very small part of the equation: compile time checks for composite types. But to use composite types in anything non-trivial in Go, you then need reflection. Which is slow. And if you then need reflection, you’re already passing interface types anyway plus you’re back to having to handle type-handling errors in the runtime.
So if you’re writing a library that’s expected to have any kind of performance, you’re back to code duplication and having a DoSomethingType() function signatures again.
Or you stick with reflection and take that performance hit PLUS the risk of compile time constraints being runtime errors; which is the a lose-lose scenario. And let’s also not forget that reflection can be just as verbose as code duplication, and harder to get right too.
Don’t get me wrong, I’m glad we have generics. But people on HN massively overstate the value of them in a AOT non-dynamic, strictly typed language like Go.
I guess you could argue that Go has other shortcomings that directly result in generics having limited value. But then you’re basically just arguing that you prefer coding in a different language paradigm, and at that point, you’re much better off using that other paradigm instead of complaining that Go isn’t JavaScript or Haskell.
Yes it is precisely Go’s shortcomings that would require typical use of generics to also require reflection most of the time. You would want Rust traits (or Haskell type classes) or C++ style type traits and then the need for reflection is much reduced. So Go has painted itself into a corner where generics feel bolted on and less useful than generics in other languages. It’s still Go’s fault and people rightfully argue that they should prefer a different language.
The Go language itself is never its strength but it has a good runtime, wonderful standard library and tooling. People never picked Go for being an amazing language, but rather for these other things.
I picked Go for the language, so your argument is incorrect.
Go’s shortcoming is also its strength. Language design is a constant battle of tradeoffs. And I happen to find many of the decisions C++ and Rust made weren’t analogous with my preferences.
> It’s still Go’s fault and people rightfully argue that they should prefer a different language.
It’s no more Gos fault than it is the people using Go. It’s called an “opinion” and “preference”. Please don’t assuming your preference is some global truth, because it is not.
Generics are supremely useful for containers. They are kind of one trick ponies in that sense in application code. Similar to reflection, I’d say, which is utilized for serialization 99% of the time.
The thing is that one use case is so essential, so foundational, that we really can’t just skip it. You need generic containers, for ergonomics and performance. I mean, compare C qsort to C++ std::sort.
The languages that “get around” generics, like PHP, include god containers in the runtime. The language I’m designing is also that way, I’d like to avoid generics preferably forever.
But there’s a tradeoff there. God containers are very flexible, and we’ve seen the ramifications of untyped PHP arrays.
I was about to mention Haskell as well, I feel like it also avoids this sort of cognitive load. Maybe it's something to do with the languages being designed as functional languages instead of languages with functional components.
You might see no information, but I see someone having their opinions really moved, in a serious manner. It's not upvoted because it advertises Kimi. It's upvoted because someone tried something different, and genuinely surprised.
I see this as a post from someone who understood the value of "open". Now they're open to understand the value of "free" (as in unencumbered). In the age of AI, we need to understand the value and embrace more open and free, both as in models and software.
> ...personal account. I work at Modal, and today we just launched Kimi K3 on managed endpoints, and I know Kimi K3 is supposed to be pretty solid, so instead of upgrading my Claude plan, I wanted to give it a try. (I didn't directly contribute to this feature, so I haven't gotten to play with it yet.)
When I read the post I read nothing about Kimi-K3. I read about someone who used something open and being surprised about the effects of using something open.
I read about owning the data, knowing the path, being able to control what you have and the lightness it brings. That feeling came through his employer, which is something we can debate all year long, but I see nothing about advertising Kimi-K3 or managed endpoint or whatnot.
Maybe because I'm in all this for a long time, and having an AI capable server near is not something alien to me.
Anyway, in short, there's no AI related content for me in that post. I'm more on the experience side.
>I haven't yet found a way for a mobile app or web page to explicitly signal to the device that the passkey to be created should live in $password_manager and not whatever built-in/on-device key-store exists.
On Android 17 (on Pixel) you can select the password service under Settings -> Passwords and passkeys -> Preferred service.
If you have an alternative password manager installed, it will be listed there along with Google's own password manager. iOS has a similar setting but I don't know exactly where off the top of my head.
"Most" apps? So it works in some apps, but not others?
Setting your preferred password/passkey manager on Android 17 to 1Password works fine in Chrome and Firefox to log in to any site, presenting passkeys managed in 1Password. It also works in all of Meta's native apps. (I'm pretty sure it works the same in Bitwarden.)
Whatever issue you're having, it's not an inherent limitation of Android passkeys. It might be a bug in your passkey manager…?
> Setting your preferred password/passkey manager on Android 17 to 1Password works fine in Chrome and Firefox to log in to any site, presenting passkeys managed in 1Password
I went to `github.com` in chrome (not my default browser) and firefox and tried to sign in with pass key. I never even got a prompt from 1password to unlock to use the pass key, just a "no pass keys available" message from what looks like the system UI.
When I go to passwords & passkeys, 1password is the only item listed under preferred service. Google shows up under additional services but I have the toggle set to off.
so yeah, I just auto-fill my username and password like it's 2018.
> Setting your preferred password/passkey manager on Android 17
Which approximately no one is using yet. Maybe in two weeks, when the new Samsung flagships roll out, to two months, when they start updating current generation devices...
> to 1Password works fine in Chrome and Firefox to log in to any site, presenting passkeys managed in 1Password.
Perhaps. But does it work with System Web UI, which I imagine is Chrome but have no clue how it's accessed?
I would say it's neither a lie nor misinformed. It 's a punchier headline that can be justified by what the user experiences. The user connects a monitor which causes ads to appear. The rest of this Rube Goldberg contraption is a mere detail.
I disagree. It matters that LG makes ads appear on their customers' screens as a deterministic consequence of connecting one of their monitors. It's not superstition.
Of course the details are important on some level. But that doesn't make everything else not matter and it doesn't turn an incomplete explanation into a lie.
That's my point: it's not a consequence of connecting a monitor. An external element is making it look like such.
This difference tells you that, for example, you cannot fix the problem by fixing the monitor, because the problem does not exist in hardware. It's actually entirely external to the hardware you own, because it exists entirely "in the cloud" (i.e. on MS and LG servers).
No you're wrong. It absolutely is a consequence of connecting an LG monitor. Connecting an LG monitor triggers a chain of events that deterministically and deliberately cause these ads to be shown.
The hardware alone is not sufficient for this to happen, but if you were to modify or "fix" the monitor (specifically its firmware) so that it no longer identifies as an LG monitor, then it would no longer cause these ads to be shown.
In other words, if A causes B and B causes C then it is correct to say that A causes C.
Android the technology wasn't, but Android the commercial product along with its business model was.
The first iPhone came out in June 2007. In November of that year Google and partners announced the Open Handset Alliance and the open sourcing of Android.
Also, parliament has a rule against wearing costumes like this. But Count Binface called that rule "binist" and claimed there was some wiggle room in the way the rule was worded :)
I think leaving the seat empty if he wins is the only possible choice, both legally and democratically. He should make it clear that this is what would happen if he gets elected so the people of Clacton know what they are voting for.
I think Erskine May just says "Members should dress in business-like attire" - so maybe if he had a special 'business bin' as opposed to a 'smart-casual bin' he could argue the point.
He would though have to remove the bin for votes at the least
I'd say standards have dropped so low, we may as well let in fancy dress. Lots of people in cheap thin dresses with no jacket [0] (some show knee when sat, even half an upper leg! [1]), boat shoes, white suits etc. They look like a collection of wedding guests.
Let's not get started on the sexism against men with Hoyle wanting them to wear ties and a jacket but for women just 'business-like' is expected.
reply