1
point
bpavuk
Joined 40 karma
- bpavukless crap than tons of buttons with region-blocked content, imho
- sorry, editing it out! thanks for pointing out.
EDIT: I was too late to edit it. I have to keep an eye on what I type...
- let me be a date-time nerd for a split second:
- Claude Code released Introducing Claude Code video on 24 Feb 2025 [0]
- Aider's oldest known GitHub release, v0.5.0, is dated 8 Jun 2025 [1]
- why not just use a big ol' monitor with a smart TV box and plain Android TV? or, even better, build a HTPC with Plasma Bigscreen or Bazzite?
- > The bottleneck is still knowing what to build, not building.
shit, I'm stealing that quote! it's easier to seize an opportunity, (i.e. build a tool that fixes the problem X without causing annoying Y and Z side effects) but finding one is almost as hard as it was since the beginning of the world wide web.
- side effects are not necessarily a bad thing. unintentional side effects are. with some exceptions, such as UI frameworks, I find it harder to unintentionally create a side effect. also, UI is basically one huge side effect.
Kotlin and Rust are just a lot more practical than, say, Clojure or Haskell, but they both take lessons from those languages.
- I'd personally declare dead everything except 3 and 4 because, unlike the rest, polymorphism is genuinely useful (e.g. Rust traits, Kotlin interfaces)
trivia: Kotlin interfaces were initially called "traits", but with Kotlin M12 release (2015), they renamed it to interfaces because Kotlin traits basically are Java interfaces. [0]
[0]: https://blog.jetbrains.com/kotlin/2015/05/kotlin-m12-is-out/...
- near-infinite until they finish Kotlin LSP alpha.
also, hot take: Kotlin simply does not need this many tools for refactoring, thanks in part to the first-class FP support. in fact, almost every non-Android Kotlin dev I have ever met would be totally happy with analysis and refactoring levels on par with Rust Analyzer.
but even with LSP, I would still need IDEA (at least Community) to perform Java -> Kotlin migration and smooth Java interoperability.
- this explains virtually everything:
- that's why OOP failed - side effects, software too liquid for its complexity
- that's why functional and generic programming are on their rise - good FP implementations are natively immutable, generic programming makes FP practical.
- that's why Kotlin and Rust are in position to purge Java and C, philosophically speaking - the only things that remain are technical concerns, such as JetBrains' IDEA lock-in (that's basically the only place where you can do proper Kotlin work) as well Rust's "hostility" to other bare-metal languages, embedded performance, and compiler speed.
- concise answers are the best, and I agree with that one.
I am still curious, why? I have my own set of why's and want to hear yours
- first off, drop the idea of coding "agents" entirely. semi-async death valley is not worth it, you will never get into the flow state with an "agent" that takes less than an hour to spin, and we did not learn how to make true async agents that run for this long while maintaining coherence yet. OpenAI is the closest in that regard, but they are still at a 20-minute mark, so I am not dropping the quotes for now.
another argument against letting LLM do the bulk of the job is that they output code that's already legacy, and you want to avoid tech debt. for example, Gemini still thinks that Kotlin 2.2 is not out, hence misses out on context parameters and latest Swift interoperability goodies. you, a human being, are the only one who will ever have the privilege of learning "at test time", without separate training process.
replace coding "agents" with search tools. they are still non-deterministic, but hey, both Perplexity and Google AI Mode are good at quick lookup of SvelteKit idioms and whatnot. plus, good old Lighthouse can point out a11y issues - most of them stem from non-semantic HTML. but if you really want to do it without leaving a terminal, I can recommend Gemini CLI with some search-specific prompting. it's the only CLI "agent" that has access to the web search to my knowledge. it's slower than Perplexity or even ChatGPT Search, but you can attach anything as a context.
this is the true skill of "how to use AI" - only use it where it's worth it. and let's be real, if Google Search was not filled with SEO crap, we would not need LLMs.
- it will be easy to prove that it is not technically possible since Git is decentralized. but fines... oh, those fines could be enormous. possibly, AMD could get barred from implementing HDMI at all - all HDMI has to do is to stop selling the spec to AMD specifically.
- I am missing some context, did not follow the Linux/Rust drama. which guy?
- yeah, but you have to download their mobile counterpart as well. you can't have e.g. Chrome desktop and Brave mobile work together. meanwhile, any Firefox syncs with any Firefox
- modern Zen is a lot better than then :)
the only missing from the sidebar thing is Library as a central place to manage downloads, spaces, and history. and although the downloads window looks a bit unsexy, it's totally enough
- Zen is actually solid these days. being a Firefox-based browser, it has its quirks, (i.e. Theo complained about gradient rendering or whatever, but who cares?) but it's still the best Arc-like we currently have.
plus, you get synchronization across desktop (Zen) and mobile (Firefox for iPhone/Android). since Google limited theirs only to official Chrome, this feature is basically exclusive to Firefox and forks, Arc <-> Arc Search, and Chrome for desktop <-> Chrome for mobile.
- seen excitement around if. [0] just a reminder: CSS had custom functions for months.
- 1 point
- I, too, am extremely interested in development on Tangled, but I miss two features from GitHub - universal search and Releases. the web frontend of Tangled is so fast that I am still getting used to the speed, and jj-first features like stacked PRs are just awesome. kinda reminds me of how Linux patch submitting works.