HNHacker News
TopNewBestAskShowJobs

0x62c1b43e

42 karma · joined January 27, 2018

submissionscomments
0x62c1b43e··on Can everyone shut the f*** up about AI
What’s even worse is crypto meaning cryptocurrency instead of cryptography now. Now I can’t talk about “crypto” without sounding like I’m going to fill up someone’s spam folder.
0x62c1b43e··on The weight of responsibility: Biomass of livestock dwarfs that of wild mammals
I saw metrics like this a while ago but it’s still hard to wrap my head around. We rarely see this enormous portion of the animals that outnumber us so much.

I grew up on a farm in the rural western US, and our few cattle lived in nice little fields like you’d imagine, but I’d occasionally go by intensive farms and you can see how they pack so many animals into such a small space that they spend their whole lives in. It’s so near but so far from all of us. And the reactions from people I know varies widely to this information or these sights.

0x62c1b43e··on CoffeeScript for TypeScript
If I were going to do this, I’d probably go all the way to using ReScript, but it’s a nice idea.

I’m quite surprised it’s not called ToffeeScript though.

0x62c1b43e··on CoffeeScript for TypeScript
The compilation speed of ReScript is also great
0x62c1b43e··on I use C when I believe in memory safety
C on its own does feel like a simpler language though I think it’s true that the semantics taken literally undermine it (the generated assembly can be really surprising sometimes). I do trust a given Rust program to have a specific runtime behavior much more when optimized. It might be interesting to come up with a variant of C that has genuinely simpler semantics as well (not sure how useful I’d find it though)
0x62c1b43e··on Go 1.20 released
> The container/heap is more useful, but it could benefit more from adding an optimization for inlining interface method calls when Go compiler knows the underlying implementation behind the interface.

This is exactly what generics do. With e.g. a heap.Heap[uint32] the compiler knows the implementation and there’s no interface method call overhead.

In order for the compiler to do this optimization, it has to know that you don’t e.g. pass a *heap.Heap[uint32] to a function expecting *heap.Heap[uint64], so the type system is what allows it to optimize.

And on top of that, now the user also gets assurance at compile time that heap.Heap[uint32].Pop returns a uint32, preventing bugs from type confusion and also so you don’t have to add type assertions everywhere you use the heap.

So now heap, sort, etc. can benefit from this improved performance; users don’t have to write wrapper types and interface implementations just so their type can be sorted; and bugs are prevented at compile time.

For [1] I posted a reply. It’s true that there are overheads with some slice-returning routines but I explained how in the reply how I viewed the tradeoffs.

0x62c1b43e··on Go 1.20 released
It’s not the only one. Some other packages that used workarounds like interface{} or other things to work around the lack of generics were container/{heap,list,ring}, sort, golang.org/x/sync/singleflight, /x/exp/{maps,slices}, etc. And people will want to write their own patterns at other times of course too. It wouldn’t be reasonable for these all to become builtin types like map. These standard library packages that already exist will also become more efficient and potentially reduce allocations (when using primitives) as well.
0x62c1b43e··on Go 1.20 released
Those are good points about some of them being nontrivial.

Though part of why they’re optimized and in the stdlib in the first place is because they’re such common patterns. So without them people would end up writing trivial, unperformant, custom versions. So now that more routines can be moved into the stdlib, they can benefit from optimization later.

(I’m not sure how much the maps routines specifically can be optimized, but stdlib routines routines can generally be more aggressive with unsafe or asm or being coupled to the runtime and its quirks, like bytes.Clone, strings.Builder, etc.)

And there are still plenty of ubiquitous patterns that have been worth including in the stdlib even if they’re usually just simple loops that aren’t very optimizable. Like strings.Index is an easy loop to write, but it comes up so often. Or strings.Cut is basically just an if-statement. But it makes code clearer about its intentions; and optimizations to these down the road benefit everyone.

It’s also true that maps.Keys and maps.Values allocate slices, and that you could avoid this with a loop, but strings.Split, bytes.Split, regexp.FindAll, os.ReadDir return slices and are still worthwhile as opposed to specialized iterators for each one. As with any code, you’re conscious of memory allocations where it counts, and optimize as needed.

In fact, now that generics make it possible, the Go team has discussed using iterators (https://github.com/golang/go/discussions/54245), which would benefit strings.Split even further in addition to all the other slice-returning functions.

So generally you have three options for those slice-returning functions:

- Custom inline loop for some of them. More verbose, will probably be naive and not benefit from stdlib optimizations. - Return a slice and iterate over it with a for loop. Creates allocations that could probably be avoided. - Create a customized iterator for that type. Unfortunately, you can’t really use an ordinary for loop, and extra custom iterators for each type. - Use generic iterators to benefit from the optimized functions and also avoid allocation overhead.

So part of the motivation is that now with generics there’s a variety of further optimizations available even to old functions like strings.Split and regexp.FindAll, in addition to opening up common patterns and optimizations for maps/slices/etc. to be included in the stdlib.

0x62c1b43e··on Go 1.20 released
By that logic we should remove bytes.Clone, strings.Split, bytes.Equal, strings.TrimLeftFunc, etc. from the standard library.
0x62c1b43e··on Go 1.20 released
*lately

It pops up on /r/golang sometimes. I don’t think it gets taken super seriously but there’s usually at least someone bringing it up.

0x62c1b43e··on Go 1.20 released
Yeah, and I don’t tend to keep this around quantitatively, but I’ve certainly run into bugs in Go programs that would’ve been categorically prevented with generics.

Of course I want sync.Map to use generics instead of interface{}. How could I not? And it’s less complex-looking than type-asserting everywhere.

0x62c1b43e··on Go 1.20 released
Generics consistently showed up as one of the most desired features (if not the most desired) by working Go developers in the previous developer surveys, so I think it makes sense that the Go team felt the ecosystem saw much value in it relative to other features and worth the time.
0x62c1b43e··on Go 1.20 released
It’s hard to be objective because of filter bubbles, but I’ve seen it a lot on Reddit last.
0x62c1b43e··on Go 1.20 released
I understand, but it shows that compiler performance is the same as before generics now, so any performance hit is gone.
0x62c1b43e··on Go 1.20 released
I’m gonna be that guy, but do you have sources for any of this? That link shows that compiler performance is the same as before generics, for instance.

Are there more bugs in the compiler? Is readability reduced, and having an effect on pace? Especially if adoption is so low to begin with? Is adoption actually so low, or just rising?

0x62c1b43e··on Go 1.20 released
But if adoption is “very low”, then it’s not much pollution, is it?
0x62c1b43e··on Learn TLA+ (2018)
A lot of people use PlusCal, which is basically pseudocode that compiles to TLA+. Depending on what you're modeling, PlusCal or directly writing TLA+ might be a better fit.
0x62c1b43e··on Strangler pattern, a powerful simple concept to do refactoring
Reminds me of https://programmingisterrible.com/post/139222674273/write-co...
0x62c1b43e··on Association between physical exercise and mental health: a cross-sectional study
They have a section discussing why this paper might seem to contradict other studies showing a causal link:

> This outcome seems at odds with findings from randomized controlled trials in clinical and population samples indicating that regular exercise can relieve symptoms in subclinical individuals and in patients diagnosed as having an anxiety or depressive disorder. To understand the different outcomes of both types of study, it is crucial to make a distinction between the effects of prescribed and externally monitored exercise in selected subgroups and the effects of voluntary leisure-time exercise at the population level. Only voluntary leisure-time exercise is influenced by genetic factors, whereas the other type of exercise is environment driven. The absence of causal effects of voluntary exercise on symptoms of anxiety and depression does not imply that manipulation of exercise cannot be used to change such symptoms. It means that a population association, cross-sectional or longitudinal, cannot be used to justify exercise as a treatment without an actual randomized controlled trial. The possible difference in the antidepressant effects of prescribed vs voluntary exercise is consistent with findings from a recent study suggesting that the therapeutic effects of exercise are nonspecific to exercise. The antidepressant effects of exercise may only occur if the exercise is monitored and part of a therapeutic program.

So it sounds like among twins, if one twin naturally exercises more by their own volition, that twin doesn't in general show less depression/anxiety than the other twin, which is evidence against exercise causally reducing depression/anxiety. However it sounds like it may still be that prescribed exercise as an intervention, beyond what an individual would naturally choose to do, and maybe only in conjunction with therapy, could still benefit an individual (and perhaps then only individuals with clinical symptoms).

This study also does help by showing how the associative inverse relationship between exercise and depression in the general population seems to be from genetics influencing exercise, and not the other way around, and the important of a randomized control trial on exercise as an intervention.

0x62c1b43e··on The terrible 'what if': how OCD makes every day a matter of life or death
https://examine.com/supplements/ashwagandha/?PageSpeed=noscr...

If you haven't encountered it, examine.com is a good resource; they curate research on supplements.

In the Human Effect Matrix, in the Anxiety entry, you can see a link to 3 double-blind, placebo controlled studies examining the effects of ashwagandha on anxiety: https://examine.com/rubric/effects/view/a42299063269c89b14ce...

As far as sourcing, you could look at consumerlab (paid subscription; they do independent testing of supplements).

0x62c1b43e··on Terraforming 1Password
Could you share what preprocessors/templating languages you've used with CloudFormation?