eslaught

I don't know if you noticed, but my test has on the order of 10 billion rectangles. Only about 80k are drawn on the screen at once because I do very aggressive culling.

To be honest, I'm not sure Canvas can handle either part of this: either drawing 80k rectangles at 60 fps or culling so that the other 10 billion don't need to waste CPU cycles. It requires a very tight integration with the UI library to make sure we do this fast.

Yes, it's a very narrow use case. That's why I went with a specialized UI library.

It sounds like you want BokehJS. It was one of the alternatives I was recommended while I was exploring, but for various reasons my particular use case is not so easy to integrate (plus my backend was already in Rust).

https://github.com/bokeh/bokeh

I did do a basic test, and the raw rects-on-screen performance is roughly comparable to my final solution.

In my testing, I went through a bunch of Rust frameworks that sit on top of the core OS UI frameworks. My experience with all of those was that they all capped out at about 3k rectangles on a screen at a time at 30 fps (vs the about 80k rectangles that fit at usually 30-60 fps in my demo).

I wonder if your experience is different?

As best I've been able to tell, right now you have to make a choice between (a) fast and (b) native, and you only get to choose one. And in my application domain, fast is nonnegotiable.

I have no beef with deferred mode GUIs except that I have yet to see one with the performance characteristics I need.

For what it's worth, egui does have an accessibility layer. I haven't gone to any particular effort to wire it up yet (besides what you get by default): https://github.com/emilk/egui/issues/167

I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the other GUI stuff I needed.

WASM demo here if you want to see it (with dummy, and not particularly realistic, profiling data): https://elliottslaughter.github.io/legion-prof-viewer/

For comparison, the UI I'm replacing falls down with about 16 nodes worth of data. (The demo has 8192 "nodes" worth of fake data.)

How much do you know about research funding?

For example, the fields you mention (sciences/engineering, medicine) pull in vastly more money that humanities. Because they have more money, they hire more faculty, and they also train and graduate more PhD students.

I knew a few humanities PhD students while I was in grad school, and none of them were funded by research grants. If they were lucky, they got fellowships. That's a stark contrast to engineering where both grant and fellowship funding was relatively plentiful (though I've got a few horror stories there too).

On top of it, humanities jobs are really hard to find (even more difficult than fields like physics that are already known for multiple postdocs, etc.), making it a bad deal all around for PhD students in those fields.

Overall, I think things are already allocated more or less the way you expect, and I don't think we need to piss on humanities for this. They already have it hard enough.

Wasn't expecting the audio commentary at all, and I have to say (beyond the visuals, which are also cool) that it's very well-done. Thanks for sharing!

If you're trying to solve boolean satisfiability, you want a SAT solver, not Prolog.

If you're trying to solve more general problems, you probably want an SMT solver or other more specific solver (e.g., ILP), not Prolog.

If you're trying to verify software, you want a theorem prover, not Prolog.

If you want database-ish stuff you want Datalog (or something like it), not Prolog.

Prolog falls into the uncanny valley of being too general of a DSL for the sorts of optimizations that more narrow solvers enjoy, while being too narrow of a DSL for most general-purpose programming. I think because it was an early DSL, people got caught up in the idea of it being more "high-level" than other languages [1], but the DSL nature of it wasn't fully appreciated at the time.

[1]: For fun, take a read through https://en.wikipedia.org/wiki/Fifth-generation_programming_l... , which was a whole thing in the 1980s.

They tried spinning it off as Quickster some years ago. It was an epic PR failure. I suspect that's why they're throwing in the towel now: they don't want a repeat even if the business could be saved.

> I’m not aware of apprenticeship models.

Maybe not a popular answer, but I think the answer to this is grad school. Someone gets a PhD in an area like this (e.g., building either theorem provers or their related infrastructure), then gets a job in the same or an adjacent area after graduation.

That's not the only way to do it, but looking around in my area of research (compilers and programming languages for HPC) there are definitely many more people who do it this way than just figure it out on their own.

I second not sharing anything that isn't already public.

But there is this pattern where these discussions get hashed out either (a) when someone misbehaves and dang posts a reply to remind them about the guidelines or (b) like this, we have an impromptu comment thread on HN's mechanisms. In either case, the content gets buried pretty quickly and we're relying essentially on human memories to keep this institutional knowledge alive.

I wonder if it would help to explicitly collate this information somewhere. Think, something parallel to the guidelines. But the guidelines answer the question, "how should I behave on HN?" whereas this would be answering "how is HN run?" (Or perhaps, how is it not run.)

It's a half-baked thought, so don't take it too seriously, but I figured I'd mention it.

I read through your linked post, and I wonder if it would work better if the algorithm was something like this:

Take what is currently the two front pages (i.e., the current front page, and what you get to when you click "next" from the front page). Then randomize out of that set and show it to the user.

You could do that for any value N, perhaps even a fractional N (1.2, 1.5, etc.) to see how much of an impact it has.

Instead it sounds like you took /newest posts and randomly placed them on the front page. These may be completely or nearly completely unvetted, so it's not surprising to me people reacted to that. (Granted, this is with the benefit of hindsight and so on.)

Stepping back a bit, I'm not sure any of this will meaningfully change the "mob" dynamics of HN. But HN attention is so focused right now, I do think spreading that out might have an impact. Right now, posts tend to die off quickly and sometimes I wish discussions would live on a little longer than they do.

I definitely empathize with feeling that any change could make things dramatically worse.

Can anyone tell me if there is an equivalent option on Android that I should be looking to disable? (Google Pixel device, stock Android)

Huh, interesting. I'm on macOS, and I don't think I've experienced any of this.

My #1 gripe is that an increasing number of websites just don't work. Microsoft Teams is a big culprit, but I've had issues with medical and bank websites too. It's not Mozilla's fault that we're increasingly in a Chrome monoculture, but it sure is frustrating to live with.

Have you actually tested this? The blog post makes it sound like this just landed.

Of all the things that frustrate me about Firefox (and it is my daily driver), UI latency is not one of them.

But was Microsoft ever cool in the sense that Google was circa 2005? (Asking honestly, I'm too young to remember that period.)

> could you please explain a little what kind of "configuration isolation" you mean?

It's been a while so I don't have the whole list off the top of my head, but there are several configuration files that live in $HOME by default unless you set SPACK_DISABLE_LOCAL_CONFIG=1. Those files can e.g., list compilers and software packages, if I recall, among various other settings.

> like what for example?

I was trying to follow someone's recipe for building something with Spack. I hit some sort of compiler error (sorry, it's been too long, don't remember). And the solution they suggested was to modify compilers.yml by hand to set various things. (Something about setting the right paths for using Cray's compiler wrappers with rocmcc...) That and I had to fuss with packages.yml to configure the system MPI. I remember trying to figure out how use "spack config set" to configure these files automatically, but the syntax was (a) completely undocumented and (b) not actually powerful enough in practice to configure either of those files. So I gave up on that, set SPACK_DISABLE_LOCAL_CONFIG and just saved the modified yaml files into my repository so that I can at least recover my settings if I need them in the future.

For advanced use cases, it seems like you basically need to modify these yaml files to get anything done, but the amount of documentation and support for doing this automatically is really lacking. (And the idea that you're supposed to require every user to do this manually is even more insane.)

> Try spack external find, and much of this problem goes away. It will register the existing packages as externals.

To be clear, this goes through a hard-coded list of packages, and adds them to Spack. It cuts maybe about 20-30 minutes off your 2+ hour build time. And it doesn't find any libraries (MPI being the most obvious one you'd want). So, better than nothing, but far from what it needs to be.

> public binary mirrors

Is that on by default? I went through this only a couple of months ago and I don't think any of my packages came from mirrors.

One practical challenge in using this in practice is that you definitely want some of your packages built with the local compilers, with maximally native settings (so native MPI, march=native, etc.). Other packages you may not care about at all (autoconf, etc.). So while I believe that Spack allows you to do that, it doesn't necessarily make it easy to do. I suspect when you tell Spack to build something with a certain compiler, it just builds everything from scratch because it can't tell where you actually care about getting the most tuned code.

I'm surprised that no one here has talked about the build times yet. As a new user, the first thing you notice out of the box is that even on a relatively beefy system, you spend ~2 hours getting to a working state, even when you're building a relatively modest set of packages. This is particularly surprising since one of the points of Spack is to integrate with the existing system software, and so much of what you're building already exists and works fine on the system.

In the past when I've talked to people about this, the answer I got was "well, set it up once for your team and don't reinstall it all the time". Which is kind of awful from a "cattle, not pets" perspective. Several other design decisions in Spack (like the lack of certain kinds of configuration isolation by default, and the general difficulty of configuring certain kinds of things) make it feel like a "pets" system. I've gotten instructions from people on using Spack to install things that have been impossible to follow because they fiddled with something in their environment and forgot to tell me.

The best thing I can say about Spack is that all the other systems are worse. I just wish they could get around to fixing some of this stuff already.

Let me take this even further.

We have systems, today, that take a specification and generate code from it (and will even do so in a provably correct manner). There are scalability issues with such systems, but they exist and have in some form for decades.

None of these systems have taken the world by storm.

If what ChatGPT and their ilk do is make it easier to spew out bulk spaghetti code that is essentially unverifiable, I don't think that's going to transform the industry nearly as much as anyone thinks it will. For boilerplate code, sure—but that's exactly where we should be using better abstractions anyway. For small code which you can verify by hand, sure. But for anything larger than that, we're just watching a trainwreck in slow motion.

Large code bases written by humans are already hard enough to understand. How much more difficult will it be when your AI can spit out a million lines of code in a second?

Without specifications, it's all worthless. But the specifications are the hard part.

Since we're here, what kind of dash do you use for dates? 2023-03-12

I've tried to be more dash-correct, but I've realized there are corner cases that none of these guides address.

This doesn't fit my experience.

I mean, yes, this was me. I came in knowing most/all of this. I knew six (or more?) programming languages, had at least played with CVS/SVN, had installed Linux (read: fought with the Linux bootloader to get my AMD CPU to boot without crashing), had dipped my toe in a few open source communities.

But I was a tutor in college and I interacted with a bunch of people who didn't come in with any of this experience. Many of those people struggled, but I also know a bunch of people who came into CS knowing nothing, loved it, and went from zero-to-sixty faster than even the people who came in knowing a lot.

I'm still not sure I can identify what the ingredient was, but experience alone is not enough to explain it.

If you want to dig into the details, The Trial by Publisher's Lunch has the (edited) trial transcripts.

https://shop.publishersmarketplace.com/

I was surprised by how readable it is, but I guess I shouldn't be. The judge, of course, is not a publishing expert. So much of what you have in this case is witnesses explaining, more or less from first principles, what the publishing business is and how it works. Except the witnesses are CEOs of the Big Five publishers, and similar level people. And (except in a few cases) I was surprised to find the testimony is refreshingly direct, for an industry that is often mired in ambiguity.

I agree it's not sinister, but I think it goes deeper than this.

Strong (static) type systems fundamentally make you do more work up front. They force you to be more explicit. They restrict what you can do. They're in your face, because you can't get your program to compile without them. No one gets through any significant amount of Rust programming without knowing that the borrow checker is there. It's so fundamental that it's just part of the experience.

C++ arguably has just as many rules for writing "correct" programs, but they're not enforced by a compiler. So much stuff happens by convention. If you follow the convention, great, your code is safe. If you mess up, no one catches you. Because it's your responsibility, it's easy to attribute this failure to your programming skill rather than to the language that made that mistake possible in the first place.

I'm not saying stronger type systems are always better, but I do think there is a fundamental human tendency to attribute the up-front as hard and the latent as easy, even if the up-front work ultimately helps you avoid the latent work down the line.

Anecdotal, but I recently had the opportunity to write some relatively greenfield code in each of Rust and C++. Nothing too massive, a few thousand lines. But fairly intricate code with a need for high performance. I consider myself to be fairly advanced in both languages (but not can-write-the-spec level advanced).

I was shocked at how many memory corruption / uninitialized data errors I was hitting in C++, for what (I thought) was fairly nice, modern-ish code. This is for code that builds cleanly with -Wall -Werror, with exclusive use of .at() instead of unchecked vector/map access, etc. There are just far too many ways to end up with uninitialized data, and the ecosystem (think serialization libraries) don't really help you there.

I didn't realize how much of a cognitive burden Rust was relieving me of. Sure, the borrow checker is a pain. But I have confidence that when my code builds, it will be entirely free of certain classes of bugs. And other classes of bugs are well-managed by Rust's compiler warnings and Clippy lints.

There seems to be a sort of sleight of hand in programming communities where when Rust is hard, we blame it on the language, but when C++ is hard, we blame it on the programmer. I didn't see the article do a good job of teasing this out.

If you really want to dig into it you can read up on the tutorials and/or papers from the Legion project: https://legion.stanford.edu/

But briefly, these task-based programs preserve sequential semantics. That means (whatever the system actually does when running your program), as long as you follow the rules, the parallelism should be invisible to the execution of the program.

I am biased because this is my research area, but I have to respectfully disagree. Actor models are awful, and the only reason it's not obvious is because everything else is even more awful.

But if you look at e.g., the recent work on task-based models, you'll see that you can have literally sequential programs that parallelize automatically. No message passing, no synchronization, no data races, no deadlocks. Read your programs as if they're sequential, and you immediately understand their semantics. Some of these systems are able to scale to thousands of nodes.

An interesting example of this is cuNumeric, which allows you to take sequential Python programs that use NumPy, and by changing one line (the import statement), run automatically on clusters of GPUs. It is 100% pure awesomeness.

https://github.com/nv-legate/cunumeric

(I don't work on cuNumeric, but I do work on the runtime framework that cuNumeric uses.)

s/happiness/health/ and then I think we have a more reasonable starting point. (And I mean health in the holistic/whole person sense, not in the limited sense of how well your biological machine is running.)

I think this helps make it clear that any single goal can compromise overall health, even if along that dimension you're exceptional.

Hasn't it already been trained on what is effectively the entire contents of the scrapable internet? There isn't another 10x to be had there, let alone 100x.

I assume that whatever future improvements we get from improving algorithms (or perhaps through throwing more compute at it), not through larger datasets.

> GPU support

If you haven't tried cuNumeric [1], you really ought to. It's a drop-in NumPy wrapper for distributed GPU acceleration. Would be interesting to see if it works for this.

[1]: https://github.com/nv-legate/cunumeric