3 ms·

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

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.

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.