451–460 of 481 posts
Earlier quoted context omitted.
Go could do something similar if you're willing to run `go generate` as part of your build process. For most Go applications, the reflection overhead is a fine price to pay for convenience, just like GC is a fine price to pay for not having to deal with the borrow checker. Obviously, these tradeoffs don't hold for all programs, but Go has definitely found a niche.
I'm not sure what you're arguing with. I know these things. I'm still missing the ability to have efficient serialization (as one example) easily. It matters.
Earlier quoted context omitted.
> we have an issue. No, we don’t.
It's hard to say much when your replies are so short, but let me try to elaborate. If a user that was happily using version 727 is now on a version that's almost identical to 402, they're now missing 300 versions' worth of code changes. You don't see how that's an issue? What if they were using functionality from that? Upgrading to 728 has removed all this code they were depending on! If everyone follows your advice…
Earlier quoted context omitted.
> we have an issue. No, we don’t.
It's hard to say much when your replies are so short, but let me try to elaborate. If a user that was happily using version 727 is now on a version that's almost identical to 402, they're now missing 300 versions' worth of code changes. You don't see how that's an issue? What if they were using functionality from that? Upgrading to 728 has removed all this code they were depending on! If everyone follows your advice…
lol. That’s not how this works.
[1] Cornelius Diekmann, “Looping with Untyped Lambda Calculus in Python and Go,” Paged Out!, vol. 2, p. 22, Nov. 2019. https://pagedout.institute/ https://www.net.in.tum.de/fileadmin/bibtex/publications/pape...
Earlier quoted context omitted.
It's hard to say much when your replies are so short, but let me try to elaborate. If a user that was happily using version 727 is now on a version that's almost identical to 402, they're now missing 300 versions' worth of code changes. You don't see how that's an issue? What if they were using functionality from that? Upgrading to 728 has removed all this code they were depending on! If everyone follows your advice…
>If a user that was happily using version 727 is now on a version that's almost identical to 402 lol. That’s not how this works.
If I give my bugfix to 402 a version number, it will be 728.
So if that's not what happens, what does?
Do I give it no version number?
Am I not allowed to release a bugfix?
Surely you can see why both of those options cause unnecessary problems.
If you have something else in mind, you need to say it.
Earlier quoted context omitted.
>If a user that was happily using version 727 is now on a version that's almost identical to 402 lol. That’s not how this works.
> lol. That’s not how this works. If I give my bugfix to 402 a version number, it will be 728. So if that's not what happens, what does? Do I give it no version number? Am I not allowed to release a bugfix? Surely you can see why both of those options cause unnecessary problems. If you have something else in mind, you need to say it.
Earlier quoted context omitted.
Congratulation on getting within inches of the point yet still completely whiffing. But i guess that’s the blub paradox for you.
lol the arrogance. Hilarious. there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language. If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive here, have fun. You’re gonna write some tests, make new types to satisfy interfaces fo…
Yes, the hilarious arrogance of… taking in account useful things that work?
> there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language.
Literally the exact same statement could be made about generics.
> If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong.
Wonderfully missing the point again.
> You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess.
Oh boy, ain’t that one for Principal.
> You know everything!
You’re the person declaring sum types useless in the face of decades of evidence and completely incapable of handling the idea of disagreement.
> I am but a simple blubbite, too dim, too dim to get it.
I see you don’t understand the blub paradox either.
Earlier quoted context omitted.
> lol. That’s not how this works. If I give my bugfix to 402 a version number, it will be 728. So if that's not what happens, what does? Do I give it no version number? Am I not allowed to release a bugfix? Surely you can see why both of those options cause unnecessary problems. If you have something else in mind, you need to say it.
Never backport fixes. Time only goes forward.
And it's not really a version numbering system that you're advocating for at that point, it's a strict rule about linear releases.
Earlier quoted context omitted.
I’ve used all those languages. It’s far easier to make sense of a non trivial go code base I’ve never seen before than any of those.
It's far easier for you . It definitely isn't for me or in general . Thank you for answering the list of languages though. Makes me wonder what the concrete points are for, since I really have a different opinion. Maybe our minds just work very different; :)
choices.forEach(async (ce) => {
let ce = choices[index]
Deno.sleepSync(220);
let cf = await getChoice(ce); // this makes the API call
Deno.sleepSync(220);
});
for (index = 0; index