HN user

lpghatguy

395 karma

not just computers but also other things

Posts1
Comments88
View on HN
Returning to Zig 18 days ago

I find it frustrating when people talk about memory safety as “a spectrum.” Yes, there are safer patterns in unsafe languages, but at the end of the day, not having memory safety as a category of bug _period_ is such a nice baseline level to work from!

If you hit a weird state in your program and it can _never_ be caused by memory corruption, you rule out a big bug space and no longer need to check the entire scope of your program. It’s similar to Rust’s unsafe blocks — it doesn’t really matter if they’re “more unsafe” than Zig because in Zig the scope of the unsafe is your entire program! Local reasoning is a huge part of what you buy into and I could never give that up if I didn’t have to.

Take care here though, because shaders are almost always working in linear sRGB colors, while color codes are almost always defined in gamma-encoded sRGB.

This property makes it mildly annoying to copy color constants between different contexts.

I bought the same keyboard when I was a teenager as my first "real" keyboard!

These days I have a ZSA Moonlander. I adore it! I love how easy it is to program it without any software installed and it's been phenomenal to customize it to fit me perfectly.

I just changed all the switches out (in order to be quieter than my stock Cherry MX Brown switches) and replaced them with a set of Gazzew U4 switches. I'm _shocked_ at how far mechanical switches have come along since the days of Cherry dominance. They're super quiet and still have an awesome tactile feel!

In my career, I've found that this problem crops up the most when a team is unable to make impactful changes to a system that they depend on. It's so much easier (and requires less collaboration and fewer approvals!) to build an abstraction over some core system than to actually fix the core system, even if fixing the core system is always the better choice.

I was very guilty of this as a young go-getter engineer! Why try to convince another team that something should be fixed if I can just paper over it?

Years ago, I introduced Flow gradual typing (JS) to a team. It has explicit annotations for type variance which came up when building bindings to JS libraries, especially in the early days.

I had a loose grasp on variance then, didn't teach it well, and the team didn't understand it either. Among other things, it made even very early and unsound TypeScript pretty attractive just because we didn't have to annotate type variance!

I'm happy with Rust's solution here! Lifetimes and Fn types (especially together) seem to be the main place where variance comes up as a concept that you have to explicitly think about.

I've long felt that I am face blind. I took the face blindness test with my girlfriend.

I scored right in the middle, but she scored better than nine out of every ten people. How about that!

Once upon a time, Flash, Java, Silverlight, ActiveX, etc. ruled the web.

I think the world is _much_ better off today, with a common language and platform. I don't think those big third party runtimes could survive in the browser in today's threat environment.

You might be getting “sampled textures in a single call” with “total textures loaded” mixed up. Sampled texture limits affect complexity of your shader and have nothing to do with loading content from elsewhere.

The CPU-specific intrinsic stabilized a little while ago for cases where you need SIMD on a specific platform at least. A lot of crates like glam seem to only support SIMD on x86/x86-64 for that reason.

I know that `wide`, `faster`, and `simdeez` are options for crates to do cross-platform SIMD in safe Rust. Eventually we'll have `std::simd`, but I don't know what the timeline is or what the blockers are.

This has nothing to do with scrolling. They're fixed CSS rules. They remind me of the tricks we used to have to use for vertically centering things.

It seems like these rules are from the site's page load animation. You can see it if you refresh the page part way down. It's not a great way to achieve that effect.

There's nothing on this site using calc as part of scrolling the content. It looks like the background image is fixed in place with some JS, which is probably the source of the performance issues.

The questionable stuff is definitely that everything is a table and that the links on the bottom of the page are divs with onclick handlers... and that selection is turned off?

There are lots of places, including many national forests, where you can cut your own firewood for free.

If you live near the Flathead National Forest in Montana in the US, for example, you can cut firewood for a campsite without a permit. You can also get a free permit that allows you to cut 4 to 12 cords of wood per adult per year.

I don't know anything about firewood laws in Sweden or the rest of Europe. From first glance they look quite a bit more restrictive.

Containers are not a great solution for programs that need graphics drivers (games) or quick startup times (command line tools).

I've been wrestling with glibc versioning issues lately and it has been incredibly painful. All of my projects are either games or CLI tools for games, which means that "just use a snap/flatpak/appimage" is not a solution.

New JS frameworks always make for compelling hello world examples.

Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty!

As an example of this point, check out the "Simple Todos" example for Solid.js[1].

In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language.

I've been writing React and React-alike code for a long time. I think that fine-grained updates avoiding reconciliation are a good idea, especially for performance. At one point, I built a React-like library for Roblox and Lua whose most novel feature ended up being "Bindings"[2], which look sorta like Solid.js state containers. They create little hot-path data dependencies, but the bulk of your components still use normal React-like rendering.

  [1]: https://www.solidjs.com/examples/todos
  [2]: https://roblox.github.io/roact/advanced/bindings-and-refs/

Compare this to the error message you get from Rust with the same program though:

  error[E0277]: cannot add `[{integer}; 2]` to `{integer}`
   --> src/main.rs:2:7
    |
  2 |     1 + [2, 3]
    |       ^ no implementation for `{integer} + [{integer}; 2]`
    |
    = help: the trait `Add<[{integer}; 2]>` is not implemented for `{integer}`
  
  For more information about this error, try `rustc --explain E0277`.
Good error messages are important for adoption of languages with strong type systems. The complexity is already foreign enough for people who aren't familiar with type theory.

This is a problem I've always had with Mermaid too. Custom theming is a no-go; it's easier to make attractive diagrams with GraphViz.

I remember the docs for Mermaid.js talk about varying document trust levels, which is not something I want involved in a diagramming DSL.

C++ is not nearly as productive a language for most programmers in the world as JavaScript. Qt is not a panacea, even for desktop apps. The condescending tone to web developers is very strange and not very nice.

I visited the USAF Museum earlier this year. It's breathtaking just how large the B-2 Spirit is. You can know the plane's dimensions going in and it'll still blow you away standing next to one.