CreepGin

"nine women can't have a baby in a month". Speed of software development is not pure output.

IMHO, Brooks's Law applies more today than ever.

Yeah I mean I also chuckle at good (or cheap) puns sometimes. But wordplay and puns are the current ceiling of LLMs. Good at them because they're purely structural (pattern-match on phonetics, then swap the meaning). In that bit, there's no buildup, no callbacks, no escalation, no expectations to subvert, no thesis, no perspective.

Grounded, buried, couchy, deep-seated, eyes, baked... It's like a thesaurus!

I feel like human comedians would have to deal with a lot of layered subtleties. They would make the potatoes _serve the bit_ instead of _be the bit_.

I'm not sure if this is mythos-specific though. Past models have been great at puns! They do wordplay and puns reasonably well because those are structural.

However, the concepts of comedic timing, subversion of expectations, and emotional punch are kinda contrary to how LLMs work. LLMs are trained to minimize cross-entropy loss. So by construction, they're biased toward the statistically expected.

Nope I guess can't tell between machine written and mediocre jokes.

Models are structurally biased toward the expected, which is the opposite of what makes a joke land or a poem transcend.

When a model can tell funny jokes or write good poetry, that's when I'll be concerned.

because AI can trivially be told to imitate that

lowercase, maybe, but not em dashes.

Yes, at the very least, it's a no-brainer for OS maintainers who are already paying for Max 20x.

You missed the sarcasm.

Everyone says that but I don't see anyone cooking up the next photoshop and selling it at $3/month.

Yup, same reason you can't throw manpower at a software project and expect a proportional outcome (Brooks's Law). AI amplifies what's already there; it doesn't conjure taste or product vision out of thin air.

Yeah to me, Burst+Jobs and Compute shaders are so easy to work with in Unity, I haven't felt the need to squeeze more perf out of C# in a long time.

For modding and OTA stuff I just use a scripting language with good interop (I made OneJS partially for this purpose). No more AOT issue and no more waiting for domain reload, etc.

Yes and it works well IME. https://docs.unity3d.com/6000.3/Documentation/Manual/roslyn-...

Now I think about it, writing SourceGenerators is actually a great fit for AI agents.

Wow that's less than a month ago. I wonder if this kind of stuff is picking up steam.

Rivlin told me that the bogus customer service number and the impostor representative were believable.

My wife said it was the persistent CC# inquiry combined with the heavy Indian accent that put her on alert.

Yes what the hell is wrong with this title. Where on the pricing page does it say the Industry plan require a runtime fee?

Yup, I agree with the author 100%. By far the worst part of AI code generation is the inability to discern old and deprecated APIs/syntax/workflows of tech stacks that are constantly changing.

As someone who maintains multiple JS libs and provides support on Discord, the #1 reason I default to using TW is because it lets me drop code snippets in chat without lugging around an extra CSS file or walls of inline styles, keeping everything compact and easy to read (tons of vertical space saved).

Example: https://onejs.com/docs/web/tailwind#quick-example

Without TW, that snippet may need to take 3x more lines.

---

My major issue with TW at the moment is that I use TW in a non-browser environment (Unity), so TW3 is fine since I can tweak everything with JavaScript. TW4 shifts everything to CSS, gives zero workarounds, and my setup crumbles.

This was many years ago, after Unity released mathematics and burst. I was porting (part of) my CPU toy pathtracer to a compute shader. At one point, I literally just copy-pasted chunks of my CPU code straight into an HLSL file, fully expecting it to throw some syntax errors or need tweaks. But nope. It ran perfectly, no changes needed. It felt kinda magical and made me realize I could actually debug stuff on the CPU first, then move it over to the GPU with almost zero hassle.

For folks who don't know: Unity.Mathematics is a package that ships a low-level math library whose types (`float2`, `float3`, `float4`, `int4x4`, etc.) are a 1-to-1 mirror of HLSL's built-in vector and matrix types. Because the syntax, swizzling, and operators are identical, any pure-math function you write in C# compiles under Burst to SIMD-friendly machine code on the CPU and can be dropped into a `.hlsl` file with almost zero edits for the GPU.

yup, "em dashes" was just easier for me to type to give an example/heuristic. Everything else would require a tad more effort to explain.

I was scratching my head pretty much the whole time during the first read.

I feel you. Nowadays I have to use tactical lowercasing and curses here and there to avoid AI-looking responses.

It reads to me like typical marketing writing.

hmm maybe that's why it rubbed me the wrong way.

The Clickbaity title certainly did the trick!

Well, you may need to worry about them now. It's a well-known issue with the mainstream LLMs. Every few days, you see a new post on reddit from people asking how to get rid of em dashes from ChatGPT, etc.

Even when they are not a telltale-sign, folks are afraid of using them now because of AI. I'm not saying em dashes are bad. Our books are littered with them, and that's why LLMs spit them out consistently.

https://medium.com/@brentcsutoras/the-em-dash-dilemma-how-a-...

Looks like that article was AI generated by a SEO consultant. Ironically, if anything "broke" the web, it's ADs and SEO...

Sorry, the article itself was really painful for me to read.

Holy s@#$! You're right. I didn't catch it at first, probably because it was on the HN frontpage. But yeah, the amount of em dashes (among other things) totally gives it away.

There were so many contradictions in the article, I was going to point them out. Don't see a point now.

Same here. We went with Electron mainly for consistency and stability. The larger bundle size wasn’t an issue for our particular project, so the decision was pretty straightforward.

Yep, we use Electron specifically because it gives us a locked-down version of Chromium with a consistent WebGPU implementation. Without that, we're stuck dealing with whatever browser version the user happens to have, and that completely wrecks the stability of our GPU pipeline.

Sure, for a quick run down:

1) Use Electron if stability and having chromium and v8 is important to you (i.e. for WebGPU, etc.). It has the biggest community and set of existing apps made with it. Largest base app size (~100MB). But should be acceptable for most desktop apps unless you are making small utility apps.

2) Use Tauri if app size is important to you. It's like Electron but with a slimmer runtime and a Rust backend. Still uses IPC.

3) Use Dioxus if you already think in Rust and don't need any JS framework. Everything is in one Rust process. No IPC. Smallest app size (~5MB). It's still very new though. Tooling is less mature (still uses a lot of other 3rdparty stuff for packaging, etc). Community is smaller.

4) Flutter has the best mobile DevEx. Uses Dart.

5) Wails is great all-around. Best tooling and JS bridge, IMO. I'd recommend going for it if you already know Go.

* Tauri, Dioxus, and Wails all default to using OS's webview.

Need to dig into this more, but I built OneJS [1] (kinda like React Native but for Unity), and at first glance this looks perfect for us(?). Seems to be super handy for Unity where you've got meshes, RenderTextures, ComputeBuffers, and NativeContainers allocations that all need proper disposal outside of JS. Forcing disposal at lexical scopes, we can probs keep memory more stable during long Editor sessions or when hot-reloading a lot.

[1] https://github.com/Singtaa/OneJS

After trying out Electron, Tauri, Dioxus, Flutter, and Wails, I’ve come to the conclusion that when it comes to desktop apps and UI, nothing really beats the combo of the JS ecosystem, Chromium, and V8. It's just very powerful and well-supported.

Experienced devs or teams can easily keep perf overhead to be under 15% compared to native. IMO it's a great trade-off for the amount of dev time you save.

That said, native still has its edge in:

- ultra-low input latency

- battery efficiency

- memory control (especially GPU)

Agreed. Maybe we're moving toward a world where LLMs do all the searching, and "websites" just turn into data-only endpoints made for AI to consume. That'll have other big implications... Interesting times ahead.

I'm pretty new in this, but a couple months back, I tried some direct AI code execution in Unity. It worked surprisingly well. Video: https://www.youtube.com/watch?v=0xCR4fiyugA

So I definitely think the value proposition of AI coding is higher when you have programmatical control over the workflow.

On a related note, the recent Cline Plan+Act function has also been a game changer.