I agree but I think was also because Java didn't have sum types (or still doesn't? years I haven't read Java) and rethrowing is super easy, while Rust kinda nudges you into the right direction (if you need to rethrow at all, think if you want to rethrow verbatim or wrap with a semantic error type).
"old" is relative term. Given @TheRogue's account is 4 years old, maybe new to field. If so, it feels "old".
I understand your sentiment of justifying not being "old". but you gotta bring up "legacy code".
"Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
So either @TheGuardian is discussing about the age of software relative to his/her perspective or confused "legacy code" without understanding deno code base.
It's relative measurement. When you are 9th grader, even a freshman college student feels way older.
But as you are in your 30s, you feel less of difference.
Same thing here, How do you define Windows and Emacs being "old"? For those who's been using it for decades, not as old as Voyager software. For those who lived through those times, Windows and Emacs feels younger.
See where I am going with it?
---
If you have a nephew or a kid, they will say you are "old". But your parents will consider you "young" for the rest of their lives.
In the context of software, I think "how old is old" depends on how web based the software has been over its lifetime.
I think 8 years is old for software that has heavily Web based like Deno. But Windows and Emacs have had portions of their lifetime without the Web in a meaningful way, so 8 years would be young.
> "Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
This is not a universally accepted definition. I've owned plenty of services with 95%+ unit test coverage, massive integ test suites, and synthetic canary tests that ran every minute that I would consider legacy. Plenty of AI slop today gets barfed out with 100% test coverage, but much of it is legacy from day 1.
Workloads that either are superseded or there is a desire to supersede them. It's not just old deprecated stuff, but also stuff that people want to deprecate.
An example could be old API endpoints only hit by old versions of a mobile app where users may be slow to update. Or a case where only newer clients/instances support modern features and old ones are stuck on a frozen featureset until they cutover.
But active services with no immediately existant alternative may also be legacy. If your auth is behind a disappointing managed service like AWS Cognito, you may consider your entire auth stack legacy while the replacement is still looming in the roadmap down the line. Maybe you can't justify funding to work on a transition just yet, but you already would avoid building on top of the existing tech stack.
It may not be old, but it sure hasn’t caught on much after 8 years. I did remember a lot of posts about migrating cloud functions/lambdas to deno initially, but not much since.
I’m taking the stance that no news is bad news here. If it was good, people would be doing Resume Driven Dev with deno and we would be buried in those articles. Alas.
It's not that old, but it's old enough that it should have gained a bit of traction, it should have been mentioned in more discussions etc. And ultimately adopted more. It's purely a gut feeling though because I didn't run any numbers
Madrid. But it will only work properly if I'm clearly dictating with a very regular rhythm (ViaVoice dictation, if anyone remembers...). If I use a more natural/conversational rhythm (no slang, no abbreviations...) it easily confuses words.
That's the best case scenario and already looks like crap. If that looks sane to you, I don't know what to say.
Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this.
Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family.
Plus they only work with JS enabled, while I can use JSX in SSR.
I've worked extensively with Web Components. They suck.
Web components are intentionally low-level, they’re not really meant to be used directly. You should see them more as performant, interoperable building blocks. Have you tried lit?
This circles back to the OP's point: they're not appropriate to use directly, so we layer a framework on top of them (Lit), and now we're just using another framework with one small piece swapped out.
Except for the hyphens, I don't feel any closer to the platform when I use Lit.
You can inspect a Lit component directly in Chrome, it’s just a custom element. No need for a browser dev extension. You can use this custom element from React or any other JS framework. You can also use this custom element in a server-rendered template, no need for any custom SSR setup. Feel close to the platform yet?
Absolutely not my experience. I've been a long time Claude user and at work people slowly started using Claude too. I canceled Claude for my personal account due to the Astra hype, but I'm back after a single month and the absolutely ridiculous context window is one of the many reasons.
I barely compact at work in a very complex monorepo (neither with Fable 5.1 nor Opus 5.5), and yet in my personal greenfield project Astra keeps compacting all the time, to the point of it being unusable.
1. You're lumping distinct groups of people. This is Hacker News but "hack" often in the sense of "growth hacking", not in the "hacker manifesto" sense.
2. Even in that case, people might just be demanding equal justice. If I make information free I might get jailed. Regardless of my moral framework.
2. What’s your point? People are demanding justice for behavior they don’t like but isn’t illegal? The way to fix that is to gather a majority and change the law.
Right idea at the wrong time.
reply