Not sure how you would define successful though. I built a Firefox addon almost entirely through vibe coding and I know at least 5 other random souls on the Internet who have used and thanked me for it. But it is by no stretch, if popularity or how much money it makes, are the measures.
I was trying to test the theory if it's even possible to release something production grade with vibe coding. Wrote about the experience here https://kau.sh/blog/container-traffic-control/
When you start to use Containers (feature the Author of the article talks about), you'll start to want a little more control in how the containers open especially for sites that you allow on more than one container
Most AI generated text doesn't seem to have spaces around the em dashes. I've been using that as a subtle distinguishing marker; as both forms are considered grammatically correct.
Huh, I've observed the opposite, AI-generated text uses spaces most of the time. Might depend on language? Style guides I use (like Chicago) don't put spaces between em dashes so those always stand out immediately to me.
having spent a lot of time on finding the right monospace fonts, one of the things i've noticed, that's particularly important in the context of coding is a visual symmetry.
some fonts individually have beautiful glyps or characters but when you preview them with blocks and blocks of code, there's a quirkiness that throws of that symmetry.
I bring this up because Google Sans Code, is super quirky; preview a few characters individually and they look good; put it all together in real code, and it's just not as smooth visually.
i don't have your skills of actually customizing or changing glyphs in fonts directly but i've customized and used scripts to fix glyph characters available as open type features. I've done this for fonts like:
it really is a sickness. a terrible sickness, if you care deeply about fonts. I know you don't care specifically about recommendations, but inevitably i've found myself gravitating to these fonts:
1. Berkeley Mono (paid)
2. SF Mono (walled)
3. Recursive (truly open and legible)
4. Commit Mono
I love the above fonts, but there's a few characters or quirks that drive me bananas on certain days, so inevitably find myself switching between them.
this makes sense and as usual great eye by Simon. progressive disclosure is such a powerful concept, that every other tool is going to start adopting it. we've personally had such great results adopting it, especially for performing high quality large migrations.
I wrote about this but I'm certain that eventually commands, MCPs etc will fade out when skills is understood and picked up by everyone
Fleet came at a time when intellij felt extremely bloated. iirc they had painted themselves into a corner where it was easier to rip the band aid and start anew.
Fleet was supposed to be that promised editor which was snappy and had the power of intellisense + all things we liked about Intellij editors ... but without the terrible glacial bloat. but in a stroke of bad luck and typical lack of focus from Jetbrains, Fleet just didn't get good enough quickly.
I say lack of focus because (like their multiple attempts at AI) Jetbrains also had a lite mode in the start but that didn't work great. then came Fleet. But it was not getting better quickly enough and they changed course to make Fleet their main cross platform editor ... but even that didn't take.
I really am worried for Jetbrains and intellij. In a world where even VScode is having its lunch eaten by Cursor, Jetbrains is quickly getting pushed out of the list of contenders. they've squandered away a lead they once had in a certain niche for code editors.
I personally only pull up Intellij these days when there's some platform specific tool that's built in (like the emulator in Android Studio) or certain Android specific profiling tools, or the debugger.
Otherwise I rarely find myself using Intellij. My usage has dropped precipitously.
Another example of their wonkiness with Fleet and focus was their whole "Kotlin Multiplaform stuff will be Fleet-first!" which they then (somewhat promptly) reversed to "actually it'll be IntelliJ/Android Studio first" ... and that's not even getting to the macOS-only aspect (also "at first").
Their matrix of features/capabilities across IDEs, platforms, plugins, etc is such a pitfall-happy maze to navigate.
I wrote an article (this morning actually!) on picking up Rust to combat AI brain atrophy. My background is JVM-based (Kotlin), and my main contenders were Go vs Rust vs Zig.
My reasoning for settling on Rust:
If I wanted something more general-purpose and ergonomic, I'd stick with something like Kotlin, which has wider ecosystem support. Go could fit here too, but I've heard from more experienced folks that Go's simplicity can get limiting as codebases grow (and requires 100s of developers to be disciplined). Not impossible, just not as conducive.
But since I specifically wanted a performant systems language, I figured I'd go to the other extreme. So my choice was Rust or Zig. I eventually chose Rust (as complicated as Rust can seem) the borrow checker is pretty elegant once it clicks and provides the necessary safety net for a language I intentionally am choosing for more control.
1 - compromised hardware over better software is a trade-off you're willing to make and
2 - you believe that the Framework software experience is better than macOS
i can concede 2 (if true, I've not used a Framework laptop) but I don't understand point 1. packing a powerbank for example just feels ancient if you've used the arm chip macs. then again, I'm now pushing my trade-off
It's going to be a different experience for everyone. For example I never get why people care about the laptop weight. You put it in your backpack anyway, (unless it's a small handbag sized laptop situation then fair enough) it's not like anything below 5kg will be noticeable in reality. Yet for others is a big deal. Personal preferences...
"Packing a powerbank" was more of a hypothetical, as I've never actually had to.
My point was that it's a tradeoff between software preference, tech politics, price, and hardware features. I think it's pretty easy to understand. It's not like Apple has an insurmountable lead; there are some benefits for some use cases.
Kotlin programmer here who is picking up Rust recently. you're right, it's no Kotlin when it comes to the elegance of APIs but it's also not too bad at all.
In fact there are some things about the syntax that are actually nice like range syntax, Unit type being (), match expressions, super explicit types, how mutability is represented etc.
I'd argue it's the most similar system level language to Kotlin I've encountered. I encourage you to power through that initial discomfort because in the process it does unlock a level of performance other languages dream of.
I was trying to test the theory if it's even possible to release something production grade with vibe coding. Wrote about the experience here https://kau.sh/blog/container-traffic-control/