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.
Rewriting the Ruby parser
171–180 of 182 posts
Re: Rewriting the Ruby parser
#172Earlier 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…
Also, any thoughts on the recent license change of GraalVN?
Re: Rewriting the Ruby parser
#173Earlier 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?
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
#174It’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.
Re: Rewriting the Ruby parser
#175Earlier 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.
Re: Rewriting the Ruby parser
#176It’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…
Re: Rewriting the Ruby parser
#177Earlier 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?
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
#178Earlier 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…
Re: Rewriting the Ruby parser
#179Earlier 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.
But I mean sure, WOOHOO, what a great achievement!
Re: Rewriting the Ruby parser
#180Earlier 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 ?
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".