On the other hand, Yarn is written in JS and it is considered fast enough. Facebook has a good track record for writing well designed tools.
Having written codebases that take a couple of minutes to compile, it seems like a bit of a waste to write a whole new full-stack-no-dependencies compiler in a language that can't be parallelised.
You can usually get behind a self-hosting compiler for language evolution purposes, but for JS there is zero value in having yet another project to try it out on. For a transpiler to work on itself, maybe, but Rome is a CLI tool, not a web bundle, so it will never need to exercise the most demanding features of a transpiler/bundler. JSX, minification, code splitting, async loading, legacy browser support, etc. You can innovate on those things in any other language just as easily.
At the end of the day, the only advantage is that people who want to contribute will already know the language. Is that important enough to deal with another ten years of slow JS transpilation, forcing people to run huge, un-optimised code blobs in development (real life, very annoying problem), and 800MB node processes? I don't see that changing in JS-world for a long time.
(This is snarky, but you might actually be better off without importing the unfortunate churn habits of the JS community.)
If you need to optimize certain parts of your runtime or your toolchain once it's correct and does what it's supposed to and you can call the solution set understood, that's one thing. But until it is, defaulting to something that isn't self-hosting is bad for your prospects of community building.
Why this level of hatred for Go?
And I would never say that that is an indefensible viewpoint. If I was selecting tools for people who are not me and people who I don't think I can effectively train and coach and lead into being better at what they're ostensibly here to do, I might even advocate for it. But I am not afraid of being too clever for myself. In production capacities, you should be prevented from being too clever by this through the taste that you should have developed as a practitioner of the craft of software development (and your code reviewers should be backing you up on if you don't have that yet). And in exploratory capacities, being too clever should be encouraged--because that's how you become good at your job in the first place.
I believe that, instead of throwing up our hands and just stapling a high-cut filter on programming as a craft, one can and should build better systems that actually use the computer to do the tedious tasks involved in making sure that you've actually expressed solutions to problems in a clear and reliable way. Tools that do exactly what I described do exist; along very different axes, both TypeScript (structurally typed and with really flexible and easily expressed generics) and Rust (lower-level borrow-checker B&D but with a raft of niceties to soften the blow; "good C++ with a great IDE" ends up here too, though there's a lot of bad C++ too) scratch exactly that itch for me.
Those tools (and others, in greater or lesser measure) reward me for thinking deeply about a problem. My reward is being saddled with less and clearer code to deal with in the future. And that's amazing! On the other hand, I have felt, each and every time I have been stuck using it, that by leaving any questions of difficulty to the programmer to handle a bunch of e-janitor stuff--bad error handling, really embracing its actually-just-Java-1.4-self by not supporting generics, etc.--Golang just wastes my time. I end up with more code that's harder to read and is better able to conceal errors both of omission and commission. Golang punts the solving of the actually hard problems of software craftsmanship to the programmer and I resent that. It should be helping me, not fucking off with the job half-done.
Don't get me wrong: I don't begrudge others its use, except when I'm stuck using it because of previous choices made, but it's the only programming language in common use that makes me feel bad to use it. (Which is to say that yeah, there are worse, but I don't exactly have to deal with them.) To me, the repelling effect is strong enough that it really is one of two languages (hi, PHP) on my under-no-circumstances list.
Golang is not a "simple language", though. C# is a simple language, and while it sometimes frustrates me its decisions make sense. Golang is a simplistic language. There is value in being simple; there is little value in being simplistic.
You don't have to use Rust or Go to use a tool written in it.
As an example, I've written custom TSLint plugins before. I'm not writing those in Rust.
There's a lot of wisdom in sticking to your lingua franca until you prove you can't.
Just like most Emacs functionalities are written in Emacs-lisp, and most Elixir functionalities are written in Elixir. It's more consistent for open source projects, and people would be more familiar and motivated when building and consuming at the same time.
I’m not sure what other examples to use to describe the tone I’m referring to without offending anyone. But, I’d personally be really interested in an anthropologist writing about the internet culture of JS development. Edit: hackernews unsurprisingly did not let me use an emoji at the end there.
Keep the emojis and witty copy coming, I say.
Again, like others said it's more likely you are just upset about the emoji.
It is refreshing though seeing somebody trying to tackle some of my gripes about JS from a clean slate. I get so tired of hearing of x tool just to use some CSS lib or JS lib, or 17 tools to make development better and they all fight each other.
I like that every new cohort grows thru rejection and rebellion. Graffiti, bleached hair, ripped jeans, cathartic music, emoji, or whatever.
Source: Former punk, now almost a gray beard.
I've been really looking forward to this source release since reading your tweets about it. Sorry it got posted to HN before you wanted it to, but thanks for making the code public at this stage.
I think so, in the same way that people use both Babel and TypeScript (or Flow) today. TypeScript/Flow check the types, while Babel simply strips them out when compiling the code.
> Supporting those "compilers" is just supporting their syntax, which both fortunately already have very good compliance test suites because other tools like Babel already reimplement their syntax anyway.
It was all added in the first commit 45 mins ago. Why would they hide their commit history?
Also I found this funny - comments in package.json:
"//": "Look! No deps!",
"///": "Only used for static type checking",
I'm the only author at the moment. The project started off years ago as a side project without any commit history, and what little history there was over the years wasn't very thorough. Prior to the open sourcing I've been working on it internally and still did pretty massive diffs that changed thousands of files, still without good history. It's something I'm working on though and will obviously need to be accountable for now that the project is public.
It would be interesting to see examples of specific such advantages that could be gained, because I'm having a hard time thinking of any.
1. Everything you seem to be asking for seems like it is not relevant at this point in the project's lifecycle.
2. IMO people who are capable of providing good contributions don't actually need what you are asking for. They can review the README as is, review the source code, etc.
In short, patience.
Two days later I got a one-star review on the now-defunct cpanratings site complaining about the lack of documentation.
Personally, HN would be my go-to if I had a project to show and for which I was hoping for some high-quality collaboration.
If by 'reaching directly out' you mean contacting specific people, then it shouldn't be a public repo. Like I said, it's under a Facebook org, of course others will find it.
Rome is not a collection of existing tools. All components are custom and use no third-party dependencies.”
A transpiler is a type of compiler, so it's fine to just call it a "compiler".
Also the readme is doing a good job for answering my doubt at a first glance - why a Corinthian helmet rather than a Roman one :)
> Rome has a logo of an ancient Greek spartan helmet. It's not very relevant since it's not Roman, but it looks cooler than a Galea.
In the .NET world 99% of the code is compiled with csc (or whatever it's called, don't remember that well)
In the C world, with one of the biggest ecosystems and a fragmented history going back half a century, 99% of the code is compiled with GCC/Clang/VS CL (of which VS CL is there just because Microsoft insists on it being there).
Similar things happen with interpreters, CPython, Yarv, etc.
Until that level takes the problem of in-browser, persistent file/blob storage seriously, the JS ecosystem will not be able to truly progress, particularly when it comes to the question of linking evolving code bases with more stable libraries. But I digress. (I'm not going to "pimp" for my project now... see my comments!)
However, that will likely require more than 24 hours (ba-dum-tss)
edit: well, looks like they took down the offending tweets, but I can link out to this discussion: https://github.com/yarnpkg/berry/issues/766
The other point is, why is Rome better than any existing tooling ? Webpack, typescript, prettier, eslint, mocha are all pretty popular and mature tools. Why would I use Rome over it ?
“Galea” links to the much cooler Roman helmet, disproving this statement. Also given that this is a build environment, perhaps an icon incorporating, I dunno, a Roman building might be appropriate?
[disclaimer, I am a big Haxe fanboy]
> Transparency. No back-channel project management. Project conversation and decisions will take place only on public forums such as GitHub, the Rome Discord, and Twitter. The only exception to this is moderation decisions which will be strictly done in private.
The whole document is full of good ideas. I still want more, but that's a league better than many "top" projects I use.
This is because, unlike the historical Rome, this Rome may fall in a day.
This seems enormously (and needlessly?) ambitious. Why not just bundle up the standard tools in a ready-to-use package?
Rome is a bet that by integrating disparate systems that need to perform many overlapping tasks, you can make a better whole.
I know from experiences in the last few days that even things like standardjs and xo, despite being described as zero-config linting/fixing solutions, don't reliably work out of the box.
The Webpack babel-loader just calls Babel with the source code, it doesn't reuse Webpack's AST: https://github.com/babel/babel-loader/blob/master/src/index....
It has to do it that way, since Babel could parse some syntax that Webpack doesn't recognise (like Flow or TypeScript annotations). Webpack loaders can even take non-JS input and produce JS output (eg. "svgr" takes SVG images and produces React components) so I don't think Webpack can even assume that the input is JS at that point.
Edit: Facebook wrote Buck and uses it extensively internally, so there being a desire for compatibility doesn’t seem far-fetched.
Unlike Oracle, Facebook has embraced the OSS community adopting their tech, and hasn't wielded the patent threat ever.
His quip about Oracle was completely irrelevant to the content of his comment. In my opinion, Facebook proved themselves champions of OSS when they relaxed their license on React (which is now vanilla MIT with no stupid patent clauses).
Except a patent clause actually gives you more protection, not less. That's why some other licenses explicitly include a patent grant, like the Apache license. I think the patent clause was a misunderstanding more than anything else. In any case, Facebook responded to what the community wanted.
Why should anyone contribute to projects that have a completely different philosophy from what they would write? I doubt that the authors of those three projects would welcome any PR removing all dependencies of their tools with or merging all 3 tools into one.
Also, what's the problem with creating new things and fostering competition and advancing the state of our profession? Why is experimenting so frowned upon by some people here in Hacker News?
By the way, the author of Rome is also the author of Babel. So I guess he has made his share of Pull Requests.
Throwing all the baby out with the bath water is something engineers consistently overvalue in business when there are other middleground trade-offs to choose from.
> Considering this is just a source code dump and call for possible contributors I'm disappointed it was even posted to Hacker News. Rome is not ready at all for public consumption. I wanted it open sourced so I could work with other tooling authors and contributors.
Those things you are asking will come at a time when Rome is actively being marketed as a tool for users rather than an experimental project for contributors.
Of course you can. Compiling is a process that takes some code as input and produces other code as output. The output code doesn't have to be at a lower level of abstraction (like assembly or machine code).
I know of what I speak. I am in the process of turning the world of web development upside down with Linux on the Web (https://dev.lotw.xyz/desk.os).