rlp

9am to 9pm 6 days a week

This is my exact experience. TypeScript seemed to hit a complexity sweet spot about 5 years ago, then they just kept adding more obscure stuff to the type system. I find that understanding TypeScript compiler errors can be almost as difficult as understanding C++ template errors at times.

This is no longer remotely true. Most .NET teams I know now deploy on Linux and develop on Windows/Mac/Linux.

Wow. I just had it write a song about being sad about losing my keys in r&b/soul style, I'm totally blown away:

https://www.udio.com/songs/bDY5CYdJZP93AdpgpfBJNX

I'm not seeing a major problem here, you just need to install MSVC++ alongside it.

I've always been a big proponent of TypeScript, but does anyone else feel like the type system has gotten a bit too flexible? I recently had to fix some errors when upgrading packages on an old project, and it was not at all clear what was wrong by just reading the compiler output. For some errors, there were like 5-10 lines of confusing info/context, it felt like trying to understand the errors reported in template-heavy C++.

Maybe libuv? It's used by node and julia. It's not a full standard library by any means, but it would give you the event loop with async/networking/io/threading.

Sarno's work comes up periodically on HN, and I always have to chime in to say that it cured my RSI. Everything is still completely, 100% cured at 15+ years. As a developer, I have no idea what I would have done without it, my career would have been over. Here are my previous comments:

From 2016: https://news.ycombinator.com/item?id=12990976

From 2021: https://news.ycombinator.com/item?id=26120633

No need for a meditation myth at all, absolutely. It's brain hacking as far as I'm concerned.

As for concentration training vs mindfulness meditation, I do think there's a difference. Concentration is a tight single-pointed focus, while mindfulness is a broad focus on the present moment. I found mindfulness meditation basically impossible without practicing concentration meditation extensively first, my mind was too overactive to settle in the present without an anchor to focus on.

It's about training your mind's executive control/function. You learn to focus on one thing and allow others to pass through your awareness without them being overly distracting/disturbing.

Think of your focus like a spotlight. Most people have very little control over their spotlight and it gets aimed at whatever is the latest thing to enter their awareness: a thought, a sound, another thought, a visual, etc. It's bouncing all around, all the time. A proficient meditator can more effectively control where the spotlight points. Over time, as the mind slowly learns to do this better, the stuff outside the spotlight fades and become less intrusive. This leads to increasing states of calm and peacefulness which extend even after the meditation session ends.

Beautiful Racket is quite nice: https://beautifulracket.com/

Also, WebAssembly can't support most GC runtimes now, because you can't scan the stack for roots. You can keep your own shadow stack on the heap, but that has a bunch of pretty bad performance implications. This actually impacts C/C++/Rust codegen as well, since they can't create references/pointers to anything on the stack, and have to build their own shadow stack (I think this is done in binaryen or LLVM itself?). I understand it's a security thing to disallow direct stack access, but most languages and runtimes expect it.

Anyways, that's why there needs to be support in WebAssembly for GC, because there needs to be a safe way to walk the stack (aside from the obvious JS interop considerations).

I had to turn off uBlock.

FedEx maybe. UPS is unionized, I think they pay a fair wage.

Very cool! I'd love to see proper macros in a major language like Dart. And the proposal looks good, like a mix of Scala and Nemerle.

Any particular reason you like Dart so much? I tried it briefly, and it felt like a watered-down mashup of Java and C# with somewhat worse performance.

It highly depends on the use case. When people interact with a piece of software all day every day, they tend to appreciate having more information/actions available at a glance. Simple interfaces are better for casual users, but they generally mean more clicking around and tend to be slower to use for experts.

The property owner should not be responsible for answering that question.

There's a Cranelift backend, which is apparently faster at creating debug builds than LLVM: https://github.com/bjorn3/rustc_codegen_cranelift

That's great! Like you, it did take me a while to get to 100%. Old habits die hard, I guess. You really know you're there when you realize you forgot to think about RSI for a whole week/month/whatever.

I totally agree, the prevailing RSI advice about posture and exercise and fancy chairs and input devices and taking breaks is not one-size-fits-all. In my case, Sarno's book showed me how my neurotic fixation on RSI was making it worse.

I wrote this comment in 2016: https://news.ycombinator.com/item?id=12990976. My RSI continues to be totally gone (it's been gone 14+ years now, the RSI started a couple years before that), and I never even think about it anymore.

If you have RSI and you are reading this, please try to keep an open mind. Not all cases are the same, and fixating on/worrying about the RSI constantly is not necessarily the best path forward.

Making Blob Opera with David Li: https://www.youtube.com/watch?v=ZfLYuXi6sDI

https://arewegameyet.rs/

Rust is not really there yet for game development, in my opinion. Amethyst is probably the most advanced 3D engine at the moment, but they are having some issues with picking an ECS implementation, and it's still very young.

There are a few 2D engines, but they are also not particularly mature either. Coffee looks interesting, although I haven't tried it.

For something lower-level, there's gfx.rs (Amethyst uses this), which is quite impressive. gfx-hal is quite nice for abstracting over DirectX/Vulkan/OpenGL/Metal/etc.

I have a fair bit of Rust experience, and I agree that it adds a lot of cognitive overhead. It gets better over time as you learn how to appease the compiler, but the borrow checker can still be a pain in the ass. It's something you're constantly aware of, taking up space in your brain.

I can understand the move from C or C++ to Rust, the safety guarantees can be compelling. And it does feel like a much more modern language. However, if something with GC like C# can get the job done, I'd choose that every time over Rust.

HotSpot uses a JIT compiler that dynamically recompiles code at runtime to speed up hot code paths. GraalVM native compilation cannot do this, and given the nature of Java's non-reified generics, it's very hard to get equivalent speeds at runtime. Profile-guided optimization is the only hope to recover some of that performance gap, and it's currently only available in GraalVM EE. I'm not sure how the benchmarks compare to HotSpot.

This is really cool, but I've always been disappointed that you can't generate Houdini procedural content in UE4 at runtime. It only works in the editor.

Yes, it's aware of the previous frame. I believe I used some kind of motion "heat map" that would indicate where the changes were needed based on accumulated deltas that would gradually decay. However, I still had to keep the brush strokes on a reasonably regular-ish grid to get enough paint brush coverage for real-time rendering. Also, if they were too randomly placed, the image jumped around too much.

Very nice! The sampling mask makes a big difference. I played around some with creating shaders in Unity for this type of thing last year. I liked how it looked on still frames, but I was never quite satisfied with the results for movement.

Increased sales of a competing medication, like Remdesivir.

Include doesn't work for cyclic types, they need to be in the same "type" block. I do not agree with Araq's stance here, there are often cases when closely-related types need to reference each other, and it's not always convenient to put them in the same file. That's why you see the "types.nim" file in larger Nim projects -- no one has a good solution and just shoves them all together. And, if you use types.nim, you no longer have proper visibility control, since fields cannot be private and there is no package-level visibility. Most languages understand this, C/C++/Rust all allow at least the ability to forward declare a type (and Rust allows cyclic, out-of-order types).