4
points
dakom
Joined 281 karma
- I wouldn't dismiss personal anecdotes any more than I'd dismiss someone claiming they saw something in a reputable journal but can't remember the citation.
In other words, yeah, don't just believe it at face value- but if you have good reason to trust the source, it's worth considering and checking into further.
In this case it's not just one individual but many people saying that THC and CBD are almost opposites if eachother, for example in how they affect anxiety.
Definitely worth proper research imho, could lead to medication that has more of the pros and less of the cons
- Funny coincidence, I use this often and just opened an issue earlier today: https://github.com/go-task/task/issues/2303 :)
- I've never delivered a game anyone's really paid for, so take with a grain of salt, but imho the big win when you are writing your own stuff is you get to decide what not to include.
That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on - but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine.
Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right.
The list goes on and on... maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way.
Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc.
I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)
- There's also some cool stuff brewing in the AVS space to allow nondeterminism, GPU, storage, and more.. for example, WAVS executes stuff off-chain in WASI components, and brings the result on-chain (secured by re-staking via Eigenlayer etc.)- so there's a roadmap to do things directly in wasi-gfx powered shaders and more low-level access like that
- bevy_math also uses glam, re-exported in the prelude: https://github.com/bevyengine/bevy/blob/cc69fdd0c63ea79fda4f...
- Do you remember Angry Birds? https://villekoskela.org/2012/02/15/angry-birds-facebook-rel...
- Eh.. lots of projects targeted mobile app stores by authoring in Flash and using the GPU accelerated stuff. Starling was a semi-blessed framework. Worked perfectly well, no battery drain. Lots of "native" apps were authored that way (and still are, you see the same approach with Unity etc.)
Browser plugins could have been fixed to catch up, the VM itself wasn't the problem in terms of drain
- While some of this is true, some of it is not (deep links worked fine, there was a brief time where hidden html was encouraged and worked just as well for search engines to pick up, etc.)
More to the point though- Flash didn't shine as a regular website thing (Adobe people used Dreamweaver for that, if anything). It was a game/application development tool. Most of the time you didn't need any of these web-friendly things, same way you'd expect every game to have a different menu system.
It was an awesome time for innovation and creative thinking. Not everything is a flex box. I miss those days
- I'd agree it's largely the human factor, but maybe from a different angle. Rust has got the "there's a crate for that" factor, like JavaScript, which helps onboard people who are afraid of getting stuck writing everything from scratch.
For example, serde (and serde_json, toml, etc.) is a gamechanger, as is tracing, reqwest, and many others.
So, maybe less about the language itself for many people, but more about the human factor of overcoming fear of being stuck on an island
- > overhead of each API call
Yeah, that's an issue, esp with WebGL.. but you can get pretty far by reducing calls with a cache, things like "don't set the uniform / attribute if you don't need to".. but I hear WebGPU has a better API for this, and eventually this should get native performance.. though, I also wonder, is this really a bottleneck for real-world projects? I love geeking out about this.. but.. I suspect the real-world blocker is more like "user doesn't want to wait 5 mins to download AAA textures"
> Nerfed timers
Yeah, also an issue. Fwiw Mainloop.js gives a nice API for having a fixed timestep and getting an interpolation value in your draw handler to smooth things out. Not perfect, but easy and state-of-the-art afaict. Here's a simple demo (notice how `lerp` is called in the draw handler): https://github.com/dakom/mainloop-test
Re: multithreading, I don't think that's a showstopper... more like, techniques you'd use for native aren't going to work out of the box on web, needs more custom planning. I see this as more of a problem for speeding up systems _within_ systems, i.e. faster physics by parallelizing grids or whatever, but for having a physics WASM running in a worker thread that shares data with the main thread, it's totally doable, just needs elbow grease to make it work (will be nice when multithreading _just works_ with a a SharedArrayBuffer and easily)
- I've been using Figment [0] Needs a little bit of hand-holding when you have structs with different field names, but otherwise does everything I need for that particular part of the problem.
- Love this :)
Small, related anecdote: back in the year 2001 or so, this is in the same family of how I built websites...
The difference is I wrote in in C as Apache Modules. So, like, most people were using other people's C modules (like PHP or CGI), but once you dug deeper and you wrote your logic/site _as_ a C module, it was so much more fun (and powerful too).
I didn't have much of a templating language, so the answer to "can we change the text on this page?" was usually, "sure, just give me a few minutes to recompile the whole Apache server" :D
Fun times
- Yeah, the game I linked to is in Rust/wasm, running solely in browsers :)
The interesting part of the collision detection code is here: https://github.com/dakom/not-a-game/blob/main/src/collision/...
- FYI, I recently posted about a 2d game I made, here: https://www.hackerneue.com/item?id=41761517
Putting aside the politics and all, focusing on the tech- one thing I came across when trying to do my own collision detection was the idea of using the GPU and occlusion queries for pixel-perfect results.
I didn't come up with the technique, but it's super cool, and since you're not taxing the GPU with tons of 3d triangles, it's perhaps a bit more free to do stuff like that.
- I don't think you get how powerful Rust's pattern matching is, or how to think of it in terms of a router.
From my example above, check out https://github.com/dakom/dominator-workers-fluent-auth/blob/... and follow it through to https://github.com/dakom/dominator-workers-fluent-auth/blob/...
Do you see that you have static and dynamic parts matching, multiple variable capture, etc.?
I'm not talking from a theoretical perspective. I'm showing you an actual example of a fully baked auth system that does everything on the wishlist (and more) and has no need at all for a router because Rust is itself powerful enough to do all that out of the box
- > URL redirection
Erm, just return a new url after the match? Get fancy with state machine like enums? Rust has everything you need here, not getting why you think this requires a framework.
> Specific management of [...]
again, match for that, map your url parts, whatever - it doesn't need a 10,000 pound gorilla when it can be done in a line or two of code
> complex regex matching
erm, regex crate?
> Django, Laravel, Rails
Yup, those are valid choices. I said it's not a framework problem necessarily.
Not a one size fits all sorta problem.
Wordpress is also a fine choice if your business is knocking out new sites for a new client every month.
But, if you're building a single product over the course of a year or two, it's not the end of the world to spend a couple weeks rolling your own auth and hook it up to transactional emails and everything else. It's just one small problem to deal with, not major in the grand scheme of things. YMMV
- This article makes several different points that would ideally each be tackled on their own.
You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need)
Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily
CSS/JS tooling makes no sense for many frontend Rust frameworks like Dominator, which is in Rust (not JS) and has its own approach to styling that works for it (e.g. attaching styles to signals, so they change on the fly)
I get what the author is saying - in fact I've been around the block a couple times solving all the different points in the article and it is painful. For example, see https://github.com/dakom/dominator-workers-fluent-auth which does a lot of the stuff here on the Cloudflare workers framework (also adds another wishlist item - localization with Fluent)
A "batteries included" full framework that does _everything_ is nice to have, but many real-world projects will want to replace those opinionated decisions and go the DIY route anyway. Rust is more than mature enough, even on the frontend web, to tackle all of that - if you know where to look (wasm-bindgen, etc.)
- Of course, goes without saying - the parts I'm most happy to discuss here are about the tech... though... this was a slow-burn of a project I started nearly a year ago and then abandoned. I think the pixel-perfect occlusion query stuff is neat (for someone like me who never worked on AAA games at least), but, I wouldn't really be able to explain how it works without re-learning, hehe ;)
I really like the combo of Shipyard ECS for the game stuff and Dominator for UI. I've used Dominator on large projects and it continues to be a great framework.
Shipyard is just super clear and is easy to reason about. I know Bevy is the hot thing these days, and maybe I'd check that out for a larger / collaborative project, but Shipyard really hit the sweet spot for letting me get into the nitty gritty (which I could manage here since it's just simple 2d state machine sorta stuff)
- I do consider it a feature, in hindsight. Learning to program by asking "dumb" questions was great, because chats were ephemeral, nobody cared if the same question was asked for the 10 millionth time or risk of embarrassment being like 12 years old and asking greybeards for help.
Nobody also felt bad saying "RTFM" because, whatever, it blows over in a minute, there's no permanent record of having a harsh moment, more free to just move on.
The same old questions being asked due to no search also provided more opportunities to answer those questions, so, newbies could start to learn by teaching.
So, yeah, I think something beneficial was lost, even if I wouldn't go back to that approach- it's more of a tradeoff than a definitive improvement
1. Codex takes longer to fail and with less helpful feedback, but tends to at least not produce as many compiler errors 2. Claude fails faster and with more interesting back-and-forth, though tends to fail a bit harder
Neither of them are fixing the problems I want them to fix, so I prefer the faster iteration and back-and-forth so I can guide it better
So it's a bit surprising to me when so many people are pickign a "clear winner" that I prefer less atm