Zen is simply a fork of Zed for those who are happy to use an IDE free from AI, telemetry, and other cloud-based services. I use it as my daily driver and intend to maintain it so that I can also use it as the base for some non-developer tooling I want to create.
Only tested on Linux for now, though Zed's support for other platforms should be (mostly?) intact.
Biome is an integrated linter/formatter for JavaScript/TypeScript, CSS, HTML and GraphQL.
We are now in the process of implementing TypeScript-like inference (not full type checking!) that allows us to enable type-informed lint rules. This is similar to typescript-eslint except instead of using tsc we attempt to implement the inference ourselves.
This post describes our progress thus far, with a detailed overview of our type architecture.
Biome is an integrated linter and formatter with support for JavaScript, TypeScript, CSS, and more.
Highlights of the release:
* Plugins: You can write custom lint rules using GritQL.
* Domains: Domains help to group lint rules by technology, framework, or well, domain. Thanks to domains, your default set of recommended lint rules will only include those that are relevant to your project.
* Multi-file analysis: Lint rules can now apply analysis based on information from other files, enabling rules such as noImportCycles.
* `noFloatingPromises`: Still a proof-of-concept, but our first type-aware lint rule is making an appearance.
* Our Import Organizer has seen a major revamp.
* Assists: Biome Assist can provide actions without diagnostics, such as sorting object keys.
* Improved suppressions: Suppress a rule in an entire file using // biome-ignore-all, or suppress a range using // biome-ignore-start and // biome-ignore-end.
* HTML formatter: Still in preview, this is the first time we ship an HTML formatter.
* Many, many, fixes, new lint rules, and other improvements.
As for Heraclitus vs. Plato, I think the lesson I’m trying to teach is to not pick a side until you understand each position’s implications and which of those might be more beneficial to the problem at hand ;)
In all seriousness though, you do hit a great point. The moment you stop being embarrassed about your mistakes and set your ego aside, is the moment that you can truly start learning from those same mistakes. At some point it even becomes the only way you can move forward, unless you want to stay boxed inside a niche of expertise defined by your own self-set boundaries.
Thanks! I would just like to clarify I’m actually not opposed to OOP at all, and at several points I tell people it’s fine to go in that direction for the problems where you need it. I do try to warn against it as a go-to solution before you’ve understood what are the problems that actually need fixing, which it sounds like we’re pretty aligned on.
Indeed if you pass by value/use immutability where feasible, you already avoid most of the issues I’m warning against, so it sounds like you found a sensible way to apply it while avoiding the pitfalls.
> If I have to give a taxi driver a jerrycan full of petrol, that's the definition of a leaky abstraction... Possibly literally in this case.
I actually have nothing against objects and methods, but that’s a very limited subset of OO. I prefer to use algebraic data types for domain modeling, and giving them methods is totally fine too. But I do prefer them to be immutable in most cases, which is also quite counterintuitive from an OO perspective.
Just know that if you do this, you’re injecting statefulness in the center of wherever it was this procedure was being used. If your entire system already has statefulness everywhere, nobody will bet an eye. But if you want to have any chance at creating a functional core or island, it’s the opposite of what you should be doing.
Only tested on Linux for now, though Zed's support for other platforms should be (mostly?) intact.