Complete Rewrite of ESLint
github.com
github.com
https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...
I've always been curious about the trade-off between "second-system syndrome" and "learning from experience". Do people have examples of rewrites that went well and those that didn't?
I can think of several that didn't go well (and in fact ultimately decided as tech lead at my last place not to do one for a big chunk of our code that I was on the fence about, just because of that), but can't think of many that did go well.
Maybe Go is kind of an example where the authors used all their experience to build something new, rather than just a straight up rewrite. BurntSushi's ripgrep is an example of someone else doing a rewrite that worked out pretty well. Others?
He’s right, that decision marked the end of Netscape as a factor.
They also rewrote their frontend in React (previously Ember.js)[1]
I know I've also seen a Twitch developer stream themselves benchmarking Rust + io_uring vs Go but I don't know if anything ever came of that.
Discord rewrote at least one Go service in Rust. [2]
Cloudflare made Pingora (Rust) to use instead of NGINX (C) though idk if that meets the rewrite criteria. [3]
[1] https://blog.twitch.tv/en/2022/03/30/breaking-the-monolith-a...
[2] https://discord.com/blog/why-discord-is-switching-from-go-to...
[3] https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...
NPM trends tells an interesting story as well: https://npmtrends.com/@angular/core-vs-react-vs-vue
I'd recommend a different strategy, personally:
Write a POC linter that demonstrates the features you think ESLint is missing, with no regard for interface consistency or backwards compatibility.
Once that's done, integrate it in a few real-world projects that currently use ESLint. See what the devs scream about, as well as what they like about it.
With all that data in hand, now you come up with a plan for making the desired changes to existing ESLint, being willing to consider the option of "nuke everything in the new branch".
You'd keep continuity of history for any files that aren't completely deleted, and you might find that you don't need to gut things as thoroughly as you expect.
> I don't believe continually to make incremental changes will get us to where ESLint needs to go if it wants to be around in another ten years.
The scale of years for rewrite and migration seems right.
Rewriting from scratch may make plenty of sense. A completely new architecture should not be held back by any remnants of the old implementation. The old test suite is indispensable though, and the old sets of rules are an important source to consult (even if not to directly incorporate).
One thing that stands out is that they haven’t grown twice the manpower with institutional knowledge overnight. You have to put a lot of effort into your rewrite, and you have to fix bugs in the existing thing.
I do see your point, though.
However… when code is the problem, rewrites make a lot of sense. Eslint is a very well understood program, there’s absolute clarity about what it does and what it should do across contributors, and they’re constantly battling bad code. A rewrite, in this situation, where other problems have been ruled out, is probably a good option.
- If you've worked with the library (as a maintainer/developer, not as a user) for a long time you know where the fundamental pain points are and, after a while, the desire to get rid of those pain points can become overwhelming.
- Languages evolve; what might have seemed like a good architectural decision 3 or 4 years ago may well have turned out to be a quagmire of confusion now, which new features in the language (JS examples: promises; fetch; various Array functions) can help simplify.
- Rewriting from scratch can also encourage a better, more maintainable approach to code documentation (and generating online documentation from it).
- Being able to dump outdated/questionable tests in favour of modern testing best practice is always welcome.
- A rewrite from scratch can offer a chance to reconsider the developer experience for people who consume the library in their projects/products - though there's a danger that moving too far away from existing practices can damage trust in the library.
... Of course, rewriting from scratch is always a lot easier if your library is (relatively) obscure. I imagine the ESLint rewrite is going to be performed in the full glare of the spotlight - see already the lively conversations around the decision to not rewrite in TypeScript!
[1] - Speaking from the experience of rewriting my (very obscure) JS canvas library from scratch 3 times over the past 10 years
why though?
JS is the front-end browser language. That's its origin story and it almost certainly will always have that job, because of web browser backwards compatibility.
That's why it's so universally known / used / understood.
Once you target TypeScript you're suddenly looking at a much smaller set of devs who know it, and you're married to a language that's effectively owned by a single company (MS, to boot).
You can get decent gains in type-checking by writing JSDoc and using tsc in your build process without adding much friction for new contributors.
Not saying it’s the best reason, but a reason nonetheless.
The typescript tooling was extremely simple to setup with only a few added packages... until I had to setup eslint. That's when I had to install a half dozen plugins, adapters, parsers, etc like you said.
Granted, the linked eslint rewrite seems to have plans to make the typescript linting tooling simpler. However, I might end up switching to Rome in the meantime just for simpler dependency management.
Of course they don’t have nearly the same amount of rules, but we’ll get there.
https://old.reddit.com/r/javascript/comments/z4lwlo/complete...
Choosing to use JS without TS at this point has become a dogmatic statement of purism that, while beautiful in a sense, is so unpragmatic as to appear a little foolish.
It's like insisting on using the pre-electronics version of a powerful, dangerous machine even though the new version gives you just as much control, greater precision, and much better safety, because of a romantic notion of purity in the way things should be done. Admirable and not at the same time.
Assuming everyone should use TypeScript just because you happen to like it over JavaScript seems crazy. But I guess that makes me seem crazy to you, so here we are in a circle...
TypeScript seems to have entered the same hype cycle as Rust (if it didn't do it before Rust) where people seem to think that everything written in X should actually be written in Y instead (C/C++ => Rust and JavaScript/Any compile to JS => TypeScript). Doesn't mean every project have to follow that though.
> Runtime agnostic. ESLint should be able to run in any runtime, whether Node.js, Deno, the browser, or other. Runtime agnostic. ESLint should be able to run in any runtime, whether Node.js, Deno, the browser, or other. […]
I certainly would never take a job in a pure JS shop.
Could you please provide a list of these tradeoffs?
But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer.
As a second tradeoff, choosing JavaScript over TypeScript tend to make codebases less complect and more modular, at least in the teams I've been in who maintained codebases with both languages.
My experience with js-land is that choosing a typescript and make use of the @types packages is _the_ modern way of doing js dev. What you describe is basically do the same people did 15 years ago.
That is not a trade-off, but a refusal to re-evaluate the situation under changing conditions.
You've yet to provide even a single example.
As an aside, at least to me your posts are coming off as really combative in this thread. You might get more constructive responses if you adopted a more curious, open tone.
Edit: found this on page... 4 of HN? https://twitter.com/swyx/status/1350427690814251010 .
> type errors may be such a small proportion of your errors that a using a type checker isn't justifiable
This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is.
> As an aside, at least to me your posts are coming off as really combative in this thread
You are correct in this. Sorry. I will fix my comments to come off as less abrasive.
Oh super interesting! I wonder if the solution is like, tsc becomes a reference compiler. I'm pretty sure people would absolutely love a Rust implementation that was fast but a little behind. A lot easier to daydream about than to do though, haha.
> This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is.
Yeah and I do miss this in dynamic languages. Interfaces (and typed data structures) have great descriptive power just on their own. There are run time packages for this (prop-types, etc) but... run time is worse haha.
[citation needed]... My experience is the exact opposite. Javascript code bases I've worked with had crazy mega functions that would accept any arbitrary input and try to return something. Typescript code bases (in my experience) tend to be more modular because the interfaces between things are clearly defined. If you want to use code written by someone else, it's immediately obvious what structure your data needs to have to work with their code.
> But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer.
I mean, they are talking about having parts written in rust:
> Rust-based replacements. Once we have a more well-defined API, we may be able to swap out pieces into Rust-based alternatives for performance. This could look like creating NAPI modules written in Rust for Node.js, writing in Rust and compiling to WebAssembly, creating a standalone ESLint executable written in Rust that calls into the JavaScript portions, or other approaches.
That looks like an _extremely_ complex build system setup compared to using the Typescript. They are also planning to document the types anyway:
> ESM with type checking. I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS, but I do think rewriting from scratch allows us to write in ESM and also use tsc with JSDoc comments to type check the project. This includes publishing type definitions in the packages.
The only possible trade-off I can think of is that type checking with tsc + JSDoc results in a faster build than using typescript directly. Personally, I find it a bit odd to use tsc + JSDoc instead of TS, but hey, they can do what they want.
Like, you are theoretically correct, but practically the extra complexity of using Typescript over Javascript is running ‘npm install typescript’ after installing node. You certainly have less build tooling without tsc, but the benefit there is tiny.
There’s some mild reasons to go for pure JS, and a lot of absolutely gigantic reasons to go for Typescript (in my opinion).
Even Rust, which has a much stronger type system than TS, does not prevent all runtime errors. Types can prevent a certain class of bugs/errors, and that’s great, but zero runtime errors is overstating it by a wide margin.
Of course, everything is just tool. Its up to us to decide if we want to use it or not. What I don't understand is why wouldn't you use it. I totally understand if its fun to cobble together some webserver using only bash scripts. But if you're writing something as big, complex, and widely used as ESLint, I am very surprised if you don't choose something that is more performant and maintainable. It is almost irresponsible. I have plenty of fun side projects that should never ever be used in production because I know its really bad.
I never claimed that using Rust will magically make all your sort implementation correct. Of course this is an insane claim. But like I said, if you take any snippet of JavaScript, you actually cannot reason about it without looking at all the calls to that function, plus all the functions that calls to that. Given any variable S, what is its value? Who knows. I guess you just have to run this massive test suite that we wrote. There's WAY more possible incorrect JavaScript code than there are Rust.
I have written webservers in TypeScript and Rust. The moment I get something out of serde in Rust, I know for a fact this is a string. If the key doesn't exist, its None. In TypeScript, I don't have the same confidence. Did they wrote the correct validator? Wait did they add a default value? Does this interface match what we have? Oh its a string...but its actually Date. Wait...why does this bool keep returning false...(https://stackoverflow.com/questions/59046629/boolean-paramet...)
I could have written 1000s of unit tests...Or just use type and fail the "test" at compile time.
>there's anything wrong with working in language without static typing
Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.
> Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.
Frankly, I have a lot more confidence in something written in Python/Ruby/JS to not fail in a really dangerous way than I do something written in C. It's silly to pretend like all languages with types are equivalent, or that types are uniformly better for all use-cases.
Sure, the type systems in C/C++ will verify that you don't have type errors, but they can't verify that you don't have use-after-free errors, or out-of-bounds errors, or null pointer dereference errors, and so on. Even Java, which has an extensive and relatively modern type system, can't protect you from null pointer dereferences.
I never said "there's nothing wrong with working in a language without static typing for ANY PROJECT IN THE WORLD." Some projects need it, and some projects frankly don't. Linux, given its constraints, could not have been written in anything other than C. That's fine.
Very large projects in dynamic languages seem to eventually want type annotations, e.g. Dropbox (Python), Stripe (Ruby IIRC), and Facebook (PHP). But at the same time there are plenty of large, successful projects written in dynamic languages: GitLab (Ruby), Wordpress (PHP), much of emacs (Lisp), this very website (Lisp), Datomic (Clojure), CircleCI (Clojure). Sure, you can say that all of those projects should have been written in some statically typed language, but they have found success regardless, which is really the only metric that matters.
Besides, I’d imagine the deployed code would be minimized anyway regardless of whether TypeScript is used.
Which renders your formula meaningless.
- code formatter :: style
- type system :: tests
...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated.
All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
> - type system :: tests
This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API.
Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like:
"Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system."
My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?"
In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc.
---
> so suggesting data driven decision making such as benchmarking because you don't trust Big-O
The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion.
> quantifying typescript's benefits instead of actually thinking about them is a cop out
This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example:
int add(int a, int b) {
return a - b;
}
Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.
Im just too tired at this point to address the comment that having more types is somehow a burden on eng velocity while having more tests isn’t. In reality, you never have nearly as many tests as you ideally need, but you can add more types more easily and it will help people reason about your system much easier.
Speaking of which, tests are often way too verbose it hurts readability aka the ability to reason about your system
My point is that if you have tests, you probably don't need types, and since you really oughta have tests, the benefits of mainstream type systems are overstated. A lot of arguments in this thread are essentially "types have benefits you can't get anywhere else", but you can get them with tests. When it comes to verifying program correctness, tests are a super set of types' functionality.
> You can have less tests when you have more types.
Can you? In my dynamic language work the tests aren't doing type checks, usually there's some kind of validation library doing that. Generally the tests are doing work that types can't.
> There are type systems that requires an overhaul of the whole toolchain, but what we’re talking about typescript isn’t that.
I guess we can disagree about "overhaul", but IMO adding a compiler, new dependencies (types) and entirely new syntax to your toolchain qualifies. If that doesn't, what does?
> You can literally run plain js with jsdoc through tcs and make your comment provably accurate documentation
A few things foil this:
- using `any`
- using untyped libraries
- taking advantage of gradual typing
- unhelpful type soup
"Type soup" really bears expanding:
subscribeToMore(
options: {
document: DocumentNode,
variables?: TVariables,
updateQuery?: Function,
onError?: Function
}
) => () => void
Further, these types don't verify any behavior. They can't prove to you that `onError` is called when an error occurs. They can't prove to you that you will continue to receive data when it's updated. They can't prove to you that you subscribed to the specified document. On and on. There's a reason that high-reliability environments use tests, even though they're using strongly typed languages like Ada and Eiffel, and that's because type systems cannot fully specify a program's behavior.
[0]: https://www.apollographql.com/docs/react/api/react/hooks/#su...
TypeScript transpilation is easy and fast. You can emit JS even when there are type errors, and use tsc as just a type-checker while using esbuild to strip types from JS. Performance is not an issue in practice and the benefits are pretty far reaching.
This statement makes no sense in two ways and shows you're not as accustomed to the problems at hand as you'd perhaps like to be. First, eslint is a developer tool and not intended to run in the browser. Second, you generally do not distribute typescript code but compiled js to target platforms.
> TypeScript seems to have entered the same hype cycle as Rust (if it didn't do it before Rust) where people seem to think that everything written in X should actually be written in Y instead (C/C++ => Rust and JavaScript/Any compile to JS => TypeScript). Doesn't mean every project have to follow that though.
No, TypeScript is a superset of JavaScript that can be enabled with little cost for the gigantic benefit of bringing type safety to a language which people have mocked for its unsafety for decades.
I really wish people on HN would hold back a little with their contrarian purism at all cost.
from the linked article: "Yes, that means an officially supported browser version!"
This sounds like everyone wins except the people who are overly-dogmatic about TS.
What about Deno or people using it in web-only contexts?
If they use ES-compliant modules, a build step isn't even required.
Once again, it's not that they don't have types, but the TS fanboys are now complaining that it's "not the right types".
i was under the assumption that deno natively supported typescript, no?
Since the new ESLint is going to be highly modular, TS would shine in defining these modules' interfaces in a robust way. Whether to use TS deeper down, or whether to enforce the use of TS across the codebase, is another question. Prototyping is often easier and faster with plain JS, while typing well-defined parts later may be helpful for maintenance purposes.
I disagree, especially in the realm of AST-crawling, that having type hints in the IDE has been extremely beneficial in moving fast.
Type-level refactoring tools don't seem to be very powerful at the moment, too; without them, you can end up with some legwork when you change a design decision (a frequent thing while prototyping), even if you carefully aliased every type (which is legwork in its own right, because trivial cases like 2-tuples are plentiful).
Fortunately, TS allows you to gradually type your code, and rely on inference in many cases (not as much as Haskell, but still).
Bonus points if it comes in notebook form so you get a nice convenient run button, a solid multiline text editor, and markdown-powered persistence format.
Thankfully, this already exists: https://marketplace.visualstudio.com/items?itemName=jakearl.... . And it supports every language your shell does!
(I made it)
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
Every bug to to ever hit production has
* passed all manual testing
* passed all unit tests
* passed the type checker
What isn't helpful is the the notion that types replace testing. Either manual testing or unit/functional/generative testing. It isn't "safer" at all, it does speed up development by catching the simple bugs so the run edit compile loop is less. If you're saying "my code compiles then it's works", I don't buy it.
I'm glad that you agree type checkers help avoid error prone and expensive manual testing work.
> What isn't helpful is the the notion that types replace testing.
Types are a type of testing. They are another tool in the toolbox for writing correct programs.
Or been ignored. It happens.
> passed all unit tests
If they have been written at all. And every bugfix should come with a regression test.
> passed the type checker
If it hasn't been disabled. And I would expect that a bug that could be fixed with better typing would include making types more restrictive when necessary.
Unfortunately, tools like testing and types are seen in two conflicting ways. Some people embrace them and see that they can use them to write better code with less bugs. Others see them as obstacles that have been placed in their way due to the additional learning curve.
But what bugs did you not see hit production because these eliminated it?
I disagree. The lesson learned from a decade of js tooling is performance issues.
That is why you see more and more js tooling rewritten in rust or other fast languages.
This is GOOD for js development, in the sense you end up with better faster more powerful tooling.
Now whether you use JS at all is a completely different point, but I think the parent was making a point about TS > JS, than TS > other languages.
It's Flow that just allows to remove any type annotations; there's no compiler, only typechecker.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This gets a bit more complicated in some setups because the typescript compiler can also transpile modern JS/TS code to older versions, doing a similar job to Babel, but this doesn't have to be the case, and in practice this tends to be fairly orthogonal to the question of Typescript: you can compile to older versions regardless of whether you use Typescript, and you can use Typescript regardless of whether you compile to older versions.
So in practice, there will be no difference between a Typescript program and an equivalent idiomatic Javascript version, because Typescript is just Javascript with syntax for type hints.
The main exceptions are enums, and decorators, both of which perform straightforward transformations. My understanding is that adding new such features are forbidden as the TypeScript team considers them to be historical mistakes. If new syntax is added in the future is should be such that it can be mechanically stripped, leaving the obvious underlying JS behind.
There also exist some historical features like namespaces or const enums that have long been considered essentially deprecated by the team (not marked as such in the documentation, as there are no plans to actually delete support for them, but they won't work correctly in isolatedModules mode for example). In practice those features are not used in new codebases since project templates will be configured with isolatedModules enabled.
The advocacy for Typescript is for type safety. Using Rust hits that same benefit.
People, if you must be religious about a programming language, at least find a more enthralling god than a JS superset!
> ESM with type checking. I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS, but I do think rewriting from scratch allows us to write in ESM and also use tsc with JSDoc comments to type check the project. This includes publishing type definitions in the packages.
This is such a heated debate, and so many posts here are just simply wrong about the capabilities of using TypeScript as a type checkers.
A statically typed code base is a primary goal of the author, they simply pick to do it using JavaScript and annotating the types in JSDoc comments, using TypeScript only as the static type checker, which is an available—and well supported—option in TypeScript.
> Choosing to use JS without TS at this point has become a dogmatic statement of purism that, while beautiful in a sense, is so unpragmatic as to appear a little foolish.
You’re parent is simply just wrong here, and it is quite frustrating how many posts here simply take up this talking point and repeat it.
It doesn't seem that performance was the driving factor, but the ability to keep code idiomatic?
https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...
> Incremental compile time when changing files in cli/js takes minutes. This is crushingly slow and painful to modify.
> The typescript organization/structure that we're using in cli/js is creating runtime performance problems.
Either way, my point is that there are very practical non-dogmatic reasons to use JS over TS.
But if you're building developer tools or libraries and want the output to be optimized for the end-user, introducing a middleman like tsc or esbuild can have tradeoffs. This is likely what the ESLint team considered.
opentelemetry.js is already an architectural nightmare (clearly built by people who use J2EE), but the fact that it's Typescript makes it ten times worse because I can't set breakpoints. I have to step all the way in every single time. Through layer after layer of delegation. So much delegation they had to pull out a thesaurus to name things.
JSDoc can do a lot of the things that Typescript does. Use it.
The goal is type safe code, and there are multiple paths that get you to that goal. Pretending that TS is the only, golden path and everyone else is hopelessly wrong -requiring hyperbole to mock even- suggests having lost sight of the actual goal itself.
for real, it's less the hassle.
I'm not here to rain on Rust's parade, but you can absolutely write unmaintainable, slow Rust code. I would even argue, beginners write fewer features that perform worse, in the same amount of time, than their main-language (in this example: Javascript) counterparts. Especially if they have years of experience.
That might still be the realm of the sufficiently smart compiler though, aka vapourware, so in practice today you're probably right.
However, I do appreciate the desire for developers to use languages that allow for more performance and fewer bugs, catching more bugs at compile time.
Even small improvements are important.
Ideally, poorly written, but correct, code in such a language could be refactored more easily in such a language.
I imagine you're of the same mind as I am - be intentional when choosing a language for a project, and consider all the pros and cons.
My impression -- no firsthand experience -- is that the ser/des costs associated with FFI between node and rust when dealing with large objects like ASTs can eliminate most wins, especially if you have to go back and forth multiple times.
Related: https://zaplib.com/docs/blog_post_mortem.html
I'm also under the impression that most of the gains from rewriting Node into Go or Rust come from getting access to multithreading, which I can't imagine working well in this context if the ESLint plugins themselves are still written in JS (which, IMO, they certainly should be). A single file will still need to run on a single thread.
(Of course, you can run different files on different cores with Workers or just subprocesses, but I assume ESLint does this already)
To be real, I don't think they'd get any perf gains from a wasm component - not until most of the library is wasm, anyway. The dream of offloading a small hot function to a faster, instruction-optimized wasm implementation is usually killed by marshalling costs for anything other than numbers. Even the perf of simple string functions (like `normalizePath`) often get destroyed in practice by things like unicode validation, since the string models and memory layouts between JS and Rust don't match. Still, despite all that, it's tempting to _try_ because, well, what else are you going to look into for performance gains? Once you've tracked down all your v8 deopts and monomorphized all your hot code, what's left but telling v8 to get out of the way as much as possible, while you go as low level as you can? Algorithms improvements? Those often amount to random flashes of insight - you can't plan those. So when a lot of people say "Hey, I reimplemented 5% of X in Rust and it's 20x faster!" you _could_ smugly assume it's because it's a partial implementation, or you can choose to believe that the authors don't have ulterior motives and the tech stack itself has merit and investigate it yourself. It'll be easier and more fun than thinking hard about usage patterns and algorithms all day, anyway.
But you CAN write fast code too! And that, for a fairly high level language (in some aspects) is quite a feature, especially in the context of the safety it provides.
In pure Python/Ruby you can certainly not write very fast code, not matter how hard you try.
Things You Should Never Do, Part I
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
While I don’t necessarily agree that we should never ever rewrite, he is making some good points that we can ignore at our own peril…
Of course, in this space I don't think eslint has many competitors, unlike Netscape vs IE did then, so they've got time.. for now.
I'm sure 'old' eslint will be mostly ignored in the meantime, as the excitement will be with the new shiny.
An ESLint plugin manages to do this well[1]. Would be nice to have this functionality built in natively although you do take a performance hit because you have to run the compiler.
Any discussion these days around eslint reminds me of a new situation that still has me very confused where I've encountered a team of engineers that refuse to allow any formatting on their code. Are there any folks that run large JS/TS codebases with no automated linting/formatting by choice and maybe feel similarly or worked with other teams that do? I've come to expect eslint (and prettier) to be pretty much a given for a large JS/TS codebase.
It looks like ESLint wants to compete with all Rome can do.
I find it funny how Go was born to be a simpler C, but managed to get a lot of mindshare with Python developers that were writing system-level scripts and backend systems.
While Rust was born to be a better C++, but is getting a lot of traction with Javascript/Typescript developers, and you can start to see some similarities in the packaging and tooling philosophies of the two. (Ton of small packages, some that should probably part of the stdlib but anyone needs to use to stay sane: futures, thiserror, anyhow, for example. Also there starts to be a tendency to rewrite and release incompatible APIs that this time will solve all the problem of the previous iteration).
I guess the hype-driven junior developers saw how better Typescript is at managing Javascript's shortcomings, and now see static typed languages, especially one with some hype of its own behind, as the Messiah.
Let me add the disclaimer that I'm a fan of Rust before I get attacked for this controversial observation.
(I prefer Go over Rust for general purpose programming, and I wish that Wasm had an answer here so we can use less complex, cognitively-lighter languages.)
We have fewer than 500 Rust dependencies in our Cargo lockfile, including dev dependencies.
Meanwhile, our relatively simple react frontend and graphql server written in TS have over 20k dependencies. It’s truly a different order of magnitude.
Running `yarn info -AR | wc -l` gets me 3,413, and I get the same number for `cat yarn.lock | rg '^".+":$' | wc -l`
I remember running `yarn install` before we switched to `yarn 2` used to get us some absolutely insane number of packages being fetched in the 20k+ range, which is where my number came from, but I hadn't looked at it again in quite a while. I'll update my original comment. (edit: nvm it's too old to update, oh well)
I think Rust's appeal (and Go's for that matter) in these cases is that it offers high performance without a lot of the footguns of C and C++. This means that even if the language is challenging at first, the pay off is far more confidence that the compiled program is correct.
It is curious that Rust seems to be the overwhelming favourite for new JS/TS tooling. The appeal of static typing from TS carrying over to Rust seems plausible, but in this case, the developer is favouring JS over TS for the initial rewrite, so I'm not sure how true that is.
If I wanted an ideal GC'd language with good types, I'd pick StandardML to pour time and resources into instead of go as it's a better-designed language with similar performance, better types, more simple syntax, and with better-modeled concurrency.
You can see the exact same thing with the transition from NoSql to SQL.
At first it just seemed like added complexity, then that "ah ha" moment hit, and it clicked.