I mean, it'd be good if these tools followed the xdg base spec and put their config in `~/.config/claude` e.t.c instead of `~/.claude`.
It's one of my biggest pet peeves with a lot of these tools (now admittedly a lot of them have a config env var to override, but it'd be nice if they just did the right thing automatically).
I feel like there is a commonly mentioned idea that "speaking a foreign language is easier after having a drink or two".
I've found that especially true with Mandarin because (I think) a beginner speaker is more likely to speak a little more quickly which allows the listener to essentially ignore the occasional incorrect or slightly mispronounced tone and understand the what theyî're trying to say.
(This is anecdotal, but with n>1. Discussed and observed with other Mandarin language learners)
I think it makes sense, both for this, and for curl.
Presumably people want this for some kind of prestige, so they can put it on their CV (contributed to ghostty/submitted security issue to curl).
If we change that equation to have them think "wait, if I do this, then when employers Google me they'll see a blog post saying I'm incompetent" changes calculation that is neutral/positive for if their slop gets accepted to negative/positive.
If I can make it clean and decent I will. I might look at again after work and see if I can tune it up. It was a bit flake and I wasn't blown away by the interaction.
I'm not super experienced with zig, but I always think that in the same way that rust forces you to think about ownership (by having the borrow checker - note: I think of this as a good thing personally) zig makes you think upfront about your allocation (by making everything that can allocate take an allocator argument.).
It makes everything very explicit, and you can always _see_ where your allocations are happening in a way that you can't (as easily, or as obviously - imo) in rust.
It seems like something I quite like. I'm looking forward to rust getting an effects system/allocator api to help a little more with that side of things.
Yep, rust forces you to think about lifetimes. Zig only suggests it (because you're forced to think about allocation, which makes you naturally think about the lifetime usually) but does not help you with it/ensure correctness.
It's still nice sometimes to ensure that you have to think about allocation everywhere, and can change the allocation strategy for something that works for your usecase. (hence why I'm looking forward to the allocator api in rust to get the best of both worlds).
That's true and I liked the idea of it until I started writing some Zig where I needed to work with strings. Very painful. I'm sure you typically get a bit faster string manipulation code than what you'd get with Rust but I don't think it's worth the cost (Rust is pretty fast already).
Having worked with c++ strings and also string views I find zigs simple fat pointer to be fairly direct and straightforward, and a bit refreshing. Ownership is being coupled in with the type..
Can't agree more. I hope someone puts some work into a less painful way to manage strings in std. I would but I don't manipulate strings quite enough to support usecases more than basically concatenation...
As of 0.15.X, you can build strings using a std.Io.Writer. You can either:
- use std.Io.Writer.fixed to use a slice for the memory, and use .buffered() when you're done to get the subslice of the buffer that contains your string
or
- Create an instance of std.Io.Writer.Allocating with an allocator, and use .toOwnedSlice() when you're done to get your allocated string.
In both cases you just use regular print functions to build your string.
Depending on your needs, it may also be good to use a fixed writer with a dynamically allocated slice, where the size of the allocation is computed using std.fmt.count(). This can be better than using std.Io.Writer.Allocating because you can avoid doing multiple allocations.
I am pretty sure we'll see Desktop Linux in the US cross the 10% mark this year... however, I don't think it will get much higher without first party sales support from OEMs. Most people don't change their OS and just use what came with it, which today is mostly Windows or MacOS.
I'd really love if some vendors would license Pop from System76 for more, broader hardware support. I think it's just about the best out of the box experience in Linux for most users.
Oh that's great! How did I not know about zapper?! (Usually on desktop I remove annoying things in inspector by just deleting the HTML element manually, but on mobile I usually just closed the site. Glad to have a nice solution now!)
Maybe this'll get wrapped into a nice tool later.
Does anyone have any recommendations?
reply