ww520

I don’t find the lack of built-in interface in Zig to be a big problem. Yes. It has some boilerplates to roll in by hand, but all of the work are confined in the interface and only required to be done once.

The benefits of the language outweigh the minor inconvenience.

Function name in camel case. Variable and parameter in snake case.

You get back an interface object at the end anyway. Why force the implementation to produce it? And if you have a type implementing 5 different interfaces, like one for Comparable, one for Iteratible, etc., do you want to stick 5 interface constructors in the implementation?

I did it this way so that the implementation doesn't need to know about the interface at all. The programmers can string the interface and implementation together with,

  const intf = interface.implBy(implementation)

This makes it possible to write an interface against any implementation objects. E.g. I can write an interface against the standard hashmap's get() and put() methods. Why would I do that? Let's say I have my custom hashmap with get() and put(), but I want to use the standard hashmap as fallback. A common interface working against my custom hashmap and the standard hashamp is possible.

Yes. You're right. It's not the typical C++ vtable.

I wrote a second blog for the C++ style vtable. https://williamw520.github.io/2025/07/17/memory-efficient-zi...

The first version is faster (one pointer indirection) with more memory consumed. The second version is more memory efficient sharing a single vtable for all instances, a bit slower (two pointer indirections).

Ah. The birth era of creative accounting. I remember companies shipped empty CD and booked it as revenue for the quarter. The actual software when ready was delivered as a “patch”.

Yes. I’ve loaded game buying whenever Epic has a free promotion.

Effect system allows programmers to annotate expressions that can have certain effects, just like the type system annotating type information on them, so compilers can enforce effect rules just like enforcing type rules.

For example for a type system,

  let a: Int      // this says 'a' has the type Int
  a = 5           // compiler allows, as both 'a' and 5 are of Int.
  a = 5.1         // disallowed, as 'a' and 5.1 are of different types.

Similarly for example for an effect system,

  let a: Int
  let b: Int!Div0 // 'b' is of type Int and the Div0 effect.
  let c: Int
  ...
  a = 1 / c       // disallowed, as '/' causes the Div0 effect which 'a' not supported
  b = 1 / c       // allowed, as both '/' and 'b' support the Div0 effect.

The effect annotations can be applied to a function just like the type annotations. Callers of the function need to anticipate (or handle) the effect. E.g. let's say the above code is wrapped in a function 'compute1(..) Int!Div0', a caller calling it can do.

  compute1(..) on effect(Div0) {
     // handle the Div0 effect.
  }

They're most likely just scapegoats for entities surrounding the area who won't give land for a proper construction.

I don't know what's going on in Mozilla. Just today on my security camera NVR, Firefox pops up a dialog in the notification area at the lower right screen of Windows 11, showing an ad for its vertical tab feature, urging me to try it out. The thing is Firefox is rarely used on the NVR and the browser is not running. The only program running is the camera video app (the popup of course obscured the video window). It must be done by the background Firefox Update process. This is a brazen abuse of the notification area that even Microsoft hasn't tried yet.

This is awesome. It's actually pretty quick. Major kudos.

> But that server is faulty!! If it has to handle multiple requests at once, it starts to break down. So, we decide to make our server's life easier by trying to ensure, from the client, that it doesn't ever have to handle more than one request at once

Used to just be a dash, like re-elect. Cooperate was co-operate. People got tired of writing dashes and they got shortened.

If I were asked this question, the first thing I said would be this is a poorly designed architecture. Client is the poor place to do throttling by itself. It has no information on the aggregated load of the system. It makes assumption that leads to complicate code in the sample code. There're more robust and better ways to do flow control and throttling.

It's not a functor; "map" is bind. Here's an example in non-Haskell as I was addressing non-Haskell audience.

  class Maybe {
    value: int;

    static wrap(v: int) { 
        return new Maybe { value = v } 
    }

    // map() applies fn on the unwrapped value. fn returns a Maybe. 
    map(fn: (x: int) => Maybe) {
        return this.value == null ? Maybe.wrap(null) : fn(this.value);
    }
  }

Here Maybe.wrap() is "unit" and Maybe.map() is "bind" in Haskell lingo. The whole thing is a monad. You can chain call with it.

  Maybe.wrap(5)
       .map(x => Maybe.wrap(x + 1))
       .map(x => Maybe.wrap(x * 2))

Nice video. I especially like the new 'labeled switch' feature providing a freeform control flow, and the watch/incremental compile feature. I used to use Rust's watchexec to do zig build on changes; now the watch feature is built natively in zig. The IO based async/await stuff seems to be the right direction; it's following the familiar Allocator pattern. The integrated fuzz testing into the compiler tool chain is fantastic; I can write much less unit tests now.

Zig.day looks like a wonderful way to do laid back hackathons. Looking forward to one coming up.

That's excellent! Thanks for the changes.

One issue I have with the old reader/writer pattern is that it is not easy to store them in a struct. Reader and writer are passed into a function as 'anytype' which implements any of the read() or write() functions. Often time in a struct's init() function, I want to take in a reader/writer and store it for later use. It's close to impossible since I don't know what type of the field of the struct to store them.

Does the new change make it easier to store reader/writer in a struct?

Here is an analogy. List is a container whose elements can be any type. There are general operations applying to a list, e.g. map, reduce, filter, find, etc. Any data type (int, float, or bool) of list elements can use these same operations regardless.

It’s similar for monad. If you can provide a unit constructor to turn an object value into a monad value and a “map” operation that unwraps a monad value, applies a function to it, and wraps the result, you have monadized the object type. Your objects can participate in any algorithm operates on monads.

The monad algorithms are the same. The only things different are the unit constructor and the mapping function.

Sounds like great timing. See if it can help.

Nice. Didn't realize zig build has --watch and -fincremental added. I was mostly using "watchexec -e zig zig build" for recompile on file changes.

The idea is not completely without merit. In gravity less environment, you can have much bigger and much thinner structure possible than on Earth.

Also the radiated heat from the Sun won't have much effect if the heat sink panels are facing perpendicular to the sun with two sides pointing sideway to deep space to radiate away the heat.

The Behringer X32 is a rare product that is designed well and built well. The digital aspect, the analog aspect, the user interface (hardware and software), the layout, the speed, the remote control feature, all work very well together. By using it I got the impression that it's built by hackers. It's good to know it's powered by Linux.

Not just employment contracts, some companies require NDA just for interviews.

Salary history of public employees.

https://transparentcalifornia.com/salaries/search/?q=Joseph+...

Is comptime slowness really an issue? I'm building a JSON-RPC library and heavily relying on comptime to be able to dispatch a JSON request to arbitrary function. Due to strict static typing, there's no way to dynamically dispatch to a function with arbitrary parameters in runtime. The only way I found was figuring the function type mapping during compile time using comptime. I'm sure it will blow up the code size with additional copies of the comptimed code with each arbitrary function.

I use a 10-year old laptop to run a local LLM. The time between prompts are 10-30 seconds. Not for speedy interactive usage.

> I kept going because I wanted to understand the BEAM properly. There’s value in following the real logic, not just the surface explanations.

Teaching is the best way to learn. I found that out when I started tutoring classmates for math in high school.

Same thing with writing a book. Something about learning a subject and turning around to speak/write out about it that really crystallizes the in-depth understanding beneath the surface.

I use LLM as a super Stackoverflow. So far it has been helpful. For code gen, 8 out of 10 cases, the code won't compile and need fixing. LLM did help a lot in learning new topics. Gemini did help tremendously recently in pointing out a new approach to a problem I was stumped on. Though the code it generated was garbage, the code did provide insight on a new approach which I adopted to make it work eventually.

Really don’t need an electrician. Just plug in to an outlet on the wall or an extension power strip. Don’t need a plumber as well. It’s really easy to install.