doppp
Born on February 28, 2014•26032 Karma
So it's been in the works for quite some time
EDIT: And for that mater, the YT channel: https://www.youtube.com/@HighNorthStudios/videos
You are better off allowing your overworked neural pathways some much-needed rest.
Yes, public transit is not a necessity here like in the States, but it's a nice convenience to have, and plenty of people are wealthy enough to pay for it.
When we optimize Ruby for performance we debate how to eliminate X thousand heap allocations. When people in Rust optimize for performance, they're talking about how to hint to the compiler that the loop would benefit from SIMD.
Two different communities, two wildly different bars for "fast." Ruby is plenty performant. I had a python developer tell me they were excited for the JIT work in Ruby as they hoped that Python could adopt something similar. For us the one to beat (or come closer to) would be Node.js. We are still slower then them (lots of browser companies spent a LOT of time optimizing javascript JIT), but I feel for the relative size of the communities Ruby is able to punch above its weight. I also feel that we should be celebrating tides that raise all ships. Not everything can (or should be) written in C.
I personally celebrate any language getting faster, especially when the people doing it share as widely and are as good of a communicator as Aaron.
The claim that Ruby YJIT beats this is not supported by the data to put it mildly:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (scroll down on each submission and you will see it uses YJIT)
(and Go is not a paragon of absolute performance either)
The whitepapers that inspired Ruby's JIT was first tested against a saner subset of JS, and shown to have some promising performance improvement. The better language/JIT compatibility is why the current Ruby JIT is actually showing performance improvements over the previous more traditionally designed JIT attempts.
JS can get insanely fast when it's written like low level code that can take advantage of its much more advanced compiling abilities; like when it's used as a WASM target with machine generated code. But humans tend to not write JS that way.
Agreed about Go as well, it tends to be on the slow side for compiled languages. I called it out not as an example of a fast language, but because it's typical performance is well known and approximately where the upper bound of how fast Ruby can get.
The author was eventually hired to develop YJIT.
What does this mean? Any JIT can make a tight loop of math and arrays run well but that doesn't mean a typical program runs well.
So basically, writing code similarly to a statically typed compiled language.
https://programming-language-benchmarks.vercel.app/amp/pytho...
Is there somewhere with benchmarks that supports the idea that Ruby is faster than Python?
Tcl had it’s web moment during the first dot com era within AOLserver.
However exactly because of the experience writing Tcl extensions all the time for performance, since 2003 I no longer use programming languages without JIT/AOT other than for scripting taks, or when the decision is external.
The founders at our startup went on to create OutSystems, with many of the learnings, but using .NET instead, after we were given access to .NET during its "Only for MSFT partners eyes" early state.
Of course. This is why you go to a university to learn to analyze the evidence for a claimed statement as scientifically as possible instead of practicing hero worship.
kakistocracy, kakistocrat.
I still chuckle when I recall this tweet, "OKRs were actually a psyop from Google to slow down potential early stage competitors" [1].
Other companies, buying into the marketing smokescreen that they were a "highly competitive tech company" and not a search monopoly figured that 'cargo culting' their OKR process would help obtain the super-profits of they craved.[3]
The statements of departing Googlers during the successive waves of layoffs in '23 and '24 supported the hypothesis that GOOG suffered from having people just meeting their OKRs for products no one wanted or needed, and without any external guidance of profitability or customer feedback.
Just say no to OKRs. They won't give your company the monopoly it wants.
[1] Thiel, P https://www.youtube.com/watch?v=rFZrL1RiuVI
[2] The obvious failures: https://killedbygoogle.com/
[3] If Google does it, it must be part of their recipe for success! https://blog.maxjahn.at/analysis/unveiling-the-ghosts-of-tec...