4 ms·

I think tools for a programming language should be written in the said programming language if possible. Rome developers will not use Rome to develop Rome, and

I think tools for a programming language should be written in the said programming language if possible. Rome developers will not use Rome to develop Rome, and the Rome users are less likely to contribute because they are more likely web developers and not familiar with Rust.

nicoburns 5y ago
That's a nice ideal, but esbuild has managed to reduce build times 100x by building JS tooling in Go. Given how widely used JS it, the amount of time that would be saved by faster tools in this area is humungous.
- dmix 5y ago
  esbuild is also basically becoming the new standard, taking the crown from Webpack.
  - hunterb123 5y ago
    ESbuild currently replaces Babel in most workflows. Webpack is still used as the bundler. My current gripe is the lack of Babel macros support in ESbuild. I need them for translations. Afaik ESbuild does not have macros.
- christophilus 5y ago
  I jumped from C# to Ruby to JS/TS to Go easily. Rust has taken a lot longer to learn. Today, if I need a statically compiled binary, I use Go, simply because I can crank out a solution quickly. My point is that Go seems like a reasonable choice, if you want to easily onboard developers who are familiar with JavaScript. I don't think Rust would be as accessible.
  - Zababa 5y ago
    I personally find Rust easier than Go. The compiler helps more, rust-analyzer is way better than the Go language server, the Rust docs are great, package management is better, and the richer type system means that it's usually easier for me to "glue the types" in my head to know what I need to do. Of course that's not universal, some people will find Go easier, some will find something else easier. But my point is just that some people will find Rust accessible.
  - nicoburns 5y ago
    I wonder if perhaps your OOP background is holding you back with regards to Rust. I see this quite a lot in /r/rust. People from a c#/Java background struggling. I personally learnt Rust quite quickly and easily coming from a JS background. There was some new stuff to learn, but the Book covered that well, and what I consider idiomatic JS - lot's of functional iterator chains, minimal mutation, duck typing, etc - translated into Rust pretty much 1:1. Cargo is also familiar to the JS dev, and the availability of high quality libraries means that a beginner Rust dev doesn't need to learn the most complex parts until later.
    - christophilus 5y ago
      I learned OCaml, Erlang, and Clojure easily enough. I generally prefer a functional style, so i don’t think that’s it. Haskell and Rust are the two most difficult languages I’ve learned. That said, Rust has come a long way in terms of ergonomics.
- deleted 5y ago
  [deleted]
- lhorie 5y ago
  esbuild is the current darling leading the pack, but there are also various other projects in the space (swc[0] is written in Rust, fjb[1] is written in C, bun[2] is written in zig, leveraging JavascriptCore's engine). The most significant performance-oriented effort in this space still leveraging JS that I know of is kataw[3], and while that's quite fast compared to babel, it's still within an order of magnitude from babel. Kataw itself is a CST-based implementation that was created to outperform seafox (a AST-based parser by the same developer), which itself is an iteration over several other perf-oriented parser projects. Babel gained popularity due to the crazy amount of churn in grammar over the past few years, but more and more I think the dust is settling, and flexibility is no longer the name of the game, making an AST-based implementation less appealing. The Rome team must be feeling the heat if the data structure design choices are being informed by performance. I highly doubt someone will be able to compete in performance using a JS implementation in today's landscape. [0] https://github.com/swc-project/swc https://github.com/swc-project/swc [1] https://github.com/sebbekarlsson/fjb https://github.com/sebbekarlsson/fjb [2] https://bun.sh/ https://bun.sh/ [3] https://github.com/kataw/kataw https://github.com/kataw/kataw
  - yewenjie 5y ago
    Is there a benchmark and comparison of these new tools somewhere?
- kuberlog 5y ago
  There is a big difference between writing in Go vs Rust. Any intermediate/advanced webdev will feel competent in Go in a matter of days. This is definitely not true with rust.
whimsicalism 5y ago
Disagree - I think mypy for python and esbuild for js are great examples of why this is not always the case.
judge2020 5y ago
Maybe so for small languages/projects, but it won't matter if it gets popular enough. Some of the biggest languages like Python and PHP still have their core components written in C, as opposed to some 'write the core in our language then create a transpiler'. I'm sure speed being the focus instead of DX (developer experience) will be appreciated by all the people that won't ever touch Rome except as an end-user.
Jtsummers 5y ago
> I think tools for a programming language should be written in the said programming language if possible. This is a popular sentiment which I've never understood. Should all JS tools be written in JS? What if you already have an 80% solution written in F# thanks to some other work that can be reapplied to JS, should that solution be rewritten? Should we have IDEs predominantly written in their target language?
- mynegation 5y ago
  In a twist of irony, the most popular IDE for Rust is written in Typescript (but of course powered by rust-analyzer, written in Rust)
javajosh 5y ago
I tend to agree, but in this case I think it's okay. The runtime of the web (the primary target of most js today) is a very different animal to more traditional runtimes. It is a "gooey" place and highly specialized and just...weird. What other environment pulls components and data from around the world at runtime? It's also tempting to think that Rust is just better than Javascript for the web too, and you can target the browser with a WASM bundle. I think that's wrong, too. The developer story in the web is weird, but it works and you give up a lot by using WASM. I also think from a societal standpoint (un-obfuscated) Javascript is the healthier choice, since it lets people learn from each other. So, basically: yes, Rome, a dev tool, will be written in Rust, and it will help people write better Javascript, and that's okay.
ironmagma 5y ago
As a JS developer, I don’t trust the users of the ecosystem enough to develop the tools properly in JS.
Zababa 5y ago
I think that's actually one of the sweet spots of Rust. I find it way more accessible to web devs, while C++ is scary for me. This in turn allows you to have very performant tools that are easily distributed as a single binary. Go has the same qualities, as ESBuild proved. Both also can be compiled to WASM, so that makes the distribution even easier.
fabiospampinato 5y ago
Are you saying that we should have a JS-based JS engine in browsers? Sometimes performance is more important than hypothetical additional external contributions.
- paxys 5y ago
  A JS engine in a browser isn't built for JS developers but rather every web user. A better example would be the TypeScript compiler, which is written in TypeScript and still very fast.
  - fabiospampinato 5y ago
    I'd argue the JS engine in browsers is _also_ built for JS developers, and even though we are definitely a minority compared to all the internet users it's important to underline that most of the stuff currently available online, for better or for worse, wouldn't exist without developers writing it. Like the average user in fact couldn't care less about what languages websites are written in, but if browsers shipped only a brainfuck compiler I'm sure there would be a lot less development happening on the web, in some sense JS developers are the target users of JS engines. I think this is literally the first time that I hear anybody saying that TypeScript is very fast. It's no coincidence that the top open issue in Deno's repo is literally titled "TypeScript compiler in Rust" [0]. The developer behind swc is even rewriting the whole type checker in TypeScript [1]. A lot of people, myself included, think that TS can get excruciatingly slow, in a large-enough but not really huge codebase, in a way that probably wouldn't happen if it were written in something like Rust with a big focus on performance. [0] https://github.com/denoland/deno/issues/5432 https://github.com/denoland/deno/issues/5432 [1] https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571
okamiueru 5y ago
Any project / tool should be written in the language most suited for the problem, while also pragmatically factoring in prior experience of those who would do said work. Is there really a significant overlap between programming tooling usage, and development of the programming tools? The case where I see most rampant abuse of this is npm/node commandline tools. Written in/for an environment because it is mostly used by people in that environment, and not because it is particularly suited for it. If it wasn't for docker, all those tools would be tied to a exceptionally messy runtime, and wasted effort. They also won't be included in any normal distribution either. It makes any tool written in node to come across as an amateurish and hacked together attempt. Regardless of how well and robust it is. I'm sure there are good reasons for it, beyond my understanding, since node is something I've always avoided due to red flags all around. But, I digress. If the memory and runtime model isn't suited for the requirement of the tool, and language doesn't allow for a paradigm that matches well with the problem domain... You've picked the wrong language.
marcosdumay 5y ago
If a language goal is not to support language parsers, what good does it do if you write your parser in it? It certainly does not benefit from the extra focus the developers dogfooding the language will bring. On the other hand, there is a real chance that the dogfooding will be harmful and make the language lose focus. If it's goals do not include a good systems interface, the same applies. And Javascript's goals don't include either.
CodeIsTheEnd 5y ago
This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world. Using Rust promises performance and stability, key features for the thousands of engineers that will be running Rome as a critical part of their workflow. The vast majority of those developers would prefer that the tool runs faster and has fewer errors over having a lower barrier to entry for contributing. "Contributing" may also encompass the plugin/extensibility ecosystem around the tool, and can be closely tied to the underlying implementation language. This functionality has been integral to the growth of things like Babel and Webpack, but it seems in this case Rome is trying to replace much of that very ecosystem. I there are some toolchains that may prioritize "barrier of entry to contributions" -- new languages, or niche communities for example -- but I don't think it's an appropriate priority for a toolchain for a massively popular established programming language with $4.5 million in funding [1]. [1]: https://rome.tools/blog/announcing-rome-tools-inc/ https://rome.tools/blog/announcing-rome-tools-inc/

nicoburns 5y ago

That's a nice ideal, but esbuild has managed to reduce build times 100x by building JS tooling in Go. Given how widely used JS it, the amount of time that would be saved by faster tools in this area is humungous.

dmix 5y ago
esbuild is also basically becoming the new standard, taking the crown from Webpack.
- hunterb123 5y ago
  ESbuild currently replaces Babel in most workflows. Webpack is still used as the bundler. My current gripe is the lack of Babel macros support in ESbuild. I need them for translations. Afaik ESbuild does not have macros.
christophilus 5y ago
I jumped from C# to Ruby to JS/TS to Go easily. Rust has taken a lot longer to learn. Today, if I need a statically compiled binary, I use Go, simply because I can crank out a solution quickly. My point is that Go seems like a reasonable choice, if you want to easily onboard developers who are familiar with JavaScript. I don't think Rust would be as accessible.
- Zababa 5y ago
  I personally find Rust easier than Go. The compiler helps more, rust-analyzer is way better than the Go language server, the Rust docs are great, package management is better, and the richer type system means that it's usually easier for me to "glue the types" in my head to know what I need to do. Of course that's not universal, some people will find Go easier, some will find something else easier. But my point is just that some people will find Rust accessible.
- nicoburns 5y ago
  I wonder if perhaps your OOP background is holding you back with regards to Rust. I see this quite a lot in /r/rust. People from a c#/Java background struggling. I personally learnt Rust quite quickly and easily coming from a JS background. There was some new stuff to learn, but the Book covered that well, and what I consider idiomatic JS - lot's of functional iterator chains, minimal mutation, duck typing, etc - translated into Rust pretty much 1:1. Cargo is also familiar to the JS dev, and the availability of high quality libraries means that a beginner Rust dev doesn't need to learn the most complex parts until later.
  - christophilus 5y ago
    I learned OCaml, Erlang, and Clojure easily enough. I generally prefer a functional style, so i don’t think that’s it. Haskell and Rust are the two most difficult languages I’ve learned. That said, Rust has come a long way in terms of ergonomics.
deleted 5y ago
[deleted]
lhorie 5y ago
esbuild is the current darling leading the pack, but there are also various other projects in the space (swc[0] is written in Rust, fjb[1] is written in C, bun[2] is written in zig, leveraging JavascriptCore's engine). The most significant performance-oriented effort in this space still leveraging JS that I know of is kataw[3], and while that's quite fast compared to babel, it's still within an order of magnitude from babel. Kataw itself is a CST-based implementation that was created to outperform seafox (a AST-based parser by the same developer), which itself is an iteration over several other perf-oriented parser projects. Babel gained popularity due to the crazy amount of churn in grammar over the past few years, but more and more I think the dust is settling, and flexibility is no longer the name of the game, making an AST-based implementation less appealing. The Rome team must be feeling the heat if the data structure design choices are being informed by performance. I highly doubt someone will be able to compete in performance using a JS implementation in today's landscape. [0] https://github.com/swc-project/swc https://github.com/swc-project/swc [1] https://github.com/sebbekarlsson/fjb https://github.com/sebbekarlsson/fjb [2] https://bun.sh/ https://bun.sh/ [3] https://github.com/kataw/kataw https://github.com/kataw/kataw
- yewenjie 5y ago
  Is there a benchmark and comparison of these new tools somewhere?
kuberlog 5y ago
There is a big difference between writing in Go vs Rust. Any intermediate/advanced webdev will feel competent in Go in a matter of days. This is definitely not true with rust.

whimsicalism 5y ago

Disagree - I think mypy for python and esbuild for js are great examples of why this is not always the case.

judge2020 5y ago

Maybe so for small languages/projects, but it won't matter if it gets popular enough. Some of the biggest languages like Python and PHP still have their core components written in C, as opposed to some 'write the core in our language then create a transpiler'. I'm sure speed being the focus instead of DX (developer experience) will be appreciated by all the people that won't ever touch Rome except as an end-user.

Jtsummers 5y ago

> I think tools for a programming language should be written in the said programming language if possible. This is a popular sentiment which I've never understood. Should all JS tools be written in JS? What if you already have an 80% solution written in F# thanks to some other work that can be reapplied to JS, should that solution be rewritten? Should we have IDEs predominantly written in their target language?

mynegation 5y ago
In a twist of irony, the most popular IDE for Rust is written in Typescript (but of course powered by rust-analyzer, written in Rust)

javajosh 5y ago

I tend to agree, but in this case I think it's okay. The runtime of the web (the primary target of most js today) is a very different animal to more traditional runtimes. It is a "gooey" place and highly specialized and just...weird. What other environment pulls components and data from around the world at runtime? It's also tempting to think that Rust is just better than Javascript for the web too, and you can target the browser with a WASM bundle. I think that's wrong, too. The developer story in the web is weird, but it works and you give up a lot by using WASM. I also think from a societal standpoint (un-obfuscated) Javascript is the healthier choice, since it lets people learn from each other. So, basically: yes, Rome, a dev tool, will be written in Rust, and it will help people write better Javascript, and that's okay.

ironmagma 5y ago

As a JS developer, I don’t trust the users of the ecosystem enough to develop the tools properly in JS.

Zababa 5y ago

I think that's actually one of the sweet spots of Rust. I find it way more accessible to web devs, while C++ is scary for me. This in turn allows you to have very performant tools that are easily distributed as a single binary. Go has the same qualities, as ESBuild proved. Both also can be compiled to WASM, so that makes the distribution even easier.

fabiospampinato 5y ago

Are you saying that we should have a JS-based JS engine in browsers? Sometimes performance is more important than hypothetical additional external contributions.

paxys 5y ago
A JS engine in a browser isn't built for JS developers but rather every web user. A better example would be the TypeScript compiler, which is written in TypeScript and still very fast.
- fabiospampinato 5y ago
  I'd argue the JS engine in browsers is _also_ built for JS developers, and even though we are definitely a minority compared to all the internet users it's important to underline that most of the stuff currently available online, for better or for worse, wouldn't exist without developers writing it. Like the average user in fact couldn't care less about what languages websites are written in, but if browsers shipped only a brainfuck compiler I'm sure there would be a lot less development happening on the web, in some sense JS developers are the target users of JS engines. I think this is literally the first time that I hear anybody saying that TypeScript is very fast. It's no coincidence that the top open issue in Deno's repo is literally titled "TypeScript compiler in Rust" [0]. The developer behind swc is even rewriting the whole type checker in TypeScript [1]. A lot of people, myself included, think that TS can get excruciatingly slow, in a large-enough but not really huge codebase, in a way that probably wouldn't happen if it were written in something like Rust with a big focus on performance. [0] https://github.com/denoland/deno/issues/5432 https://github.com/denoland/deno/issues/5432 [1] https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571

okamiueru 5y ago

Any project / tool should be written in the language most suited for the problem, while also pragmatically factoring in prior experience of those who would do said work. Is there really a significant overlap between programming tooling usage, and development of the programming tools? The case where I see most rampant abuse of this is npm/node commandline tools. Written in/for an environment because it is mostly used by people in that environment, and not because it is particularly suited for it. If it wasn't for docker, all those tools would be tied to a exceptionally messy runtime, and wasted effort. They also won't be included in any normal distribution either. It makes any tool written in node to come across as an amateurish and hacked together attempt. Regardless of how well and robust it is. I'm sure there are good reasons for it, beyond my understanding, since node is something I've always avoided due to red flags all around. But, I digress. If the memory and runtime model isn't suited for the requirement of the tool, and language doesn't allow for a paradigm that matches well with the problem domain... You've picked the wrong language.

marcosdumay 5y ago

If a language goal is not to support language parsers, what good does it do if you write your parser in it? It certainly does not benefit from the extra focus the developers dogfooding the language will bring. On the other hand, there is a real chance that the dogfooding will be harmful and make the language lose focus. If it's goals do not include a good systems interface, the same applies. And Javascript's goals don't include either.

CodeIsTheEnd 5y ago

This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world. Using Rust promises performance and stability, key features for the thousands of engineers that will be running Rome as a critical part of their workflow. The vast majority of those developers would prefer that the tool runs faster and has fewer errors over having a lower barrier to entry for contributing. "Contributing" may also encompass the plugin/extensibility ecosystem around the tool, and can be closely tied to the underlying implementation language. This functionality has been integral to the growth of things like Babel and Webpack, but it seems in this case Rome is trying to replace much of that very ecosystem. I there are some toolchains that may prioritize "barrier of entry to contributions" -- new languages, or niche communities for example -- but I don't think it's an appropriate priority for a toolchain for a massively popular established programming language with $4.5 million in funding [1]. [1]: https://rome.tools/blog/announcing-rome-tools-inc/ https://rome.tools/blog/announcing-rome-tools-inc/