I start to have less love for technical pride languages and love business backed languages like Ruby more. It also means wide ranges of library, more jobs. Great or elegant niche languages put me in bad position so far. (Also sick of developer complex)
Ruby 3.2’s YJIT is Production-Ready
231–240 of 304 posts
Re: Ruby 3.2’s YJIT is Production-Ready
#232Earlier quoted context omitted.
> by many accounts Oracle makes the fastest database I've never seen that credibly claimed. Why would their license ban benchmarking if their performance was any good?
Their licensing does not ban benchmarking; it only bans publishing the results. A subtle but important point. By all means, run benchmarks on your workload profile and choose the technology that works best for you - that is perfectly OK. But not make claim that xxx beats oracle in yyy. Oracle goal here is to make a good enterprise ready DB solution; not to fight the open-source community on hundreds of different perf…
> Oracle goal here is to make a good enterprise ready DB solution
Maybe. Or maybe it's to soak naive clients for all they're worth. The remedy for bad benchmarks is good benchmarks, not no benchmarks.
> Just look at the « independent and fair review » that Top Gear made about Tesla.
What about it? It was accurate and informative (unless you think Tesla lied about their range stats). The good points about electric cars are real but they don't mean we should ignore the downsides.
Re: Ruby 3.2’s YJIT is Production-Ready
#233Earlier quoted context omitted.
The README states "TruffleRuby runs Rails". Anything specific?
It passes most (maybe all?) of the Rails test suite. But it can't run a randomly-selected production Rails application. This was based on my conversations with Chris Seaton before his passing, about 6 months ago.
That doesn’t sound like a very good test suite then.
Re: Ruby 3.2’s YJIT is Production-Ready
#234I start to have less love for technical pride languages and love business backed languages like Ruby more. It also means wide ranges of library, more jobs. Great or elegant niche languages put me in bad position so far. (Also sick of developer complex)
I'm with you on this as I get older. 'Been fascinated with Clojure for years but now sick of being out in the cold/on the fringe as it hasn't really converted into anything which brings home the bacon so I've turned to Java and Javascript lately. Will even do PHP if necessary if it means more paid work as a solo dev.
Re: Ruby 3.2’s YJIT is Production-Ready
#235Earlier quoted context omitted.
Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify. (Rest in peace, Chris, and may your memory be a blessing to those who knew you)
Looks like it’s still a WIP https://github.com/oracle/truffleruby/commits?author=eregon
With due respect to the tireless efforts of the TruffleRuby team TruffleRuby always seemed fated to be forever almost ready. I first came across it in 2013, I think it was, but there was always a not-quite-ready factor. If I remember the show-stopper was that it was unlikely to ever be Rails compatible but I may be wrong.
Re: Ruby 3.2’s YJIT is Production-Ready
#236Earlier quoted context omitted.
I don't know if I'm just a bad programmer and everyone knows something I don't, but it seems to be the benefits of a strongly typed language are wildly overblown. It's a different way of thinking about building software and it saves you from a few mistakes you could otherwise make, but you'd think I was writing code with a hammer and chisel the way people on HN talk about languages like Ruby. It feels a lot like the…
Its all guts, feels, and "everybody knows" - but afaik there's been no hard proof about statically typed languages being superior to dynamically typed ones, or vice versa.
To me, it’s as much of a preference as text editor or spaces vs. tabs.
Re: Ruby 3.2’s YJIT is Production-Ready
#237It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.
This thread on Rubyists' impressions of the gradual typing options is relevant: https://www.reddit.com/r/ruby/comments/105sdax/whats_the_lat...
Spoiler alert: not a lot of fans
Re: Ruby 3.2’s YJIT is Production-Ready
#238Glad to see Ruby still going strong it will forever be the 1st programming language I actually loved working with, and the combination of it with Rails was amazing. Had to move to the other side (Typescript, Django) but I think unless ChatGPT will write all the code 10 years from now - Rails and Ruby will still be there, providing teams with a lot of power and a lot of fun.
Funny that you say that. If AI writes code, it should be Ruby, because it's shorter and easier to read. I'm making a site and love ChatGPTs Ruby code.
PS: Any Microsoft people here? Ruby could be 10x faster on Windows, if we figure out how to load files faster! https://bugs.ruby-lang.org/issues/19325#note-11
Re: Ruby 3.2’s YJIT is Production-Ready
#239Earlier quoted context omitted.
> Moving away from CRuby to an alternative Ruby is a lot harder than that. In what way? Truffleruby passes over 97% of CRuby's specs and it runs on my command-line without any problems so far. It was easy to install too. I'm sure if I dig into those failing specs I'll find something but will it be important? I'd love to know.
It’s probably not hard for someone to run the interpreter and try a few things out - but large private code bases are where the struggles would begin I imagine.
Sure, but the Devil's in the detail, especially when there's nothing obvious.
Re: Ruby 3.2’s YJIT is Production-Ready
#240Earlier quoted context omitted.
Their licensing does not ban benchmarking; it only bans publishing the results. A subtle but important point. By all means, run benchmarks on your workload profile and choose the technology that works best for you - that is perfectly OK. But not make claim that xxx beats oracle in yyy. Oracle goal here is to make a good enterprise ready DB solution; not to fight the open-source community on hundreds of different perf…
> Oracle goal here is to make a good enterprise ready DB solution Maybe. Or maybe it's to soak naive clients for all they're worth. The remedy for bad benchmarks is good benchmarks, not no benchmarks. > Just look at the « independent and fair review » that Top Gear made about Tesla. What about it? It was accurate and informative (unless you think Tesla lied about their range stats). The good points about electric car…
> The remedy for bad benchmarks is good benchmarks, not no benchmarks.
The comment you replied to just said Oracle allows running benchmarks internally, though.