coxmi

> but the bindless approach can give you both ergonomics and performance in some cases (not all). Certainly it can reduce CPU overhead - passing a single pointer to a shader is much faster than heavy bind group updates. The trade off is that you might have more pointer indirection on the GPU, which can introduce stalls.

Yeah I'm totally with you there, it just feels like the interfaces aren't that pleasant at the moment (although I've not tried Metal)

Edit: didn't realise you were the project author, I think it's great by the way!

Sorry, I wasn't clear (and have edited the post), I absolutely do believe that usability is important, and to be honest I feel like it's the main problem with graphics APIs (at least for my skill level).

Where I'm at now is that Vulkan is great because it's removed so many of the hard-coded assumptions that were previously hidden in the driver layer, allowing much greater CPU and GPU utilisation and performance when you need it (if you can get past the ugly APIs).

Where the usability stuff comes in is that it allows for the creation of alternative, higher-level shader-reflection setups that work brilliantly for simple use cases, all in user-space, which can open up shader programming for creative coders and a broader spectrum of developers. The lower-level APIs are then still accessible to those who absolutely need those performance levers.

Looking at the code examples (e.g. the cube[0]), I can’t get away from the idea that this looks very similar to standard OpenGL bindings, just with a different style of boilerplate.

At some point (for basic rendering examples at least), you’re always going to have to define a data layout of some sort, have that reproduced or reflected between the cpu/gpu environments, and iterate through each vertex. How exactly that turns into GLSL’s in/out variables feels to me like a relatively unimportant implementation detail that should be assessed on performance alone rather than usability[†]. I wonder if what we’re ultimately heading toward is better shader compilation, directly to SPIR-V, to support both bound and unbound use cases.

Sort of related, but Gabriel Dechichi’s engine [1] reflects shader vertex layouts back to C, so you get compile-time error handling if the struct layouts don’t match between cpu/shader.

[0] https://github.com/rkevingibson/loon_gpu/blob/main/examples/...

[1] https://m.youtube.com/watch?v=NTuLfB2ex5Q&ra=m

[†] Edit: Specifically talking about the final compilation unit here, not the shader language or library interface

I wonder what the dev/CI process looks like on this.

Will it ultimately be manually loading a build into specific hardware each time, or is there a level of automation that can be done here?

Thanks for the detailed answer :)

All this does for me is raise the question of why they chose to use the `.` for so many different uses. I'd be fine if it was just to infer the type, but it seems very overloaded.

Yeah, after looking it up, it looks like it is basically only used as either field access or an 'infer operator', is that right?

I thought it was used in four completely separate ways:

· normal struct field access

· anonymous struct definition

· field definition within structs (for reasons to do with the parser)

· an extra 'infer operator' for syntactic sugar

But there's no support for anonymous structs/fields, and all structs and fields require a type somewhere for it to be inferred. Which is why this is invalid zig:

  const test = .{ .x = 0, .y = 1 };

(It would need the type to be specified in the called function definition, or inline when assigning)

Correct me if I'm wrong here! (And thank you)

The dot syntax used everywhere really confuses me. I get its use in struct fields, or for defining anonymous structs, but what is this one for? (Some kind of module-level enum space, where .sampler and .unknown are defined previously?)

  const Sampler = @SpirvType(.sampler);
                             ^

  const Image = @SpirvType(.{ .image = .{
    .usage = .{ .sampled = u32 },
    .format = .unknown,
              ^
  } });

Everything else about zig is quite readable, but this gets me every time. Maybe I'm being dumb though.

Great stuff!

I can imagine the financial modelling side is a particularly difficult balance, yeah. Mod support sounds amazing though, I'll keep a look out. :)

This looks great. I've had a quick look through the docs and can't see anything about bikes under transport, or, under housing, anything relating to modes of tenure that aren't private rentals (e.g. Vienna-style social housing, housing co-operatives, or private ownership). Would be lovely to play around with those variables.

Also, for finance, is there a particular reason why the finance sector calculations look quite simple (on the face of it, at least)? They seem only to be a percentage lift based on aura, rather than anything resembling any number of complex sectoral dynamics, from full rentier-financial domination to prudent support of industry/services.

Thank you!

Nice project!

I’ve been doing something very similar recently[0] with slightly different goals (still a tiny bundle size, but fully typed uniforms, deeper control over buffer bytes and layout, and less setup).

Some in the comments seem to think GL is dead, but for me I think it’s just an easier shader language for beginners and that’s most important for dabbling and many small web use cases.

[0] https://github.com/coxmi/gleasy

The point of civilisation, however loose that idea may be, if it’s anything at all, is determined by people.

Technology exists today in a way that feels like it could be defining its own path in a sense, but much like oral tradition, neither are large enough concepts to describe civilisation.

This is an insane claim:

> The entire point of civilization and society is that we are all "addicted" to technology and progress.

Technology is like much of material reality, in that we can think whatever the hell we like about its various forms, especially so if we’re surrounded by it.

Is there a general preference for serifs, or a local style in Finland for this reason?

German certainly has typographic preferences that err toward taller x-heights and narrower forms due to heavy use of portmanteaus. It’d be interesting to know of other language-specific typographic styles too.

This sounds really interesting, do you have any more info or a repo to follow?

> Every Noise at Once was a long-running attempt at an algorithmically-generated, readability-adjusted scatter-plot of the musical genre-space, based on data tracked and analyzed for 6,291 genre-shaped distinctions at Spotify through 2023-11-19. The calibration is fuzzy, but in general down is more organic, up is more mechanical and electric; left is denser and more atmospheric, right is spikier and bouncier.

> Click anything to hear an example of what it sounds like.

> Click the » on a genre to see a map of its artists.

> Be calmly aware that this may periodically expand, contract or combust.

Nice to know i’m not alone, I’m sure there are dozens of us — dozens!

I’d go further than this and say globally-scoped CSS is fine as long as you’re using a decent naming pattern (e.g. BEM), or @layers.

For me, back in the JQuery days, the problem was always globally-scoped JS/DOM, rather than CSS. The big revolution was simply co-locating/importing styles in JS modules during the compile step, which works surprisingly well even outside of any framework.

Just using vanilla DOM or a small wrapper around web components for connectedCallback/disconnectedCallback logic is refreshingly simple. It’s quite sad that most SSR frameworks don’t allow this sort of approach, and lock you in to a specific framework.

rsync needs some love on this.

The most memorable args for me are `-mrchivas`, because together they sound somewhat like a name (“Mister Chivas”)

(I drop the -a depending on whether archive is needed, Mr. Chivs sounds fun too)

Ooo nice, I didn’t know about this. Thanks for posting, looks interesting, and framework agnostic to boot :)

(Edit: well, potentially at least)

I did try to make something like this a couple years back to deal with multiple renderers and a choose-your own set of various SSR techniques [0], but didn’t get very far with it in the end. I should have based it on Hono really, to get web standard Request objects.

[0] https://github.com/coxmi/ssr-tools

That’s a shame, I’ve also been through much the same process.

Astro is pretty good too, though. I’m not 100% sure on some of the decisions it’s made, and personally don’t enjoy the need for new file formats and domain specific languages, but it does a half decent job of being framework-agnostic despite a few pain points.

I don’t disagree on that front, the React ecosystem is huge, and rebuilding a load of complex components is often beyond the budgets of many greenfield projects.

I also don’t believe a React monoculture is good, so a growing Preact or Solid ecosystem would be really positive, alongside growing web/DOM standards to ultimately make these frameworks more of a light wrapper around some trivial updates.

React and Next.js, to me, have done the typical architecture astronaut thing, and it feels like they’ve both increased the barrier to entry and just made everything a little more complicated than it really needs to be for much of the web.

Deno Fresh seems like it has the right approach. It’s not complicated, the docs are refreshingly simple, and it handles both server and client logic without getting confused.

It’s just a shame it’s Deno-only (although I completely understand why)

That’s where duodecimal comes in…

Clearing the waste sounds like a good thing, I guess. Haven't got time to read the study, but can this have beneficial effects to do while awake?

It certainly feels quite strange after watching the prototype for 8 cycles.

Composer’s means of including packages doesn’t do the language any favours imo — it doubles down on namespaces (and complex PSR 4/7 ones at that) and the cli isn’t particularly intuitive.

To me, what PHP needs is a simple module system with scoped functions and variables, an object literal syntax rather than `new \stdClass`, and first-class simple to use threading/async/promises for concurrent requests and IO.

A great cross section of math and creative expression — well worth a watch

Great paper, thanks for posting.

It reminded me of a lot of themes present in my design education, of political downstream effects created by apparently neutral technical decisions, and therefore the inherent responsibility of creators when putting something into the world.

Not just standard economic externalities but consequences for human interaction.

A nice flashback to university, so thanks!