Live data from Hacker News

Ruby 3.4.0

ruby-lang.org

271–280 of 282 posts

Re: Ruby 3.4.0

#271

Earlier quoted context omitted.

It's the language with the highest ratio of (useful work / LOC), so it's the least verbose language. This makes it very suitable to write and understand complex scripts, because the reduced boilerplate means less cognitive overhead for the programmer. As a result, experienced programmers can be extremely productive with it. The well-known Rails framework uses this to great effect, however, some people argue that the…

> It's the language with the highest ratio of (useful work / LOC), so it's the least verbose language. That's not even close to true. Even setting aside APL and its descendants, even setting aside Perl, any of the functional programming languages like Haskell and Scala are less verbose. (The relative lack of success of those languages should indicate why minimizing verbosity is a poor aim to target.)

Don't just focus on the language syntax, the high ratio of useful work to verbosity is in large part owing to the excellent design of the standard library, which is available without including any headers or downloading third party libraries. This is where it handily beats out any of the alternatives you mention.

Re: Ruby 3.4.0

#272

If I want to make a SSR site using Ruby, are there any good frontend UI libraries that make doing this easier? It’d be nice if there was some Ruby abstraction for writing HTML, CSS, and JS that makes building interactive UIs easier (possibly built on top of HTMX, AlpineJS, etc).

I would suggest taking a look at Phlex (https://www.phlex.fun/). This kind of ruby maximalism is very pleasing to the dev process. For the interaction I'm using hotwire and stimulus. Been using pure Phlex views in production for 2 years now. I wrote Protos (https://github.com/inhouse-work/protos) which is built on top of Phlex and adds a bunch of quality of life features I wanted.

Re: Ruby 3.4.0

#273

Earlier quoted context omitted.

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.

And of course the right way to do that is to take an extremely mediocre, rushed, incomplete language that is currently constrained to the browser, and make it run everywhere else, ironically having to reinvent many wheels and re-learn very old lessons the hard way along the way. Mission "reuse knowledge" is a hearty failure in node.js-land.

[deleted]

Re: Ruby 3.4.0

#274
post #260

Earlier quoted context omitted.

How can you compare the FLA with Oracle's CLA??? From the FSFA: > An FLA offers a special clause against this kind of situation, in order to protect the Free Software project against potentially malicious intentions of the Trustee. According to this provision, if the Trustee acts against the principles of Free Software, all granted rights and licences return to their original owners. That means that the Trustee will…

I don't know what the "FLA" or "FSFA" is (are they real things or is this an AI-generated comment?), but the FSF traditionally required copyright assignment, which gave them all the rights in Oracle's CLA and more.

I meant FSFE.

https://fsfe.org/activities/fla/fla.en.html

Re: Ruby 3.4.0

#275
post #242

Earlier quoted context omitted.

It is definitely how it works in Python. As if there is nothing else to chose from regarding Python performance issues and libraries used by folks. Not everything is fashionable AI.

Can you name specific "un-fashionable" AI projects that are dependent on Python code for things that have any significant performance impact, which are seeing significant benefits from Python JIT implementations?

He cannot

Re: Ruby 3.4.0

#276
post #242

Earlier quoted context omitted.

It is definitely how it works in Python. As if there is nothing else to chose from regarding Python performance issues and libraries used by folks. Not everything is fashionable AI.

Can you name specific "un-fashionable" AI projects that are dependent on Python code for things that have any significant performance impact, which are seeing significant benefits from Python JIT implementations?

I guess you will have to ask Microsoft, Facebook, NVidia and Intel why they are bothering then.

Re: Ruby 3.4.0

#277

Earlier quoted context omitted.

Can you name specific "un-fashionable" AI projects that are dependent on Python code for things that have any significant performance impact, which are seeing significant benefits from Python JIT implementations?

He cannot

Microsoft, Facebook, NVidia and Intel apparently can.

Re: Ruby 3.4.0

#278
post #241

Earlier quoted context omitted.

Not at all, given Facebook and Microsoft involvement into making CPython folks finally accept a JIT has to be part of the story, coupled by NVidia and Intel work on GPU JIT DSLs for Python.

Yeah but how much of the Microsoft and Facebook effort was due to AI directly, as opposed to the general popularity of Python? which is undoubtedly driven nowadays by AI, but indirectly.

What Python projects do they have outside AI?

Re: Ruby 3.4.0

#279
post #276

Earlier quoted context omitted.

Can you name specific "un-fashionable" AI projects that are dependent on Python code for things that have any significant performance impact, which are seeing significant benefits from Python JIT implementations?

I guess you will have to ask Microsoft, Facebook, NVidia and Intel why they are bothering then.

Can you name projects at those companies which meet the description?

Re: Ruby 3.4.0

#280
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…

The biggest improvement from this (besides maybe performance) is that it should enable much better manually programmed syntax error messages. Those generated by yacc were pretty shit.

This is generally my #1 reason for using a manual parser — nobody has yet made a pretty good syntax error handling / reporting for parser generators or parser combinators.

It's genuinely very complex — I read the whole literature on that as of 2019 (there's surprisingly little). You basically have to inject custom logic, though there are a few heuristics that you can prepackage and can be useful in a lot of places. But the custom aspect of it means this doesn't play nice with traditional LL/LR parser generators. It could be done for parser combinators (PEG etc) however. Didn't have enough time in my PhD thesis to play with this, and I moved on to other things, but I'm hoping someone will make this eventually.

Post reply on HN