Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.4.0

ruby-lang.org

Post reply on HN
Print view View original

101–110 of 282 posts

Re: Ruby 3.4.0

#101

Post by majewsky »

badsectoracula wrote: post #90
omoikane wrote: post #2

I am most excited about the parser change, previously discussed here: https://news.ycombinator.com/item?id=36310130 - Rewriting the Ruby parser (2023-06-13, 176 comments) I remember being taught to use yacc in our compiler course because "writing it by hand is too hard". But looks like Ruby joins the growing list of languages that have hand-written parsers, apparently working with generated parsers turned out to be e…

> I remember being taught to use yacc in our compiler course because "writing it by hand is too hard". But looks like Ruby joins the growing list of languages that have hand-written parsers, apparently working with generated parsers turned out to be even harder in the long run. I've been writing parsers for simple (and sometimes not so simple) languages ever since i was in middle school and learned about recursive de…

Parser generators will tell you whether the grammar given to it is well-formed (according to whatever criteria the parser generator uses).

When hand-rolling a parser, there could be accidental ambiguities in the definition of your grammar, which you don't notice because the recursive descent parser just takes whatever possibility happened to be checked first in your particular implementation.

When that happens, future or alternative implementations will be harder to create because they need to be bug-for-bug compatible with whatever choice the reference implementation takes for those obscure edge cases.

Re: Ruby 3.4.0

#102

Post by Alifatisk »

phoronixrly wrote: post #92
Alifatisk wrote: post #73

Earlier quoted context omitted.

Wait until you hear about TruffleRuby

Thanks, but no thanks. Never touching anything by oracle.

No wait, I know Oracle has a bad rep which is deserved, but TruffleRuby and GraalVM is truly open-source, not open-core. They actually did something great this time.

Someone pointed this out https://news.ycombinator.com/item?id=42323293

Re: Ruby 3.4.0

#103

Post by loloquwowndueo »

ninkendo wrote: post #79
thdhhghgbhy wrote: post #12

Why did NodeJS take off on the backend while Rails was still popular? I'll never understand it.

People say frontend/backend parity, and that’s true, but I also remember there was a time in 2011 or so where single thread/async was this new hot thing. Nginx was starting to get popular and overtake Apache on installs, and people were enamored with its performance and idea of “no blocking, ever” and “callbacks for everything”, which the nginx codebase sorta takes to the extreme. The c10k problem and all that. When…

“Node makes it impossible to write blocking code” reminds me of this classic and hilarious piece by Ted Dziuba:

http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cance...

Re: Ruby 3.4.0

#104

Post by phamilton »

shortrounddev2 wrote: post #7

What does ruby do well that other languages don't? What is the niche it's trying to fill?

The language is incredibly flexible and allows for "DSLs" that are just ruby libraries.

A simple example: `3.days.ago` is a very commonly used idiom in Rails projects. Under the hood, it extends the base Number class with `def days` to produce a duration and then extends duration with `def ago` to apply the duration to the current time.

Taking that concept to a bigger extreme is this mostly unnecessary library: https://github.com/sshaw/yymmdd

`yyyy-mm-dd(datestr)` will parse a date str that matches yyyy-mm-dd format. It looks like a special DSL, but it's just Ruby. `dd(datestr)` produces a `DatePart`. Then it's just operator overloading on subtraction to capture the rest of the format and return the parsed date.

That library feels unnecessary, but the entire thing is 100 lines of code. The ease of bending the language to fit a use case led to a very rich ecosystem. The challenge is consistency and predictability, especially with a large team.

Re: Ruby 3.4.0

#105

Post by tekknolagi »

Alifatisk wrote: post #102
phoronixrly wrote: post #92

Earlier quoted context omitted.

Thanks, but no thanks. Never touching anything by oracle.

No wait, I know Oracle has a bad rep which is deserved, but TruffleRuby and GraalVM is truly open-source, not open-core. They actually did something great this time. Someone pointed this out https://news.ycombinator.com/item?id=42323293

GraalVM tends toward open core. They have entire test suites and test tools that are internal-only that make developing it kind of difficult.

Re: Ruby 3.4.0

#106

Post by ysavir »

jherdman wrote: post #88
FBISurveillance wrote: post #24

Earlier quoted context omitted.

I love Rails and spent a good chunk of my career using it - and I'd recommend it more if only the frontend story wasn't that bumpy over the years with all the variations of asset pipelines. I wish the TypeScript/React integration was easier. Say what you will but there's no way you can achieve interactivity and convenience of React (et al) UIs with Turbo/Hotwire in a meaningful time.

Agreed re asset pipelines. I definitely have Webpacker related scar tissue. Have you tried either Inertia ( https://github.com/inertiajs/inertia-rails ) or vite-ruby ( https://vite-ruby.netlify.app/ )? Both look very promising.

I converted from webpacker (or rather shakapacker, the continuation after rails moved away from webpacker) to vite_rails recently, and it's been such a breath of fresh air. It's easy to set up, and easier to maintain. Strongly recommended.

Re: Ruby 3.4.0

#107

Post by ericb »

wiseowise wrote: post #49
briandear wrote: post #21

Earlier quoted context omitted.

Because of the JavaScript Everywhere crowd. When you have a hammer, everything looks like a problem for JavaScript.

God forbid we reuse knowledge instead of drudging lives through never ending learning of same concepts with different syntax’s and 10x costs for supporting every special native snowflake toolchain.

If that's the goal, the problem itself has been re-implemented by the Javascript ecosystem.

Re: Ruby 3.4.0

#109

Post by JasserInicide »

evjan wrote: post #5

‘it’ is a welcome addition!

I don't understand the point of it when the `.map(&:upcase)` syntax is shorter. This just seems like yet another syntactic sugar Rubyism that doesn't really add anything.

If it's an alternative to the `|x|` syntax when using only one block variable, then I like that.

Re: Ruby 3.4.0

#110

Post by graypegg »

JasserInicide wrote: post #109
evjan wrote: post #5

‘it’ is a welcome addition!

I don't understand the point of it when the `.map(&:upcase)` syntax is shorter. This just seems like yet another syntactic sugar Rubyism that doesn't really add anything. If it's an alternative to the `|x|` syntax when using only one block variable, then I like that.

That only works when calling a method on the things you’re iterating thru, it is a replacement for the single variable block example you gave there
Post reply on HN