- > “Slow is smooth, smooth is fast.”
Such a great axiom.
I had a mentor/colleague give me a piece of advice that is somewhat related:
"People will remember the quality of your work far longer than the time it took".
I've found it to be true through my experience. I will admit though, I generally do not get tapped to do the quick hacks when in a pinch, but that's a feature, not a bug, in my opinion.
- ... and most of that money comes in the form of sponsored browser/search integration w/ their competitors.
In that set of circumstances, the main qualification for CEO is likely 'plays nice with Google'. Given that, I'm not surprised that Mozilla underperforms.
Beating Google in the browser market might be considered hostile to their sponsors.
- > One of my New Year's resolutions is to learn Neovim properly.
I'm decades in at this point and still learning. Just keep in mind you don't need to know everything before getting a massive benefit out of it.
My top features:
- Fingers do not leave the home row (only good if you are a touch typer, but if you aren't, do it, it is worth it)
- Terminal based (so you can use it over ssh when needed, or pipe data into it during scripting sessions)
- Starts fast
- Navigating and editing with text objects (though this took me a while to work into my workflow)
- Regular expressions w/ ex commands
- Filtering text with cli commands via ex
- Editable macros
If you haven't gone through `vimtutor`, I recommend that as an early step.
- Is the 'regex hater club' subtitle related to using regex to 'parse' rather than using something like tree-sitter that actually parses?
I also had a hard time understanding the context given just the link.
- Depends on the problem at hand.
Zig where I used to use C/Rust (but admittedly I spent the least time here).
Go where I used to use Java.
Bun/Node for typescript/javascript, where each is appropriate, but I favor Bun for standalone application programming and local scripting.
- Years ago, when I initially picked up Rust, I loved it. It does a lot of things right. At the same time, though, I knew there was a possibility of it going wrong in two opposite directions:
1. Developers balked at being required to take on the cognitive load required to allow GC-less memory management
2. Developers wore their ability to take on that cognitive load as a badge of honor, despite it not being in their best interest
I eventually came to the decision to stop developing in Rust, despite its popularity. It is really cool that its creators pulled it off. It was quite an achievement, given how different it was when it came out. I think that if I had to implement a critical library I would consider using Rust for it, but as a general programming language I want something that allows me to focus my mental facilities on the complexities of the actual problem domain, and I felt that it was too often too difficult to do that with Rust.
- There's a big part of me that agrees with your implied conclusion, that it shouldn't matter.
On the other hand, I've found that core decisions like language ecosystem choice can be a good leading indicator of other seemingly unrelated decisions.
When I see someone choose a tool that I think is extremely well suited for a purpose, it makes me curious to see what else we agree on.
The Oven team, the ones who created the Bun runtime, is a good example for me. I think Zig is probably the best compromise out there right now, for my sensibilities. The Oven folks, who chose to use Zig to implement Bun, _also_ made a lot of product decisions I really agree with.
- No experience with AVM, but Ubiquiti gear is at least a class above Netgear equipment.
- Pulling doesn't have to happen at the surface?
- I don't enough experience w/ Buildbot or Travis to comment on those, but Jenkins?
I get that it got the job done and was standard at one point, but every single Jenkins instance I've seen in the wild is a steaming pile of ... unpatched, unloved, liability. I've come to understand that it isn't necessarily Jenkins at fault, it's teams 'running' their own infrastructure as an afterthought, coupled with the risk of borking the setup at the 'wrong time', which is always. From my experience this pattern seems nearly universal.
Github actions definitely has its warts and missing features, but I'll take managed build services over Jenkins every time.
- Bun isn't based on V8, it's JavaScriptCore, but your point still stands.
- Same here, having a different version manager per language ecosystem got tiring due to the small differences.
I used asdf for a while but moved to mise-en-place (mise). Same reasons though, one tool manager for all the tools.
- I was hoping to see some corn smut.
- I think the idea that there was outrage about branch naming is manufactured.
It was more that the naming was potentially offensive and cost next to nothing to change.
The people griping about it are the ones outraged.
- I no longer run a Microsoft OS on any of the computers I own.
This type of behavior is the reason.
Linux is good enough for most everything I do, for the rest is MacOS.
- The reflog is the failsafe. It is the tool that fixes all the scary states, as it keeps a journal of the states of each ref in the repo (like branch heads).
You can see where you were and hard reset back, no matter what state you are in.
- > C++ is TypeScript for C
In what way?
Typescript is really just an optional type system for javascript. I don't see the analogy with C/C++.
- Zig feels like a better C with modern tooling. It is a tool that works for me.
Rust feels like a better C++ with modern tooling. I am a tool that works for it.
- I have no proof of this, but I would bet that there will be some quid-pro-quo involved between Trump and the pardonee. Trump does not usually give things away, he leverages his power to get more power/money.
- > Its interesting to me that Codex has such high sentiment.
Me too, so much so that I doubt this is legitimate. This blog post is the only place I've seen people 'raving' about codex.
Claude Code is the current standard all others are measured against.
- Seriously. It took more time to respond with disrespect than to just ignore it.
- > zero downsides
I just said that I have measured it being slower in at least some use cases.
JIT gains better when already compiled paths run repeatedly. Most long running programs embedding Lua will choose luajit for this reason.
I don't care what people use, the point is that JIT compilation isn't magic that makes everything faster. The way to know is measure.
- Yet I've witnessed Lua 5.1 launching faster than luajit for some of my use cases.
My point still stands though. Don't just use LuaJIT thinking it will magically make things faster in all cases. If you are embedding, LuaJIT is a no-brainer. If you are using a stand-alone interpreter, measure if you care about reality.
- You may want to benchmark lua versus luajit if you are writing scripts or other short-lived programs.
JIT-compiled languages aren't generally faster in starting up, they generally are used to speed up long-lived programs that have hot sections.
- Don't forget Fennel, if you are a Lisp lover!
- > Battery life is the result of getting details right at every level of the software stack
Exactly. Apple's way of doing things is about vertical integration of the stack, which is the polar opposite of how the PC market developed and largely still works.
The vertical integration approach (where you control all the layers beneath the customer facing product) has the benefit of allowing you to optimize that customer experience by tweaking things anywhere in the stack.
Power management in digital systems mostly comes down to being able to slow or turn off clocks when appropriate. Doing this well can be complicated, but you can tell that Apple has put a lot of energy into doing it.
The downside of the vertical integration approach is that components cannot be sourced or replaced with off-the-shelf components, as the interfaces are not really standard, they are tailor made for the use case.
For the Framework folks to pull off something like the M1's power sipping, they'd have to invest a lot of engineering time (a.k.a. money) and have strategic partnerships with hardware vendors and standards bodies to move the commodity chip market forward to support better power management.
The thing is, one of the strengths of the Framework is that the hardware is commodity, making their devices easy to repair. Also, any work that the Framework folks do to move things forward also benefit their competitors, which can shrink the potential reward for doing so.
- Unbounded greed will prevent you from enjoying the benefits of your life.
- I never aspired to be a generalist, but I have come to realize my process has made me into one.
If I had to generalize how I work, I'd say it comes down to:
1. Identify the highest value thing I can work on that is feasible
2. Learn what I need to finish the work. Invest as little time/effort as possible into topics that have not proven to be timeless. Lindy's Law is your guide here.
3. when the solution is good enough, go back to 1.
Being a generalist doesn't mean you aren't an expert in anything. There are topics that I've identified as being so timeless and high value that I've more time and effort into them than others (making me a relative expert, I guess).
For me, it is more about targeting the goals at hand and learning just what I need than setting out to master the tools I like. Over time you will become an expert in the tools you trust.
- > I love podman, and, like others have said here, it does not always work with every container.
Which is probably one of the motivations for the blog post. Compatibility will only be there once a large enough share of users use podman that it becomes something that is checked before publish.
If you are dumping AI slop on your team to sort through, you are creating drag on the entire team's efforts toward those positive outcomes.
As someone getting dumped upon, you probably should make the decision (in line with the objective to producing positive outcomes) to not waste your time weeding through that stuff.
Review everything else, make it clear that the mess is not reviewable, and communicate that upward if needed.