Hacker News: Replies to jerfhttps://news.ycombinator.com/threads?id=jerfHacker News RSShttps://hnrss.org/hnrss v2.1.1Thu, 28 Mar 2024 13:23:15 +0000<![CDATA[New comment by Quekid5 in "`async: false` is the worst"]]>I think a slightly more succinct way of thinking about mutability in actor systems is this: (I think it's from Erik Meijer, but not quite sure.)

Ultimately, any actor system has global mutable state via message queues. You can perfectly emulate a shared mutable variable by just sending it back and forth between message queues. (At least it's only atomically modifiable, I suppose.)

It's very different from abient authority to modify a mutable variable, but still...

]]>
Wed, 27 Mar 2024 21:30:59 +0000https://news.ycombinator.com/item?id=39844822Quekid5https://news.ycombinator.com/item?id=39844822https://news.ycombinator.com/item?id=39844822
<![CDATA[New comment by theptip in "Tech Debt: My Rust Library Is Now a CDO"]]>I wonder if there are tools that library maintainers can use to calculate transitive code coverage of their libraries, eg which other lib test suites use them?

Could be an interesting test strategy, in some sense it’s directed fuzz testing. (With other libraries providing the random-ish invocations.)

]]>
Tue, 26 Mar 2024 17:14:25 +0000https://news.ycombinator.com/item?id=39830333theptiphttps://news.ycombinator.com/item?id=39830333https://news.ycombinator.com/item?id=39830333
<![CDATA[New comment by cmrdporcupine in "Tech Debt: My Rust Library Is Now a CDO"]]>Worth pointing out that all third party deps at Google have to be vendored. By policy. And generally only one version of said dep is permitted for the entire massive monorepo. (This may have changed since I was there.) And each third_party dep has a set of designated responsible individuals / OWNERS.

This has the effect of keeping things relatively sane.

But this enforced discipline can work well at an org like Google that has plenty of time and $$ and isn't dedicated to a "move fast and break things" philosophy. Not sure how well it would work for a startup.

]]>
Tue, 26 Mar 2024 14:48:29 +0000https://news.ycombinator.com/item?id=39828620cmrdporcupinehttps://news.ycombinator.com/item?id=39828620https://news.ycombinator.com/item?id=39828620
<![CDATA[New comment by leoedin in "Tech Debt: My Rust Library Is Now a CDO"]]>This is actually a great outcome. All dependencies are a security risk - the argument for not vendoring every dependency is that you should keep external dependencies up to date to avoid known security issues. If the external dependency has nobody watching it any more then that argument disappears, and that external dependency becomes a liability.

The fact the dependency was marked as abandoned and started getting flagged in security reports is what you want. That lets you make an informed decision about whether to vendor it (which removes the "bad actor sneaks something in" risk) or do something else. It's great that the Rust build system allows that so easily.

]]>
Tue, 26 Mar 2024 14:15:39 +0000https://news.ycombinator.com/item?id=39828104leoedinhttps://news.ycombinator.com/item?id=39828104https://news.ycombinator.com/item?id=39828104
<![CDATA[New comment by ngrilly in "Why choose async/await over threads?"]]>> It is important that [...] we have a high-power very systems-oriented programming language that will make that choice, because someone needs to.

This is exactly why I'm looking into Zig more.

]]>
Tue, 26 Mar 2024 12:23:30 +0000https://news.ycombinator.com/item?id=39826965ngrillyhttps://news.ycombinator.com/item?id=39826965https://news.ycombinator.com/item?id=39826965
<![CDATA[New comment by mike_hearn in "Why choose async/await over threads?"]]>In any system that uses mmap or swap it's a meaningless distinction anyway (which is obviously nearly all of them outside of embedded RTOS). Accessing even something like the stack can trigger implicit/automatic IO of arbitrary complexity, so the concept of a function that doesn't do IO is meaningless to begin with. Async/await isn't justified by any kind of interesting type theory, it exists to work around limitations in runtimes and language designs.

]]>
Tue, 26 Mar 2024 09:21:50 +0000https://news.ycombinator.com/item?id=39825730mike_hearnhttps://news.ycombinator.com/item?id=39825730https://news.ycombinator.com/item?id=39825730
<![CDATA[New comment by freedomben in "Show HN: Detecting adblock, without JavaScript, by abusing HTTP 103 responses"]]>Interesting, I guess this explains why I can never "solve" the damn things on my desktop. I use an Ultimate Hacking Keyboard which has a mouse layer, so I control the mouse cursor with my keyboard. It means that my mouse always travels in either perfectly horizontal, perfectly vertical, or perfectly diagonal patterns, and at very different timings than a human using a traditional mouse would.

But, it pisses me off to no end that I can't use my fucking keyboard the way it is supposed to be used (which is a far superior design to the "normal" setup) to view some websites because it doesn't "look" human to the fucking server who expects me not to be a statistical outlier. As someone who has always been an outlier, I kind of hate the algorithmic future we live in and are headed even further toward. This is why we can't have nice things.

]]>
Mon, 25 Mar 2024 22:43:53 +0000https://news.ycombinator.com/item?id=39822074freedombenhttps://news.ycombinator.com/item?id=39822074https://news.ycombinator.com/item?id=39822074
<![CDATA[New comment by xk_id in "Show HN: Detecting adblock, without JavaScript, by abusing HTTP 103 responses"]]>a tutorial on how to be human on internet

]]>
Mon, 25 Mar 2024 21:14:50 +0000https://news.ycombinator.com/item?id=39821337xk_idhttps://news.ycombinator.com/item?id=39821337https://news.ycombinator.com/item?id=39821337
<![CDATA[New comment by asa400 in "Why choose async/await over threads?"]]>Honestly that's a fair reply, thanks for the additional nuance to your argument. Upvoted.

]]>
Mon, 25 Mar 2024 19:02:56 +0000https://news.ycombinator.com/item?id=39820085asa400https://news.ycombinator.com/item?id=39820085https://news.ycombinator.com/item?id=39820085
<![CDATA[New comment by paulddraper in "The case of a leaky goroutine"]]>Structure concurrency is to concurrency what structured program control are to program control.

I.e. unstructured concurrency is like GOTOs. Not necessarily wrong, but certainly nerve-wracking.

]]>
Mon, 25 Mar 2024 17:32:06 +0000https://news.ycombinator.com/item?id=39819099paulddraperhttps://news.ycombinator.com/item?id=39819099https://news.ycombinator.com/item?id=39819099
<![CDATA[New comment by asa400 in "Why choose async/await over threads?"]]>> But as it stands now, async/await may be the biggest current premature optimization in common use.

To be fair, isn't the entire point of OP's essay that async/await is useful specifically for reasons that aren't performance? Rather, it is that async/await is arguably more expressive, composable, and correct than threads for certain workloads.

And I have to say I agree with OP here, given what I've experienced in codebases at work: doing what we currently do with async instead with threads would result in not-insubstantial pain.

]]>
Mon, 25 Mar 2024 17:11:33 +0000https://news.ycombinator.com/item?id=39818810asa400https://news.ycombinator.com/item?id=39818810https://news.ycombinator.com/item?id=39818810
<![CDATA[New comment by roguecoder in "The case of a leaky goroutine"]]>Guy Steele's talk "Growing A Language" gets into this. It's definitely worth looking up if you haven't seen it.

I think we've seen two ways languages have successfully been open to evolution:

Java was specifically designed to allow it to build on the standard library over time in fully backwards-compatible ways. It has required the central governance committee to adopt proposals, because reflection is slow and poorly-optimized, but it is a far more fully-featured language today than it was an inception without ever needing a reset. By keeping the surface area small & the strong "Everything Is An Object" paradigm in place, it has had remarkable longevity and has avoided the Python versioning pain.

The second are the "sharp knives" languages: Javascript, Ruby and to a lesser extent C++ (only because DLL hell is very real).

All three of these can be used to write software in any paradigm (including Aspects, if one is a masochist), and so let engineers invest in their own productivity. Languages where the standard libraries are indistinguishable from custom libraries require more skill and collective team alignment to use productively and safely, but also allow for solutions highly-opinionated languages can't support.

]]>
Mon, 25 Mar 2024 16:30:27 +0000https://news.ycombinator.com/item?id=39818314roguecoderhttps://news.ycombinator.com/item?id=39818314https://news.ycombinator.com/item?id=39818314
<![CDATA[New comment by Cthulhu_ in "The case of a leaky goroutine"]]>> The concept was formulated in 2016 by Martin Sústrik (creator of ZeroMQ) with his C library libdill, with goroutines as a starting point.

It's fairly new; the thing (and I think you address it too) is that the pattern did not exist yet when Go was introduced. Go is averse to adding more things to its standard library, or indeed changing its core fundamentals; I think it's better to have one well-defined way of doing things in a language, instead of adding the mental overhead of deciding between one or the other.

And I doubt Go will remove support for their original concurrency, like, ever. I'd love to see forks of Go made with core elements (like concurrency) swapped out though.

]]>
Mon, 25 Mar 2024 15:42:21 +0000https://news.ycombinator.com/item?id=39817750Cthulhu_https://news.ycombinator.com/item?id=39817750https://news.ycombinator.com/item?id=39817750
<![CDATA[New comment by typesanitizer in "The case of a leaky goroutine"]]>Structured concurrency is part of the Swift standard library, and was added at the same time when first-class support for concurrency was added.

TaskGroup in the standard library - https://developer.apple.com/documentation/swift/taskgroup

Explore structured concurrency in Swift (WWDC 21) - https://developer.apple.com/videos/play/wwdc2021/10134/

]]>
Mon, 25 Mar 2024 15:27:36 +0000https://news.ycombinator.com/item?id=39817533typesanitizerhttps://news.ycombinator.com/item?id=39817533https://news.ycombinator.com/item?id=39817533
<![CDATA[New comment by kazinator in "Goto Is Not a Horror"]]>I do not believe the article is correct, then. Dijkstra's goto paper squarely applies to the C local goto. The subject of the paper is not specifically machine language branch instructions that can go anywhere, or something like the global goto in line numbered BASIC (a language he did revile, claiming that it damages the brain).

I'm looking at the paper again. It clearly states that goto should be abolished from higher level languages.

Note that Dijkstra also lumps the repetition statement (while B repeat A / repeat A until B) with goto, and then carefully argues why that is an acceptable use of goto, namely that it is susceptible to analysis by induction.

I can't see how I can reach a conclusion other than that, yes, C has a goto of a type that Dijkstra considered harmful.

Some have argued that forward goto in C is easily analyzable, since it doesn't create loops. There are coding standards that permit forward goto, but not backward goto. What Dijkstra would have thought about the inclusion of a forward-restricted goto in a HLL is anyone's guess.

A C forward goto could jump from the middle of one loop into the middle of another one, though. Simply being forward isn't enough to ensure a certain property of the function's control flow graph. This is written about extensively in the Dragon Book.

]]>
Sun, 24 Mar 2024 15:08:29 +0000https://news.ycombinator.com/item?id=39807698kazinatorhttps://news.ycombinator.com/item?id=39807698https://news.ycombinator.com/item?id=39807698
<![CDATA[New comment by a-dub in "GoFetch: New side-channel attack using data memory-dependent prefetchers"]]>see DIT and DOIT flags referenced in the paper and in the faq question about mitigations. newer CPUs apparently provide functions to do just that.

]]>
Fri, 22 Mar 2024 08:37:30 +0000https://news.ycombinator.com/item?id=39788558a-dubhttps://news.ycombinator.com/item?id=39788558https://news.ycombinator.com/item?id=39788558
<![CDATA[New comment by Kluggy in "GoFetch: New side-channel attack using data memory-dependent prefetchers"]]>Isn't that the entire point of the secure enclave[1]?

https://support.apple.com/guide/security/secure-enclave-sec5...

]]>
Fri, 22 Mar 2024 05:18:20 +0000https://news.ycombinator.com/item?id=39787667Kluggyhttps://news.ycombinator.com/item?id=39787667https://news.ycombinator.com/item?id=39787667
<![CDATA[New comment by smallmancontrov in "Vernor Vinge has died"]]>I'd be pretty comfortable advocating for (metaphorical) Death of the Author on this one if this weren't, you know, a thread about the literal death of the author.

]]>
Fri, 22 Mar 2024 03:47:22 +0000https://news.ycombinator.com/item?id=39787287smallmancontrovhttps://news.ycombinator.com/item?id=39787287https://news.ycombinator.com/item?id=39787287
<![CDATA[New comment by Joel_Mckay in "GoFetch: New side-channel attack using data memory-dependent prefetchers"]]>Encrypted bus mmu have existed since the 1990's.

However, the trend to consumer-grade hardware for cost-optimized cloud architecture ate the CPU market.

Thus, the only real choice now is consumer CPUs even in scaled applications.

]]>
Thu, 21 Mar 2024 18:19:00 +0000https://news.ycombinator.com/item?id=39782350Joel_Mckayhttps://news.ycombinator.com/item?id=39782350https://news.ycombinator.com/item?id=39782350
<![CDATA[New comment by bee_rider in "GoFetch: New side-channel attack using data memory-dependent prefetchers"]]>One option would be for people to stop downloading viruses and then running them.

]]>
Thu, 21 Mar 2024 18:17:27 +0000https://news.ycombinator.com/item?id=39782330bee_riderhttps://news.ycombinator.com/item?id=39782330https://news.ycombinator.com/item?id=39782330