I learned about kakoune from helix. I played with both of them to figure out which one I preferred and ended up choosing kakoune for simplicity. It’s a fantastic editor and my cfg is 50 LoC which is just fine for me.
As long as helix doesn’t add a plugin system I think both are superior to neovim. Neovim defaults are just awful. I hate that quickfix and loclist are so close to being useful for pickers but it just misses the mark and now there’s lock in on some terrible impl because we don’t want to break backwards compatibility. The select -> action model is superior.
Having an opinionated editor just makes so much sense. We don’t need 10 different picker implementations.
It’s not that it just makes mistakes but it also implements things in ways I don’t like or are not relevant to the business requirements or scope of the feature / project.
I end up replacing any saved time with QA and code review and I really don’t see how that’s going to change.
In my mind I see Claude as a better search engine that understands code well enough to find answers and gain understanding faster. That’s about it.
can you imagine two years in the future and still believe this will be true? You are just dragging your feet. You will give in sooner or later, and i would suggest sooner.
I use https://pipe.pico.sh for this use case. It’s a pubsub over ssh. It’s multicast so you can have multiple listeners on the same topic, and you can have it block or not block the event.
I do it myself and I'm sure a lot of people on HN do too. But I've tried to embrace the "zen" of closing all tabs lately and it's been nice. If I really want to find something later I can search my history or, like you said, just bookmark it.
I’m constantly using code agents to work on feature development and they are constantly getting things wrong. They can refactor high level concepts but I have to nudge them to think about the proper abstractions. I don’t see how a multiagent flow could handle those interactions. The bus factor is 1, me.
Try building review skills based on how you review. I built one recently based on how I review some of the concurrent backend stuff one of our tools does. I have it auto-run on every PR. It's great, it catches tons of stuff, and ranks the issues by severity. Over 10 reviews, only 1 false positive (hallucination) and several critical catches. I wish I'd set it up sooner.
Can also after those sessions where they get stuff wrong, ask for an analysis of what it got wrong that session, and produce a ranked list. I just started that and wow, it comes up with pretty solid lists. I'm not sure if its sustainable to simply consolidate and prune it, but maybe it is?
I just looked this up so might not be fully accurate but it seems most private sector “engineers” don’t require a license. You only need a PE license when providing a service to the public. That is quite a strict band on the title.
Might also be different between countries. But a bridge wouldn't be built without an engineer signing off on it being safe. A process change at a production facility would need an engineer to approve that the output still will follow specs etc
React was originally meant to be the 'V' in MVC. You can still use it that way and React becomes very simple when you only use it for UI. Why do data fetching in a React component?
Rails 8 is surprisingly good nowadays. It absolutely still has its share of problems (e.g. Bundler being slow, the frontend story being crappy without Inertia, lack of types which is a biggie, memory) but it is still a fantastic framework imo.
Why Inertia.js? I quite enjoy not using JS heavy frontends in Rails by leaning on Turbo and light Stimulus JS controllers where needed. My experience going hard into Vue+Rails was full of pain and I've rediscovered why server first makes everything easier to reason about instead of duplicating tons of logic + dealing with constant async issues (particularly around automated testing and complex data loading).
Inertia because it’s a plug-in replacement for ruby html templating aka erb. Try it out, it’s basically the same stuff you get from erb, without the need for Turbo’s web sockets. You get server side rendering, all the great BE stuff like server side validation, but no SPA headache.
I find the best DX with Adonis/nodejs and typescript.
I miss Rails so much when working with any of the top JS frameworks.
Every time I run into an issue that Rails had a standardized solution for a decade ago just proves that most of the JS world spends their days metaphorically digging holes with sharp sticks, rather than using the appropriate tool.
But the industry values overpaying stick-diggers over results, therefore I gotta play along…
Shilling a bit but maybe check out wasp.sh, we are conceptually very similar to "Rails for JS"! Just don't tell Claude to completely copy us hehe (pls)
Nothing personal and I wish you the best of luck with wasp.sh, but the constant churn of new libraries that will revolutionize JS development, but are never quite finished and are eventually abandoned in a semi functional state is exhausting and exactly the main issue I have with the JS ecosystem in general.
At this point, I'm convinced there's a secret global conspiracy to prank JS developers. For example 1 person maintaining 3 similar-but-distinct decimal libraries for Javascript, or the top 3 PDF processing libraries silently producing blank outputs.
I get that people like but I really cannot stand most of the decisions it made. The worst of all is auto imports which every language has rejected: https://bower.sh/on-autoloading
Rails powers nearly 15 percent of the US e-commerce. I love it. Any time I have to use another framework it feels like a huge downgrade. Rails has so many things that make it nice to use
It's terribly painful to go and have to import everything you want to use when you want to use the Elixir console. That alone makes it not worth it to me.
You can find specialized roles than Rails and usually more experienced (understandably) but most companies would be really open if you told them you have a Rails background but want to learn Elixir.
The pool size is less, but the pay is more (depending on your demographics, experience, etc) in my personal experience.
But, honestly I chose it not for the market, it's just a better programming language to build stuff, period.
The basic premise of Next is good, but it definitely has more overhead that in should, has odd "middleware", and is very hard to optimize. I view this mostly as a React problem though since any page requires full hydration and ships everything to the client. RSCs are... not my favorite for sure.
I too have been very frustrated by this, and I made an "Astro for dynamic sites" TypeScript framework called Hyperspan ( https://www.hyperspan.dev ) that aims to fill the gap in the JS ecosystem for a modern fully dynamic option that, similar to Astro, makes dynamic islands easy. I have enjoyed using it in all my own projects. Check it out if you want.
RSC by design does not ship everything to the client. That's one of its basic premises. It ships markup, composed in client interactivity, but you can shed a lot of the code required curate that markup.
I obviously meant traditional React components, not RSC. RSC can eliminate some client code, but they can be very awkward to use in practice, and lines between server and client get blurry really fast. The mental model is difficult for many to fully grok. I say this as someone who has lead engineering teams with folks of varying skill levels. RSCs are not worth the extra complexity and mental overhead they bring.
Switch to a rival service that doesn't have an outage. There are at least half a dozen competent hosted LLM vendors for coding now (Anthropic, OpenAI, Gemini, Mistral, Kimi, MiniMax, Qwen, ...)
reply