Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rome Tools, Inc.

rome.tools

Post reply on HN
Print view View original

51–60 of 90 posts

Re: Announcing Rome Tools, Inc.

#51

Post by austincheney »

Oddskar wrote: post #38
austincheney wrote: post #29

Earlier quoted context omitted.

> I have no doubt that Rome will massively increase the producitvity of thousands of companies and developers I would like to see that measured. My suspicion is that many developers are already too reliant on tooling and that reliance harms productivity rather than improves it. Bundling those tooling concerns eliminates some operational costs associated with a plurality of tools but increases dependency upon the tool…

I think you're being very selective with what you call "tooling" here. I understand where it's coming from though, and I agree that in some circumstances people are adhering too much to what might be perceived as "standards" instead of building or using something more fit to the task. On the contrary I would also say that I see a lot of developers not being reliant enough on tooling. A simple example is getting very…

I mean tooling as generally as possible, everything outside your application's execution runtime and the shell it runs in. Of course developer's will benefit from a code editor and a language compiler (assuming there aren't many), but how much tooling do you really need to deliver a product?

Re: Announcing Rome Tools, Inc.

#52

Post by sebastianmck »

throwaway91_82 wrote: post #31
ruffrey wrote: post #9

Earlier quoted context omitted.

Healthy skepticism is good. Dev tools are hard. There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out. JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.

this team also has had at least one example of unilateral non-open source decisionmaking https://www.vice.com/en/article/pawnwv/open-source-devs-reve...

The Rome license will stay MIT.

Re: Announcing Rome Tools, Inc.

#53

Post by threatofrain »

throwaway91_82 wrote: post #31
ruffrey wrote: post #9

Earlier quoted context omitted.

Healthy skepticism is good. Dev tools are hard. There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out. JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.

this team also has had at least one example of unilateral non-open source decisionmaking https://www.vice.com/en/article/pawnwv/open-source-devs-reve...

Linus is probably a tie-breaker, and thus a unilateral decision maker for Linux when necessary too. What's the problem?

Re: Announcing Rome Tools, Inc.

#54

Post by SahAssar »

jillesvangurp wrote: post #36
anaclet0 wrote: post #34

I thought Rome was a Facebook internal project. Am I missing something here?

It's also a java framework for parsing RSS and Atom. I bet that there are more ways that lead to Rome :-)

This is that facebook project though (not just the same name), see here: https://github.com/rome/tools/blob/main/website/src/blog/pos...

Seems like the author could take it with him when leaving facebook, which is nice.

Re: Announcing Rome Tools, Inc.

#55

Post by Aken »

RcouF1uZ4gsC wrote: post #33
ruffrey wrote: post #9

Earlier quoted context omitted.

Healthy skepticism is good. Dev tools are hard. There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out. JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.

> There are hundreds of open source companies - many making gobs of money. [citation needed] It seems there may be many open source companies with tons of users, but they seem to struggle with monetization and turning those users into paying users. Redhat which used to be the epitome of a company making money from open source got acquired by IBM. A lot of other open source companies are switching to non-open source l…

https://www.forbes.com/sites/glennsolomon/2020/09/15/monetiz...

Re: Announcing Rome Tools, Inc.

#56

Post by swyx »

FractalHQ wrote: post #49
pier25 wrote: post #40

Any news on plugin support (eg: Svelte)?

This was my first thought as well. More and more devs are beginning to discover Svelte as a milestone in the evolution of Javascript. I would be surprised if it wasn’t already on the roadmap.

second vote for Svelte support here - i'd hate for a next-gen tool like Rome to only support React when there are other great frameworks that it could handle

Re: Announcing Rome Tools, Inc.

#57

Post by thiht »

cpojer wrote: post #4
yewenjie wrote: post #3

Earlier quoted context omitted.

Why do you think this is the only bet? What about things like Snowpack, Vite, and Esbuild?

Those are all great bundlers/dev servers but they aren’t as ambitious as Rome. Rome aims to be the one tool that handles everything: compiling, bundling, testing, linting and everything else.

And it will be the one tool that handles everything poorly. Linting (eslint) and testing (jest) are solved problems, there's no way I'll migrate to Rome for these. They should focus on bundling which is the current pain point (although my bet is more on esbuild).

Re: Announcing Rome Tools, Inc.

#58

Post by Touche »

orta wrote: post #37
tsdlts wrote: post #25

After using esbuild and experiencing fast builds, I'll never go back to tools written in javascript/typescript again.

FWIW, sucrase (written in TypeScript) has done a great job of being in the same ordinal of perf as esbuild: https://github.com/alangpierce/sucrase#sucrase

That's single threaded perf, so takes away a huge advantage of Go. Also doesn't include startup time (node is slow to start)

Re: Announcing Rome Tools, Inc.

#59

Post by serverholic »

Touche wrote: post #58
orta wrote: post #37

Earlier quoted context omitted.

FWIW, sucrase (written in TypeScript) has done a great job of being in the same ordinal of perf as esbuild: https://github.com/alangpierce/sucrase#sucrase

That's single threaded perf, so takes away a huge advantage of Go. Also doesn't include startup time (node is slow to start)

And memory usage.

Re: Announcing Rome Tools, Inc.

#60

Post by jeroenhd »

devit wrote: post #42

Being written in TypeScript and not Rust seems quite a big liability that might see Rome never be popular or lose out quickly due to inferior performance. There is already RSLint and SWC as JavaScript tools written in Rust and I would expect such tools to take over, with a good choice of it happening before Rome is ready.

I don't see the relevancy of rust here, but you're right that at this point any language that compiles directly to machine code will blow any javascript tool out of the water any time.

Of course, perf is only one reason to use a tool, I expect javascript based tooling to stick around for much longer because developers are used to them now. And, of course, if all you know is frontend, everything starts to look like a javascript job.

Post reply on HN