141–150 of 182 posts
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 ?
Earlier quoted context omitted.
> Too much implicit magic, too much memorization, too opaque to tools that might help overcome those first two problems. If you are a senior level Rails developer none of this is true except maybe memorization and that seems to be a pre-requisite for any senior engineer in any language. It's trivial to debug rails applications with debugger and reading the underlying source code. Everything you need to solve problems…
If you're having to poke around in running code to find out WTF some symbol even is and where it comes from, and that's not a very uncommon thing to have to do, that's unacceptable IMO. > that seems to be a pre-requisite for any senior engineer in any language In many languages and language-ecosystems, there's little point to memorizing e.g. method names and signatures that you're not using so often that memorization…
I see this people complain about this but I don't understand why. First of all I've seen highly competent engineers complain about methods in Rails that exist from basic inheritance in Ruby. A concept that they probably learned when they were 10 years old. This is how object-oriented code is written. Pretty much every game is written the same way. Yes the dynamic methods that are generated can be annoying, but not what I see people complain about.
Second, they're trying to code a language like Ruby in a text editor and complain. If you tried to write Java or Scala in a text editor you would also have a bad time. So, yea I don't get it to be honest.
Earlier quoted context omitted.
I'm a bit surprised that Github isn't doing work on Ruby, since they're probably the largest RoR deployment
A lot of ex-Hubbers went to Shopify. Additionally, a lot of upstream commits to Rails occurred from things pulled out of GitHub. GitHub has (had?) an entire team dedicated to Ruby and Rails and performance and optimizations/improvements
Earlier quoted context omitted.
GraalVM Ruby, more commonly known as TruffleRuby, is actively developed still. As the article states, it adopted YARP already.
My understanding is that Shopify still hasn’t been able to migrate to Graal/TruffleRuby, even after 10-years of its development.
As you might imagine, there's a lot more to production deployments than simple Ruby compatibility. At Shopify, we've recently modified our CI system to support TruffleRuby and are actively running projects against TruffleRuby in CI now [1]. The TruffleRuby 23.0.0 release coming out in the next day or so includes quite a few compatibility issues we've worked out getting a large Rails app booting. That project is on the order of months, not decades.
YARP will make adoption of TruffleRuby easier. Absent a language specification, implementations like JRuby and TruffleRuby have to match what CRuby is shipping and that by necessity means they lag after CRuby releases. Parser changes are amongst the hardest things to port over. YARP eliminates most of the challenges there.
[1] -- https://railsatscale.com/2023-06-12-truffleruby-in-shopify-c...
Disclaimer: I'm on the TruffleRuby team at Shopify.
Earlier quoted context omitted.
I'd say that C and C++ were successful despite their being hard to parse, and other unfortunate hacks, like null-terminated strings and include files instead if modules There was little choice for other features they offered (like Unix being written in C and bundling a C compiler) which.were the compelling reason to use them. JavaScript was a huge success not because it was a great language, but because everyone want…
I think you and I are saying essentially the same thing: grammatical complexity seems to have little negative impact on language success. > There was little choice for other features they offered (like Unix being written in C and bundling a C compiler) which.were the compelling reason to use them. Pascal was around at the same time, is grammatically infinitely more elegant... and is dead.
Earlier quoted context omitted.
My understanding is that Shopify still hasn’t been able to migrate to Graal/TruffleRuby, even after 10-years of its development.
Your phrasing could be misconstrued by those not familiar with the history. Shopify hasn't been developing TruffleRuby for 10 years. The entire TruffleRuby project is 10 years old, including the first 12 - 18 months where it was a humble intern project. TruffleRuby (previously called JRuby+Truffle) was initially a research project for testing out optimizations, not a production-quality implementation suitable for dep…
What does ‘booting’ exactly mean in the context of a web app (Rails)?
While on the subject, anybody has good reference on parsing error recovery ?
Earlier quoted context omitted.
> Disclaimer : my career has mainly been on compiler/runtime and other infrastructure related stuff, so not much of a business logic/web dev kind of guy. That probably explain your surprise. This question comes up extremely often on HN, the answer is that even if you were to stop all feature development, re-platforming a large organization like Shopify would take years, not even considering all the re-training, lost…
> re-platforming a large organization like Shopify would take years I am not sure what re-platforming means here, but "slowly transitioning" to a different stack is not the same as stop and rewrite everything. > That probably explain your surprise While i don't write "business logic", i have been involved in a lot of project to babysit, maintain, refactor and/or improve business code bases. Sometime the runtime can o…
Given that I work on the Ruby Infrastructure team at Shopify, I think I have a well informed view on both the cost of transitioning and the operating burden.
With the mention of the parser's performance, I am reminded of Rich Kilmer's 2004 RubyConf presentation. Rich used Ruby to test reliability of a distributed system with hundreds of Java VMs. Some of the serialized data was stored as XML (over 1M lines!), which was slow to parse and load. Rich modified the program to serialize the data as Ruby code, which loaded much faster ( https://www.infoq.com/news/2007/06/infoq-i…
>Some of the serialized data was stored as XML (over 1M lines!), which was slow to parse and load. Rich modified the program to serialize the data as Ruby code, which loaded much faster So he took a data format designed for human readability and converted it to a data format that's designed purely to be read by Ruby and people are surprised that it's faster?