4 ms·

> I foresee a future where we won't have to deal with slow tooling and can have instantaneous updates once again. You quote Python examples around data process

> I foresee a future where we won't have to deal with slow tooling and can have instantaneous updates once again. You quote Python examples around data processing (an appropriate niche use-case for perf-oriented implementations), but then your final line is actually about build tooling. The problem here is that things like esbuild are written to support dysfunction. Javascript-written build tooling build "reasonable" projects very fast. The dependency bloat in the NPM ecosystem is well-documented, and the actual level abstraction complexity of apps/frameworks/projects is also commonly considered to be excessive. This leads to slow builds, slow apps, and low maintainability/debuggability. Solving the first of those problems in isolation "supports dysfunction" in that it makes the latter problems less likely to be solved. It's especially bad when that solution comes with further maintainability/debuggability compromises.

cercatrova 4y ago
Slow tooling, slow runtime, it's all the same to me, I want fast programs. Not sure what you mean by esbuild written to support dysfunction, could you elaborate on why that's the case? If you mean that well-developed JS-made tooling can be on par with esbuild and similar, I will have to disagree as benchmarks show that compiled languages like Go and Rust are orders of magnitude faster, and whatever architectural improvements can be made in the JS-made tooling can also be made in these compiled-languages' tooling as well.
- lucideer 4y ago
  Writing software in a fast language -vs- whatever quick-to-write-/maintainable-/domain-specific-/sandboxed-/etc. language is always some kind of compromise of perf. vs whatever your other priorities are. In particular, writing tooling for a language in that language will have massive advantages in terms of contributors, but may have perf. drawbacks if that language is not as performant as alternatives. Weighing up those pros & cons is important - the performant option is not always the best, it depends on your priorities. Performance generally increases in priority depending on how much of a bottleneck it is. If webpack takes 0.2 seconds and esbuild would take 0.02 seconds, that's a 10x perf. gain but is probably not a compelling reason to switch. If webpack is taking 20 seconds however, that's a bottleneck that's worth looking at. My point above is that an app that takes 20 seconds for webpack to build is overengineered in the most common cases - taking that badly written app and running it through esbuild to "fix" your problem isn't really fixing your problem, it's just hiding it under the bed. This is what's called "supporting dysfunction". Numpy, pandas, scipy are poor comparators because they're processing data, not code: they're tasks that depend on data scale, rather than on how many over-abstracted layers of code someone is trying to compile all at once. The former is not (necessarily) a sign of dysfunction. It's much more likely to be a valid use-case.

cercatrova 4y ago

Slow tooling, slow runtime, it's all the same to me, I want fast programs. Not sure what you mean by esbuild written to support dysfunction, could you elaborate on why that's the case? If you mean that well-developed JS-made tooling can be on par with esbuild and similar, I will have to disagree as benchmarks show that compiled languages like Go and Rust are orders of magnitude faster, and whatever architectural improvements can be made in the JS-made tooling can also be made in these compiled-languages' tooling as well.

lucideer 4y ago
Writing software in a fast language -vs- whatever quick-to-write-/maintainable-/domain-specific-/sandboxed-/etc. language is always some kind of compromise of perf. vs whatever your other priorities are. In particular, writing tooling for a language in that language will have massive advantages in terms of contributors, but may have perf. drawbacks if that language is not as performant as alternatives. Weighing up those pros & cons is important - the performant option is not always the best, it depends on your priorities. Performance generally increases in priority depending on how much of a bottleneck it is. If webpack takes 0.2 seconds and esbuild would take 0.02 seconds, that's a 10x perf. gain but is probably not a compelling reason to switch. If webpack is taking 20 seconds however, that's a bottleneck that's worth looking at. My point above is that an app that takes 20 seconds for webpack to build is overengineered in the most common cases - taking that badly written app and running it through esbuild to "fix" your problem isn't really fixing your problem, it's just hiding it under the bed. This is what's called "supporting dysfunction". Numpy, pandas, scipy are poor comparators because they're processing data, not code: they're tasks that depend on data scale, rather than on how many over-abstracted layers of code someone is trying to compile all at once. The former is not (necessarily) a sign of dysfunction. It's much more likely to be a valid use-case.