kiliancs

To me Effect is past those endless cycles and debates. It leaves you in control, and doesn't take over, but it gives you primitives that are really needed. Primitives without which you can get by, but you end up paying in correctness, future issues, and reinventing the wheel to solve the problem (often incorrectly). In the JS world, this is one of the reasons we end up with hundreds of dependencies for a small project: besides the actual abstractions, you have all the plumbing between abstractions.

Effect solves this elegantly.

> barely any time at all on solving the actual problem

This is how we should measure things TBH. For me, Effect solves very real problems. As a Principal engineer, I sleep so much better overseeing many teams and agents releasing to production because of Effect.

> Code that you can put a breakpoint on to debug.

This is a pain point for sure. For me, the tradeoff is clearly positive (because also the need for debugging that way decreases significantly with more declarative, type-safe, well-architected, telemetry-first code), but it is still very unfortunate.

This was me in the past too. But Effect's DI is only advantages, because it is all type safe, including that you _must_ provision the dependency. The result is all the benefits of prop-drilling (explicit) without its problems (now your whole execution tree must learn about this dependency in a leaf).

Effect's type-safe DI simplifies application architecture (you now have a clear algebra that is interfaces + layer composition), promotes important architecture principles (e.g. it's a lot easier to compose within the application when components are not tangled because they have to pass "ambient" service props through), and as a result apps are a lot easier to maintain and evolve.

This is the sort of guardrail that really matters in the age of AI, because AI can still mess things up, but the blast radius of messing things up locally is very different than sloppifying architecture—and makes the problem of slop itself more treatable.

Effect is to TypeScript what TypeScript is to Effect. It just pays off. But most of the learning curve or the unfamiliarity with syntax and even concepts goes away with AI. In fact, the same reasons why it makes it good for teams makes it good for AI. When a team member or an agent use the Effect patterns, I know I there is a lot less they could have messed up.

One issue with Effect is that it's hard to intro because it does many things. But it does them well, and it does all of them because only a coherent system can deliver the promise of allowing you to write production-ready TypeScript.

I'll list some things:

- Effects: how you describe programs. For some people it helps to think of them as promises on steroids. In addition to tracking the return type, they track the types of errors it could fail with, as well as its dependencies (see context/layers).

- Fibers: primitives for concurrency—but most of the time you don't have to think about them because the `Effect` methods handle most common scenarios

- Context/Layers: type-safe dependency injection. Have your cake and eat it too. You define context interfaces, use them within effects, and TypeScript forces you provide implementations of those interfaces via layers. Layers can provide more than one context, and can also depend on other layers. Very powerful.

- Schema: think Zod, but with the concept of codecs (to be fair Zod has this too), which means you define how things encode (e.g. what API takes and responds with) and decode (e.g. what my app works with). I love `Model`, which derives schemas for the API side and repo (db) side, so I can define a domain model declaratively with things like "account number should be replaced with * except the last 4 digits in the API; it should be Redacted (wrapped, can't leak to logs etc) within the app logic, and should be encrypted in the database".

- Standard library: lots of things that should standard in JS/TS and aren't, or exist but are not coherent or play well together. When I don't use Effect, I have to choose between doing things well or shipping (and suffering the consequences). And I don't mean just strings, dates, decimals. I mean also queues, cache, etc.

- SQL primitives to work with transactions, migrations, queries. There are interfaces on top of this for popular ORMs.

- HTTP server; and ways to define your API with types and schemas, then implement it.

- Telemetry, logging by default

...and I could go on. I am not looking back.

You may also be interested in https://alchemy.run/git/

What is the default reasoning level?

Based on the abstract, this has to do mostly with diversity within a language, but the impact on the diversity of languages and their health is even larger. My direct experience is with Catalan. The uphill battle of Catalans to get _anything_ in Catalan continued with tech (where even some manufacturers _removed_ Catalan from their phones purchased in Spain even though it was available by default), but reached new heights of impact with voice assistants and LLMs. They have managed to bring Spanish into Catalan households, because that is the only way they have to e.g. tell a device to start playing their favorite music, tell them the time, or provide directions.

I applaud the efforts by Softcatalà, The Mozilla Common Voice Catalan Community, AINA, etc. but there is a long way to go, and the damage is being done now.

I left Firefox for the first time since... well, I _think_ I used it before it was Firefox. This self-imposed exile only lasted a couple months.

I left looking for low-friction answers to my need to organize tabs and content. I didn't love giving up control to some central organization to process my data, but I had promised myself I'd write one or two extensions to answer my needs "next week" for years.

After doing some research, most of what I wanted already exists. Sidebery, Tab Wrangler and the new Agents window (with some styling to eliminate the default tab list), together with my other old friends like uBlock Origin, Auto Tab Discard (suspend) and a number of container-related extensions, deliver the same functionality I found elsewhere, without taking control from me.

Plus, this is just me, but chromium-based browsers manage to get my m3 pro macbook with 36GB RAM hot pretty consistently with normal use. I noticed the moment I left Firefox. And I noticed the problem gone as soon as I went back to Firefox.

I have often criticized Mozilla, because I care that Firefox remains the best browser, not just an alternative worth keeping.

Previous discussion https://news.ycombinator.com/item?id=46177022

A discussion from 3 years ago. https://news.ycombinator.com/item?id=34243520

I would be interested in seeing numbers backing the high performance claims.

Also in their website https://catala-lang.org/en/about#naming

I see where this sort of take comes from. Reviews are not a place for subjective comments that just slow down or block progress, signaling, excessive nitpicking, etc. However, the reviewer should be thinking beyond the immediate "hey, this is progress", and also consider how this change affects the codebase and how it aligns with feature and technical direction. A few happy approvals and a great codebase becomes hard to work with, if contributors are inexperienced.

Code reviews are also an opportunity for learning, and provide real-life scenarios to inform decisions that are otherwise not grounded and mostly opinion. Of course, not all comments and discussions should block approval, but there is a balance. No one is going to die if this feature is delayed by a few days if you get a better result _and_ are investing in team growth.

If the targets are in other countries, deployed by other countries, I don't think this is a good example.

Careful! People have gotten in trouble for using that expression before. https://www-vilaweb-cat.translate.goog/noticies/linterrogato...

It is akin in that the same sort of mistaken political intrusion into linguistics was being made.

Great project. Clear goal, well executed, very nice API (safe, terse, clear).

I use Effect CLI https://github.com/Effect-TS/effect/tree/main/packages/cli for the same reasons. It has the advantage of fitting within the ecosystem. For example, I can reuse existing schemas.

The other laptops overheat soon after purchasing, often with just the bare OS running. There is a 3 yo laptop that my parents still use, but it has to always be plugged in, and the fans will spin loudly even in suspension.

My >10 yo macbooks also have bad batteries. One of them won't last one minute, and will also overheat with minor workloads. They were not immune to overheating when new, but unreasonable overhearing (for the time) definitely didn't become an issue at within 3 years of purchase.

And that's with Intel macbooks. My M1 from Dec 2020 works like new (I'm sure the battery life has shortened, but not in a way that I notice). It overheated a couple times running LLMs—that's it. That's how I know the fans work.

In my experience and my family's you are lucky if they last 3 years. If they last 5 years there's usually a subpar experience, e.g. they overheat significantly at 2 years. OTOH, we have a few macbooks > 10 years still working.

I like Ecto's approach in Elixir. Bring SQL to the language to handle security, and then build opt-in solutions to real problems in app-land like schema structs and changesets. Underneath, everything is simple (e.g. queries are structs, remain composable), and at the driver layer it taks full advantage of the BEAM.

It's hard to find similarly mature and complete solutions. In the JS/TS world, I like where Drizzle is going, but there is an unavoidable baseline complexity level from the runtime and the type system (not to criticize type systems, but TS was not initially built with this level of sophistication in mind, and it shows in complexity, even if it is capable).

Vertical tabs and tab groups (I suspect it can't be that different from folders but I could be wrong) are available in Firefox.

- article schema - page schema - non-technical users can author & upload

And the browser takes care of the rendering.

Good times.

Indeed. Catalan speakers have Spanish forced down their throat no matter if Spanish has never been associated to the Google account in any way, nor in the system or browser language preferences.

In my case, I live in the United States, but Google is determined to serve me Spanish results even for Catalan-related queries. E.g. preferring the Spanish Wikipedia. The search engine's behavior has had ups and downs over the years, but it has never been great.

This is very much a problem for my children, who don't understand Spanish, as well as for the Catalan-speaking regions of the world that are not in Spain, including Andorra.

In my experience, Gemini easily flags any Catalan content as unsafe and prevents the conversation from continuing. Even for prompts like "summarize this article". This may have improved lately, but still.

Google used to be an example in sensitivity to the world's diversity, being a responsible major player. Way back. Now, although I applaud some efforts multiple teams continue making, it is obvious this is no longer a priority.

They also seemingly went out of their way to prevent ctrl/cmd+click on several anchor elements in pages like https://m3.material.io/components.

Now the website asks if you like emojis or not. I don't mind the emojis, but if I did, I think I'd prefer them to the popup.

Remembering bugs is not necessarily and indicator for passion. I know I love what I do, and have since I was really young, but I do not keep track of bugs or even feats—they just become a rolling base of knowledge (experience). At least in my case, it is just how my brain works.

This is so different from what comes to mind when I think about how to improve productivity:

- require engineers to present and justify engineering investments (and understand that what you don't accept has real costs) - have engineers estimate the work in the roadmap, and provide clear risks and possible mitigations - note all of the above means the goals are clearly defined first - not everything you wanted to accomplish may fit; be prepared to distinguish essential from good to have, and to change the order of your priorities. - have teams commit to dates based on estimates, a healthy error margin, additional responsibilities, meetings... - plans change, things happen, life happens, engineering is hard. It's OK, it's expected! Make sure there are clear communication channels from engineers to the top, and from the top to the engineers, so that expectations are adjusted as soon as possible, and maybe make further adjustments. - Communication should happen often. Be always available to listen, don't micromanage. - managers should protect engineers and said communication channels - managers and PMs do not set deadlines - don't hire cheap; hire motivated team players. - the primary role of your >Senior engineers is to be force multipliers (how is a whole different conversation), not to do superhero work - communication, communication, communication; you'd be shocked how much time is wasted by engineers being unsure how to proceed and not sure who to ask of if the question will be well received; there are no bad questions.

I feel like I could go on and on and expand on many of these.

Yes: multitasking hurts; yes, procrastination is bad; but beyond looking at each "issue" individually, engineering leadership should provide processes and culture that protect, motivate and facilitate success.

I agree. Our kids are very much ahead, in part because when we travel, they learn a lot. They seen new places, new ways of doing things, learn history, apply their math and other acquired knowledge, they often learn things ahead of time just because they interact with other adults, they get to use free time to apply their knowledge and interests creatively. And with the right timing, they get to see their relatives far away without it draining our savings, which makes them happy, which is not only important, but makes them better students as well.

> Or maybe do start saving, so your ancestors can take advantage of compound interest to buy a ticket in a few millenia

My apologies if this is off-topic, but I have recently read and heard a couple cases of "ancestors" being used instead of "descendants", which has sparked my curiosity. Is this a common brain-lapse result?

Speaking of which, he made a statement about Toriyama's passing: https://www.cbr.com/one-piece-eiichiro-oda-dragon-ball-akira...

I see how I was too vague. I decided to post without elaborating because I thought the concerns were obvious from previous HN discussions about Mozilla announcements of different sorts, and because I was running out of time, which probably was a mistake.

The Pocket partnership and acquisition, the 250 layoffs with the 4x CEO pay increase, the Mullad partnership for a worse offering, are all concerning and they do destroy trust, but my primary concern is the apparent lack of focus. Can Mozilla sustain all these potentially positive initiatives (like this recent announcement or https://foundation.mozilla.org/en/privacynotincluded/)? I very much doubt it. And I hope this changes before Firefox usage drops even further.

I'm not a Mozilla hater. I have contributed Firefox translations in the past, built extensions, and I even collaborate actively with some of the projects that I think are distracting Mozilla.