[HN Gopher] Announcing Rome Tools, Inc.
___________________________________________________________________
Announcing Rome Tools, Inc.
Author : sebastianmck
Score : 171 points
Date : 2021-05-04 16:00 UTC (7 hours ago)
(HTM) web link (rome.tools)
(TXT) w3m dump (rome.tools)
| devit wrote:
| 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.
| valyagolev wrote:
| no, much worse. they might actually win by overspending on
| marketing and feature-bloat, and we'll be stuck working with
| slow tools
| intergalplan wrote:
| Yeah, I'm over here going, "oof, I hope they don't do _too_
| well by burning VC cash, or they might stifle esbuild and
| deno and similar efforts, and we 'll remain stuck at this
| embarrassingly-low local maximum even longer"
| valyagolev wrote:
| what else would VC money be for other than a sweet vendor
| lock-in?
| jeroenhd wrote:
| 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.
| serverholic wrote:
| I'd prefer my tools to use languages that are compiled +
| memory safe. Basically that just leaves rust or go.
|
| But rust also has other features that can help prevent bugs
| regarding concurrency and more. So rust is a feature in my
| book and not just an implementation detail.
| mssundaram wrote:
| > _compiled + memory safe. Basically that just leaves rust
| or go_
|
| If you mean compiled && memory safe then that leaves just
| Rust, and not Go.
| serverholic wrote:
| Is go not compiled and memory safe?
| ruffrey wrote:
| It's a difficult, painful problem - meaning there's an
| opportunity. Sebastian has the grit to deliver. What's the
| business model?
| sebastianmck wrote:
| Supplemental services that integrate with the tool. Think code
| quality monitoring, error reporting, and core enhancements like
| a remote cache. There's a lot we're going to be experimenting
| with.
| inglor wrote:
| I'd pay for fast remote builds that integrate into my source
| control (GitHub and Azure DevOps) and creates production
| builds fast.
| gremlinsinc wrote:
| Rome sounds awesome but the branding confused me for a second...
|
| I was trying to find out how this relates to
| https://roamresearch.com/
|
| I guess phonetically my mind was flipping things around.
| [deleted]
| cpojer wrote:
| The JavaScript tooling ecosystem is fragmented, bloated and slow.
| Rome is the best - and currently only - bet to fix this. I'm
| excited!
| yewenjie wrote:
| Why do you think this is the only bet? What about things like
| Snowpack, Vite, and Esbuild?
| swyx wrote:
| bad examples - the better one is Deno.
| cpojer wrote:
| 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.
| inglor wrote:
| You can also do that with Deno: - Built in testing library
| - Lint with `deno lint` - Bundle with `deno bundle` -
| Format with `deno fmt`
| thiht wrote:
| 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).
| capableweb wrote:
| Where is the company incorporated? In most countries, companies
| act for profits first. Especially if you raise funding from a few
| selected ones instead of the wider community.
|
| This statement reads weird too
|
| > We don't believe in placing artificial constraints on the tool
| or having functionality behind a paywall. In order to support the
| open source project, we'll be building supplemental products and
| services. This aligns our incentives with the community and our
| open source users, with a focus on interoperability, performance,
| and usability.
|
| Supplemental products and services on top of open source projects
| often require (down the line) the open source project to adapt
| because it might hurt the bottom line of these supplemental
| products and services. Since there is no guarantee this won't
| happen, if the stake is between the company surviving or a
| feature being open-source vs "supplemental", the people working
| at the company might have to chose the option against the wishes
| of their open source users. I don't see how creating a for-profit
| company is at all in alignment with open source users. Better
| would have been a Co-op, a non-profit, OpenCollective, or
| leverage an existing entity like the Linux foundation, that can
| actually guarantee it for you in contracts and laws.
| redisman wrote:
| https://xkcd.com/927/
| pier25 wrote:
| Any news on plugin support (eg: Svelte)?
| FractalHQ wrote:
| 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.
| swyx wrote:
| 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
| coward76 wrote:
| Can someone tell me how this is different than something like
| webpack?
| abc11283 wrote:
| This question is answered literally on the front page of their
| website.
| anaclet0 wrote:
| I thought Rome was a Facebook internal project. Am I missing
| something here?
| jillesvangurp wrote:
| It's also a java framework for parsing RSS and Atom. I bet that
| there are more ways that lead to Rome :-)
| SahAssar wrote:
| This is that facebook project though (not just the same
| name), see here: https://github.com/rome/tools/blob/main/webs
| ite/src/blog/pos...
|
| Seems like the author could take it with him when leaving
| facebook, which is nice.
| yuchi wrote:
| Parent comment was talking about _this_ specific Rome
| project. And he is indeed right, it _was_ a Facebook project
| at the earliest stage, but moved out of it when Seb left FB.
| throwaway91_82 wrote:
| possibly sensitive question - i recall Sebastian and Kyle had
| their differences during the ICE issue of 2018
| https://www.vice.com/en/article/pawnwv/open-source-devs-reve...
|
| what are Rome's intended policies on OSS licensing and usage by
| ICE?
| abc11283 wrote:
| I think there's a difference between "objectionable
| organizations" using what is available as OSS, and them being
| allowed on the platform that the company intends to develop.
| abc11283 wrote:
| Disclaimer: I know the foundation of Rome was largely written by
| Sebastian. This question still applies to Rome though, but more
| so to "open source companies" in general.
|
| https://rome.tools/credits/
|
| How many of these people are going to receive an employment
| opportunity from this company? How many will receive equity?
|
| I suppose the same questions can be asked if any big project,
| like React, though that had FB's backing from the get-go.
|
| I understand that OSS needs funding from somewhere, and I am
| incredibly optimistic about Rome, but I'd think it a bit
| disheartening to be surprised by this announcement as a
| contributor.
| [deleted]
| sebastianmck wrote:
| I've been keeping the core contributor team updated on the
| funding process since December. We've also been publicly
| speaking about it in the Rome Discord server too. I posted
| about securing funding in early April in #general.
|
| Emanuele and Yasser both approached us during this period to
| offer their interest in joining and have stayed actively
| involved in development.
|
| It's a good question around how to compensate the shoulders of
| the giants you're standing on, and I don't think anyone has a
| good answer for that. I think it's important to note that the
| credits page is meant to be as exhaustive as possible. I am not
| aware of many other projects that have something similar, and
| theirs are likely to be even longer.
|
| In the end the community is getting value because we'll now be
| able to do more to improve the project than we otherwise would
| have. Babel most notably has struggled for funding and is even
| currently undergoing a serious funding shortage. It has been
| used as one of the poster children for the JS community and
| it's clear that donation-based funding isn't effective, at
| least on the order of magnitude required to support a team.
| abc11283 wrote:
| I appreciate the thoughtful reply. I should've added that
| I've seen your commitment to transparency through the whole
| process, so the info about Discord doesn't really come as a
| surprise. Thanks and good luck!
| swyx wrote:
| thats not how OSS contributions work. you contribute of your
| own free will, they don't owe you any equity or employment. of
| course you'd have a leg up on hiring but they don't owe you a
| thing.
| abc11283 wrote:
| I know how OSS works. I just think the transition from being
| a community-oriented project, to one that will create a lot
| of value for a small group of people, will be interesting to
| watch.
|
| They certainly deserve any and all success, I just wonder how
| those decisions will be made.
| lacker wrote:
| This is pretty exciting! I'm glad to see more investment going
| into the JavaScript developer tooling ecosystem.
|
| Some of the open source companies have had an easier time
| monetizing than others. Databases, for example, have a somewhat
| obvious path nowadays of offering a hosted version. NPM and
| Docker, on the other hand, developed incredibly popular tools but
| struggled to monetize. So I'm curious to see what Rome will do.
|
| The other interesting question to me is what Rome will focus on.
| There's a really wide array of things in the JS toolchain and
| it's tempting to boil the ocean. How much of it can you really
| boil? Running a nice JS browser stack of course. Supporting
| TypeScript I presume. How about Node on the backend? An Electron
| app? All of those in the same codebase?
|
| Some tough decisions here but I'm glad the team working on them
| is set to grow and attack this problem. Good luck Romans ;-)
| SamBam wrote:
| This feels like a new version of Brunch.
|
| Did anyone use Brunch to build and bundle JS projects and manage
| dependencies? It seemed like the best thing since slice-bread at
| the time.
|
| I recently had to go back and update a 6-year-old project that
| had been written using Brunch. It took several days of painful
| work to extract it all out of the framework and built it using
| Babel.
|
| All I'd want to know with Rome is, if and when I abandon it or it
| gets abandoned (whichever happens first), how annoyed am I going
| to be that I had chosen this framework? How seamless will it be
| to extract my project?
| betterfaster wrote:
| I think the future of JavaScript tooling is esbuild and SWC,
| written in fast compiled languages like Go and Rust. I don't see
| the value proposition in a brand new toolchain written in slow
| and memory hungry TypeScript/JavaScript.
| pictur wrote:
| you are right but the most common tools are still made with
| these. I think people don't worry about performance that much.
| or worry, but they don't make an effort to change that.
| jillesvangurp wrote:
| I had a quick look at how they are set up and I like what they
| are doing from the point of view of actually creating an OSS
| community. I don't actually know much about what they do as I'm
| not one of their users. Judging this purely from a "does this
| make sense as an OSS company" point of view.
|
| - License: MIT. Great pragmatic choice. Generally a good fit for
| not obstructing your users to actually use, copying, modifying,
| etc. your code. Too many OSS startups play games with this and
| end up going for something too restrictive. IMHO not having
| copyright transfers is the key to longevity for any OSS
| community. It basically progressively removes re-licensing as an
| option as more contributors would have to agree to such a thing.
| Most long lived oss projects have long lists of contributors and
| no history of license changes past an early stage of their
| development. Also, MIT is very compatible with just about
| anything in the ecosystem. Given their stated goal of being good
| OSS citizens, that's a hard requirement.
|
| - Contributing.md: no mention of copyright transfers. Also they
| have close to twenty contributors. I assume this means the
| license will stay as it is and there are no plans to change that.
| Great! This is key to building a successful open source community
| with people actually contributing as well as using the code. It
| also ensures the code can survive acquisitions, bankruptcies,
| mismanagement of the company, etc. Committing to this upfront is
| important and a big step.
|
| - Community: There are seventeen contributors, most of which are
| not employees (I assume). And they probably integrate a lot of
| other libraries/tools.
|
| - Explicit stated goal that affirms the above: "The company
| exists to support the open source project, not the other way
| around.".
|
| That does raise a few question marks around valuation and ways to
| profit from this. I'm curious about their plans for adding value
| in the form of services on top of this. I assume this means some
| cloud based services and/or support contracts with consultancy.
| But then, it's good to remove the nuclear option (relicensing)
| from the table early on to create clarity for developers and
| investors that this is just not that sort of company.
|
| It's smart from a business point of view as well because most of
| what they do will come from outside the company anyway. The
| nature of the javascript community is people rapidly iterating on
| tools, libraries, etc. and forking left right and center as
| needed. So, a lot of value is going to be added through people
| doing exactly that. You can work with them or against them. With
| them is the smarter option.
| greshario wrote:
| > License: MIT.
|
| Virtually all open source projects in the web dev community are
| MIT licensed, especially when it comes tooling. Choosing any
| other license would cause a lot of friction and prevent
| adoption.
| no_wizard wrote:
| Isn't Apache-2.0 also considered easy going?
| tsdlts wrote:
| After using esbuild and experiencing fast builds, I'll never go
| back to tools written in javascript/typescript again.
| [deleted]
| orta wrote:
| 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
| lhorie wrote:
| Sucrase "cheats" though[0]:
|
| > Sucrase bypasses most of these steps, and works like this:
| Tokenize the input source code into a token stream using a
| trimmed-down fork of the Babel parser. This fork does not
| produce a full AST, but still produces meaningful token
| metadata specifically designed for the later transforms.
|
| While this is fine for simple transformations like
| transpiling JSX, it's not very suitable for full-on AST
| analysis like some eslint plugins do. Most notoriously,
| Sucrase is specifically designed to be garbage-in-garbage-
| out, whereas Babel will throw proper errors on things like
| early errors.
|
| Tools written in lower level languages like esbuild can take
| advantage of facilities that aren't well supported in Node,
| such as cheap concurrent coroutines and greater control over
| memory layout (Babel ASTs are notoriously megamorphic and can
| silently fall off perf cliffs depending on how you manipulate
| them). These caveats are not reflected in Sucrase's
| benchmark.
|
| [0] https://github.com/alangpierce/sucrase#motivation
| Touche wrote:
| That's single threaded perf, so takes away a huge advantage
| of Go. Also doesn't include startup time (node is slow to
| start)
| serverholic wrote:
| And memory usage.
| blocked_again wrote:
| > Together, we're announcing that we've raised $4.5 million in
| seed funding, led by A.Capital Ventures and OSS Capital.
|
| VCs fund startups which has the potential to 100x their returns
| right? How is that going to work here? How will they monetize a
| javascript library? Will we have an IPO for a javascript library?
| Or are they betting on a big tech company to acquire a Javascript
| library for 100s of millions of dollars? I am confused.
| lhorie wrote:
| Over at r/javascript, Sebastian mentioned the business model
| would be based on providing services. He mentioned things like
| code quality monitoring and remote cache, so it sounds like
| it's up the alley of CI/CD cloud platform offerings.
|
| Does seem like quite a departure from the original premise of
| Rome, but it seems like a sensible strategy. FWIW many
| companies easily spend 6-7 figures on CI/CD per year, so
| there's definitely room to carve out a niche there.
| yawnxyz wrote:
| I really hope they don't start charging $1 for every time I
| install Babel through npm.....
| ruffrey wrote:
| 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.
| throwaway91_82 wrote:
| 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...
| sebastianmck wrote:
| The Rome license will stay MIT.
| vosper wrote:
| Is it a given that because the software is open-source, the
| decision-making will be, too? Almost seems there should be
| a separate set of claims for what the decision-making
| process will be (like how there are various software
| licenses).
| ipsum2 wrote:
| From the article:
|
| > Eric Raymond, the founder of the Open Source Initiative
| and one of the authors of the standard-bearing Open
| Source Definition, said Kyle's decision violated the
| fifth clause of the definition, which prohibits
| discrimination against people or groups.
| spenczar5 wrote:
| Okay, so the issue wasn't decision-making, then, and you
| agree with the parent comment that open source need not
| have open decision-making?
| threatofrain wrote:
| Linus is probably a tie-breaker, and thus a unilateral
| decision maker for Linux when necessary too. What's the
| problem?
| RcouF1uZ4gsC wrote:
| > 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 licenses.
| javamonn wrote:
| OSS Capital, which participated in the Rome Tools, Inc
| round, has compiled a list which includes commercial open
| source companies, revenue estimates, and how much VC
| raised: https://docs.google.com/spreadsheets/d/17nKMpi_Dh5s
| lCqzLSFBo...
| Aken wrote:
| https://www.forbes.com/sites/glennsolomon/2020/09/15/moneti
| z...
| gjhr wrote:
| 34 billion dollars doesn't count as gobs of money?
| ttul wrote:
| Even though a company's software might be open source, the
| company does own the intellectual property of the open
| source project. It chooses what license under which the
| software should be offered and has the freedom to
| commercially exploit the software in ways that nobody else
| can.
|
| That being said, a compiler toolchain is not so easily
| monetized as something like Grafana, which has obvious
| enterprise features that need filling in and which can be
| hosted as a cloud service, generating revenue that way.
|
| I imagine the team has ideas for monetization, otherwise
| they would not have raised $4.5M from some top shelf
| venture capitalists. I would like to know what those ideas
| are.
| Philip-J-Fry wrote:
| Compiler As A Service obviously. I'm half joking.
| polote wrote:
| > In order to support the open source project, we'll be
| building supplemental products and services. This aligns our
| incentives with the community and our open source users, with a
| focus on interoperability, performance, and usability.
|
| like every open source company, they will sell additional
| services to companies. When you have millions of users you
| always find a way to monetize it, even if you think you are
| just a "javascript library". Redis is just a database, Word is
| just a text processor, ...
| amasad wrote:
| It's not a "JavaScript library" it's an entire toolchain. In
| the same way that `git` generated billions of dollars worth of
| value in the form of companies and productivity, Rome will do
| the same. Possibly even bigger.
| ehutch79 wrote:
| git doesn't make linus torvalds money though.
|
| People used git because it was mandated for linux kernel
| work.
| jakeva wrote:
| To your second point, I remember when git was announced. I
| remember it was such a breath of conceptual fresh air over
| what I had been using (svn, mercurial) for me. I use it
| because it makes a lot more sense to me and how I work, and
| I've never worked on the linux kernel.
| nytgop77 wrote:
| never used it, but afaik mercurial is basically git's
| doppelgannger - functionally they are identical. Am I
| wrong here?
| arthurcolle wrote:
| No, doppelganger seems like a pretty incorrect term to
| choose here.
|
| http://www.rockstarprogrammer.org/post/2008/apr/06/differ
| enc...
| blocked_again wrote:
| I have no doubt that Rome will massively increase the
| producitvity of thousands of companies and developers. But
| the hard thing in open source is how will you capture some
| portion of that value. The vast majority of libraries,
| toolchains and other open source projects out there which has
| massively increased the developer producitivty are
| underfunded let alone generate millions of dollars in sales.
| Rome not only has to find a sustainable way for funding the
| project as well as figure out a way to 100x the returns of
| VCs? How is Rome planning to do that?
| austincheney wrote:
| > 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.
|
| This problem is not a technical problem (as in how do I
| solve a problem), but a cultural problem (as in what is the
| proper way to solve a problem). It comes down to the
| difference between a product focus (what do we ship) versus
| an operational focus (what do we work on).
| Oddskar wrote:
| 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 acquainted with the
| debugger in your language of choice. It 's very common to
| sprinkle logs everywhere instead of properly learning how
| to step through code.
| austincheney wrote:
| 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?
| sbarre wrote:
| > How is Rome planning to do that?
|
| Clearly they have a vision that investors thought was
| compelling enough to buy into.
|
| Perhaps be patient and see what they announce in the
| future? This is their day one (zero?)..
|
| If there was an easy answer here, someone else would have
| already done it.
|
| edit: they (sort of) answer in another thread
| https://news.ycombinator.com/item?id=27039330
| blocked_again wrote:
| Yeah. I geuinely hope they work it out. And hopefully
| more open source projects can follow their playbook.
___________________________________________________________________
(page generated 2021-05-04 23:01 UTC)