|
|
|
|
|
|
by octref
2323 days ago
|
|
|
One take away for me was: Language designers & compiler writers today need to consider editor support as one of their goals. On the top page there's another thread about rust-analyzer vs RLS. What Aleksey said[0] about RLS that "[RLS's] current architecture is not a good foundation for a perfect IDE long-term," feels similar to my coworker's conclusion in her effort to provide better editor support for PHP[1]. Parsers for compiling code into machine-executables vs parsers to serve LSP responses have different tradeoffs. For example, Anders mentioned TS parser need to have good error-recovery, can respond with completions/errors when one file changes inside a thousand-files-project. I vaguely remember TS had a goal to provide completions in < 50ms and errors in <150ms. Such goals are hard to achieve as after-thought. If your core compiler doesn't do error recovery, such as PHP, you need someone to write a new compiler from scratch for a language server implementation. If tools such as RLS rely on compiler to dump all JSON metadata and figure out LSP responses[0], it's too slow for editors. TS's good editor support doesn't come free. I think one of the most under-appreciated achievement of TS is how it took editor support seriously and designed its compiler infrastructure to do it well. That's why I don't believe in those hot-new-web-languages that try to take over TS by designing a better type system. TS brought the average developer's expectation of a language to having fast completion, fast error reporting, editor autofix, F2 to rename and renaming-a-file-in-editor-to-update-all-references. It's 2020 and people aren't going back to write code like in Notepad. [0]: https://ferrous-systems.com/blog/rust-analyzer-2019/ [1]: https://github.com/microsoft/tolerant-php-parser --- EDIT: grammar. |
|
|
In a way this is very intuitive: a programming language is a kind of a UI for the language's runtime. The IDE is just another UI layer on top of that.