laserbeam

There are plenty of libraries out there which require users to do an init() call of some sorts at startup. It is perfectly possible to design a library that only works with 1 io instance and gets it at init(). Whether people like or want that… I have no clue.

Yes. You can always use the blocking syscalls your OS provides and ignore the Io system for stuff like that. No idea how they’d do that by default in the stdlib, but it will definitely be possible.

> If anything, it would make sense to me to have IO contain an allocator too. Allocation is a kind of IO too.

Io in zig is for “things that can block execution”. Things that could semantically cause a yield of any kind. Allocation is not one of those things.

Also, it’s perfectly reasonable and sometimes desireable to have 13 different allocators in your program at once. Short lived ones, long lived ones, temporary allocations, super specific allocators to optimize some areas of your game…

There are fewer reasons to want 2 different strategies to handle concurrency at the same time in your program as they could end up deadlocking on each other. Sure, you may want one in debug builds, another in release, another when running tests, but there are much fewer usecases of them running side by side.

At some points in life I spent several weeks with my therapist and one session with a psychiatrist exploring whether I have ADHD. Turns out I don’t. It was an important journey in my past, not because it determined that brain is “normal”, but because I learned a lot about myself.

Every single self diagnostic tool I have looked at in that period would have screwed me over. I would have misdiagnosed myself.

I second everything in this comment. If you think you have ADHD, explore the topic with professionals. Your own biases can trap you with internet apps.

I am VERY confident you guys have everything I mentioned either half working or coming shortly, so I'm not worried. I just saw a "the debugger is here!" announcement, then read the announcement, and saw what's still under todo... My reaction is "well, it's not here, it'll be here in a few weeks". And that's ok ^.^

Am impressed by the under-the-hood discussion though. Keep up the great work!

Oh yeah, of course :). My argument is they're just premature in declaring readiness.

Zed was the first editor that tempted me into using AI features. It felt solid in general and AI feels mostly like autocomplete in other editors (in terms of how much it's in your face). There's definitely a place for AI models and agents in code editors, and Zed makes me feel like it's not built around them, which is great! Zed feel like "Come to us, we are making a good fast editor that also has AI." while competition feel like "Come to us, we want AI that has an editor".

I'm very happy to see work on the debugger. This is the main feature preventing me from switching full time to zed.

Unfortunately, "here" is not accurate. Not having a watch window, a stack trace view, and no mention of data breakpoints in the announcement still keeps the "beta" tag. I know those features will arrive eventually, but what is described is definitely not sufficient for 97% of my debugging sessions.

I would also have liked to see more in the announcement of multiple simultaneous debug sessions, and on how multithreaded debugging is planned. There are really cool things that can be done with multithreaded debugging further down the line that I'd be interesting in hearing about (like how RemedyBG has a DAW-like UI for freezing certain threads, or hitting one button to "solo" a thread and freeze all others).

It’s not “mistakes”, it’s fashion. The cool thing about fashion is you can never run out of innovation. If something has been out of fashion for 15 years you can bring it back! It makes it seem like everything is forever changing and new. I’ll bet your ass that material design will be all the rave in 10-15 years or so.

Agreed. The previous article made me think “this tool is probably more potent than I thought and I should give it a try”. It did not make me drop my concerns about AI in general.

The correct way to recommend to the scientifically inclined to learn about breathwork “without the woo woo” is to point to a meta analysis. The first one I found suggests that yeah, breathwork can lead to lower stress but that most studies feel biased and can overhype most other benefits.

https://www.researchgate.net/publication/366645304_Effect_of...

To me, breathwork falls under that category of positive exercises that can give a boost in life. I would never overhype “the power of breathwork” to anyone. Just like going to the gym, yoga, dancing, and most other similar activities.

> The header formats are meant to be very simple key/value pairs that are known by the parser, and not free-form bits of metadata. That's what the "meta" blocks are for.

One more thing you should prepare for whenever you have "free-form bits of metadata". They somehow turn into: "some user was storing 100MB blobs in there, and that broke our other thing".

> 1. Compatibility is a key factor here, so we'd want to go with base-level JSON. I'd prefer being able to have trailing commas in lists, but not enough to make life hard for someone implementing this without access to a JSON5 parser.

This is what I was referring to. This is not json:

> #..meta: format=json, length=270

> The header formats are meant to be very simple key/value pairs that are known by the parser, and not free-form bits of metadata. That's what the "meta" blocks are for. The parsing rules for the header are intentionally very simple.

Exactly my point. That level of flexibility for a .patch format to support another language embedded in it is overwhelming. Keep in mind that you are proposing a textual format, not a binary format. So people will use 3rd party text parsing tools to play with it. And having 2 distinct languages in there makes that annoying and a pain.

TIL these are a thing. Thanks! (Just a regular joe on the internet, not the author)

I really don’t like the highly hierarchical format, that there’s a “..meta” and a “…meta” somewhere else. I can imagine we want to annotate the whole diff, each file and each chunk. That’s a total of 3 levels of depth. Let’s just give them distinct names and not go full yaml with a format for once?

This helps with readability (if one of the “meta” blocks is missing, for example, I could still tell at a glance what it refers to without counting dots), and is less error prone (it make little sense to me why the metadata associated with a whole diff should have the same fields as the metadata of a file).

Furthermore, why do we have two formats? Json and key=value pairs? Is there any reason to not just use one format because it sounds like the number of things we’d want to annotate is quite small. Having a single structure makes it much easier to write parsers or integrate with existing tooling (grep, sed or jq - but not both at once)

Other notes:

- please allow trailing commas in lists

- diffs are inherently splittable. I can grab half of a diff and apply it. How does your format influence that? I guess it breaks because I would need to copy the preamble, then skip 20 lines, then copy the block I need?

- revisions are a file property? Not a commit checksum? (I might just be dumb here)

The statistic is actually wrong, I misremembered. It is from Tantacrul, a designer overseeing the current design of MuseScore and the redesign of Audacity. It's a finding he had while working at microsoft on a revamped version of MS Paint (the man has since moved to greener pastures).

The actual moment is a few minutes into the section about shortcuts (of a long video trashing a piece of discontinued music software). The actual bit was that undo/redo was the most clicked button in the MS Paint interface, and that people overwhelmingly prefer the button over the shortcut. No actual number is specified.

https://youtu.be/Yqaon6YHzaU?si=uDFFQgrbZuYFifhS&t=1580

The correct statistic (which I associated with the other example in my mind) was that only 17% of users use more than 20 shortcuts.

In my view, peak design is the "density" setting in Gmail where you could select between 3 degrees of density and wasted space in the UI.

Even though I like somewhat denser interfaces, I know that lots of whitespace is GREAT for new users. Just like I know everything needs to be in the UI (~80-90% of users click the undo button instead of typing Ctrl+Z in many apps). There has to be space for a learning curve for any interface.

The ability to make things denser is important, but high density is usually only relevant for power users. It should not be the benchmark by which a UI is judged.

EDIT: Actual ctrl+z statistic is inaccurate. Details included in a further comment.

> You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond.

The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.

There’s only 1 artifact. A static executable. No “need” for a package manager. If someone builds a package manager they would just need to compile the src and ship the executable.

All you need to do otherwise is add it in PATH.

I honestly felt the grime on my phone’s screen had more impact on my accuracy than anything else. Sometimes i’d just rotate my phone and instantly spot the difference after the disks moved.

I first found it hilarious that there are 9 authors for a 10 person experiment, but I double checked.

There are multiple experiments with 82 total participants. One of those experiments does indeed have a sample size of 10.

Yup, this is still “wait and see”. For these kinds of papers my stance is: “cool read, I won’t click the share button”.

The reason is: bots DO spam you repeatedly and increase your network costs. Humans don’t abuse the same way.

Yeah… was about to ask that. I just run Ollama on windows. What am I actually solving by running it virtualized in WSL?

Musky, tell me 5 things you did today at school.

Well, I invented a new name, sold it to myself and now people say I’m worth more money.

Anything productive, Musky?

No. Nothing else.

You're fired Musky!

My biggest problem with “zig build” is learning it. Mainly because it still changes from version to version, and having a clear picture of what steps are and how they interact is somehow hard for me.

Obviously I will overcome this, but unlike zig itself, the build file still feels like guesswork to me.

I dare to say Word is so poorly designed that there are so many ways to screw up formatting... that bad behaviors (like right aligning text with spaces) are inevitable.

For 90% of documents, software like Word was a mistake and you should be using google docs level of detail or markdown or so. And for the rest you want publishing software, not Word :(.

The article doesn't go in detail about how they solve that. But that's the key problem they highlight as being solved. It's a product which manages multiple cameras for events, and color correction is one of those "obvious in hindsight" problems to be solved.

Of course! Of course you have to do color correction on all the different cameras pointed from different angles at a sports event.

I absolutely love reading about hard problems that are invisible to most people.

Aren’t perovskites incredibly fragile? I thought the reason they aren’t used in solar panels is because they only last a couple years. Why should I believe LEDs made out if the same stuff would survive the test of time?

I've read the first 2 paragraphs 5 times and I still can't tell if Microsoft was renting datacenters and paying for them, or if Microsoft was leasing out datacenters and decided "no more AI data centers for you, 3rd parties".

And digging further into the article didn't help either.