You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Opening this discussion to explore how tooling might work in a batteries-included, polyglot-style runtime. In a world where your runtime can speak multiple dialects, and has built-in tools like a bundler/package manager/test runner/etc, how do those work?
In a software engineer's day, or a software component's lifecycle, several tools might be touched or used to various degrees. Roughly, in terms of frequency of use:
Language server
Formatters, linters, static analyzers, type checkers
Test runner
Debugger
Package managers
Coverage tooling / reporting
Profiler
Good tooling is often praised as the best part of a good language. By improving the developer's tooling on a polyglot-first basis, we will be offering features which are meaningful in a developer's day and while staying in a valuable area: most of these tools do not exist how they should yet.
Approach
I think we should survey current approaches and lessons learned in other runtimes, and then propose some options along the lines of user customizability / load-from-deps (the way Node or Python do this), vs. built-in best-of-breed tools (a-la Bun, Rust, et al).
Goals
Smooth tooling experience in Elide, which covers major use cases in all supported languages
Ideally, embedded into the runtime in some way ("batteries included")
But without bloating the runtime or locking the user to specific tooling in any unreasonable way
Non-goals
Development of new tooling specific to each language
Prior Art/Relevant Material
GraalVM's Tooling
GraalVM has a notion of tools which work with Truffle. There are several tools which are available to integrate into Elide (some of which already are integrated into Elide):
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Summary
Opening this discussion to explore how tooling might work in a batteries-included, polyglot-style runtime. In a world where your runtime can speak multiple dialects, and has built-in tools like a bundler/package manager/test runner/etc, how do those work?
In a software engineer's day, or a software component's lifecycle, several tools might be touched or used to various degrees. Roughly, in terms of frequency of use:
Good tooling is often praised as the best part of a good language. By improving the developer's tooling on a polyglot-first basis, we will be offering features which are meaningful in a developer's day and while staying in a valuable area: most of these tools do not exist how they should yet.
Approach
I think we should survey current approaches and lessons learned in other runtimes, and then propose some options along the lines of user customizability / load-from-deps (the way Node or Python do this), vs. built-in best-of-breed tools (a-la Bun, Rust, et al).
Goals
Non-goals
Prior Art/Relevant Material
GraalVM's Tooling
GraalVM has a notion of tools which work with Truffle. There are several tools which are available to integrate into Elide (some of which already are integrated into Elide):
Extended Tooling
Certain libraries or instrumentation tools exist for further construction of tools:
Beta Was this translation helpful? Give feedback.
All reactions