Live data from Hacker News

Rewriting the Ruby parser

railsatscale.com

171–180 of 182 posts

Re: Rewriting the Ruby parser

#171

Earlier quoted context omitted.

It sounds like the novel idea was thinking to do that in the first place

"Use a more performant serialization format" is hardly novel. It's why things like protobuf exist.

lol what do you want here. "ok you're right, the approach that worked is bad we should have waited for the astute technical insight of an anonymous internet commenter two decades later." you got it bud A++ are you looking for work you seem delightful.

Re: Rewriting the Ruby parser

#172

Earlier quoted context omitted.

> “getting a large Rails app booting ” What does ‘booting’ exactly mean in the context of a web app (Rails)?

The Rails initialization process is commonly called "booting", probably owing to the presence of the config/boot.rb file. It's the loading and execution of code necessary before a request can be processed. Beyond the code that Rails executes, it generally includes the loading of most, if not all, of your application's dependencies and any initialization they may require. In my experience, the Rails boot stage account…

When do you think Shopify will be running its rails on in production on Truffle?

Also, any thoughts on the recent license change of GraalVN?

Re: Rewriting the Ruby parser

#173

Earlier quoted context omitted.

The Rails initialization process is commonly called "booting", probably owing to the presence of the config/boot.rb file. It's the loading and execution of code necessary before a request can be processed. Beyond the code that Rails executes, it generally includes the loading of most, if not all, of your application's dependencies and any initialization they may require. In my experience, the Rails boot stage account…

When do you think Shopify will be running its rails on in production on Truffle? Also, any thoughts on the recent license change of GraalVN?

I can't commit to a timeline, but can say the work is progressing nicely. I plan to blog more about it as we have details to share.

The GraalVM commercial license change seems like a positive change to me. But, I'm not a lawyer and I'm not speaking on behalf of Shopify. To me, it looks to be in keeping with how the Oracle JVM is licensed and I think that simplifies a lot. The commercial version has some really nice improvements for the native binary and that's been mostly closed off to Rubyists.

Re: Rewriting the Ruby parser

#174

It’s little appreciated how much current parser generators are holding the industry back. That is, LISP maintains a lead in metaprogramming because it bypasses Chomskyism alltogether. It really should be a few lines of code to add an “unless(X) {}” statement to “if(!X) ()” to Java, Python, Ruby but the very idea that you could patch an existing grammar with a separate file is like technology that fell off a UFO. Also…

The difficulty isn't `unless(x) {}`, it's `{} unless(x)` and `{} if(x)`. Except you also don't have the brackets to keep things organized.

Do you mean semicolons and whitespace?

Re: Rewriting the Ruby parser

#175
post #147

Earlier quoted context omitted.

If you find it, i am interested. But it seems to be a topic that is still open to research and niche to a small group of devs

I suspect that most of the knowledge on this topic is embedded in source code of most prominent compiler tool chain and the head of their dev. :( I think they might an interesting intersection here we ML, where can could learn the comment mistake pattern made by real user and either error correct better, or at least provide pin point accurate error messages.

Not really no.

Re: Rewriting the Ruby parser

#176

It’s little appreciated how much current parser generators are holding the industry back. That is, LISP maintains a lead in metaprogramming because it bypasses Chomskyism alltogether. It really should be a few lines of code to add an “unless(X) {}” statement to “if(!X) ()” to Java, Python, Ruby but the very idea that you could patch an existing grammar with a separate file is like technology that fell off a UFO. Also…

[deleted]

Re: Rewriting the Ruby parser

#177

Earlier quoted context omitted.

The difficulty isn't `unless(x) {}`, it's `{} unless(x)` and `{} if(x)`. Except you also don't have the brackets to keep things organized.

Do you mean semicolons and whitespace?

No, I mean that in the examples of difficult to parse lines there are no {} anywhere and no () on the condition.

  def save = File.write(name, self.to_yaml) unless invalid?
and you could also have

  def save = File.write(name, self.to_yaml) if valid?
If you had to bracket the expression that postfix if/unless applies to, it would be significantly easier to parse.

Re: Rewriting the Ruby parser

#178

Earlier quoted context omitted.

>Hard to believe, but in that case i would say that you are comparing libraries, not the languages. No, you're not, because comparable libraries in C++ to do many activities, such as at-scale stream processing, simply do not exist in C++.

> many activities I do not doubt that there are domain where the best libraries are in a particular language, and this language might not be C++. I am just not convince that java is better than C++ with this regard. (as they are more domain where the best C++ is faster than best java one). But i think that's beside the point, we are comparing language here, so the existing/quality of characteristics of libraries shou…

What value is there in that exercise? We never use a given programming language outside of a given task/context. Comparing them absent that is navel gazing.

Re: Rewriting the Ruby parser

#179

Earlier quoted context omitted.

"Use a more performant serialization format" is hardly novel. It's why things like protobuf exist.

lol what do you want here. "ok you're right, the approach that worked is bad we should have waited for the astute technical insight of an anonymous internet commenter two decades later." you got it bud A++ are you looking for work you seem delightful.

I'm not sure why you're so upset over this. All I've done is point out that some people put a ton of work into a great deal of engineering effort to solve a problem that would have been trivially solved by merely using a different choice of serialization format. Even 10 years ago the technology to do so was widely available and standardized.

But I mean sure, WOOHOO, what a great achievement!

Re: Rewriting the Ruby parser

#180

Earlier quoted context omitted.

It is a lie to say java is faster than c/c++ due to runtime optimization It is also a lie to say java is "quite slow" compare to c/c++

> It is also a lie to say java is "quite slow" compare to c/c++ Why ?

Since no one is replying to your actual question:

The JVM takes bytecode and generates assembly for execution. It also profiles that code and improves it over time.

Sometimes long running java bytecode will be faster than statically compiled C++. In many/most cases, long running Java code on good JVM will reasonably close to C++ for some measures of "reasonable".

Garbage collection pauses, memory usage, JVM startup/warmpup is all more detrimental to Java in the speed comparison.

But "quite slow" basically, to me, implies it is 10-100x slower than C++. Sure you can come up with various benchmarks (lies, damn lies, and benchmarks) to make some corner case.

In general, the JVM is probably about 2-3x slower than C++ compiled code. It certainly is not "quite slow".

Post reply on HN