Live data from Hacker News

Ruby 3.4.0

ruby-lang.org

231–240 of 282 posts

Re: Ruby 3.4.0

#231
post #39
post #10

Shopify strategy aka the story of YJIT If I cannot refactor my services, I shall refactor Ruby instead.

That has been the story of every dynamic language since forever, thankfully the whole AI focus has made JITs finally matter in CPython world as well. Personally I have learnt this lesson back in 2000's, in the age of AOLServer, Vignette, and our own Safelayer product. All based on Apache, IIS and Tcl. We were early adopters of .NET, when it was only available to MSFT Partners and never again, using scripting language…

HHVM has raised its head.

Re: Ruby 3.4.0

#232
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).

Re: Ruby 3.4.0

#233
post #6

Earlier quoted context omitted.

I'm pretty sure the only reason people ever used parser generators is that it allows a language that vaguely resembles the formal description of the target language. I always found them very confusing to write, confusing to debug, and much less efficient than writing your own. It's actually pretty straightforward once you get the tokenization and lookahead working.

Agreed. Parser generators are a magic black box. Parsing is not too difficult, there is some actual computer science in some spots, but I think parsing should be a core complacency of a programming language to unlock full potential.

"core complacency" was an excellent typo in the context of this conversation.

Re: Ruby 3.4.0

#234

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).

Do you mean like Hotwire?

https://hotwire.io/

Re: Ruby 3.4.0

#235
post #85

Earlier quoted context omitted.

They're written in Ruby from scratch. Some are available, e.g. the window manager is here: https://github.com/vidarh/rubywm Beware that one of the joys of writing these for my own use is that I've only added the features I use, and fixed bugs that matter to me, and "clean enough to be readable for me" is very different from best practice for a bigger project. I'm slowly extracting the things I'm willing to more gener…

Nice! That's something that you could submit as a post here in HN

The wm was actually discussed on HN way back. I think once some of my other projects, like the terminal, is a bit more mature (it works for me and I use it for 99%+ of my terminal needs) I might post those too.

The biggest issue with these projects is that I feel uncomfortable pushing a few of them because I make a living of providing development and devops work, and my personal "only has to work on my machine and certain bugs are fine to overlook" projects are very different to work projects in how clean they are etc... But as I clean things up so they're closer to meeting my standards for publication I'll post more.

Re: Ruby 3.4.0

#236
post #126

Earlier quoted context omitted.

The big plus of parser generators is that they report ambiguities. Handling conflicts is a pain but explicit. Do people who write predictive recursive descent parsers (LL(k)) really calculate first/follow sets by hand? What if the grammar requires backtracking?

Arbitrary backtracking in a recursive descent parser is very easy with exceptions. However, there's also an argument here that if the grammar is too complicated to be parsed with recursive descent, it's probably just too complicated in general and should be simplified if possible. Obviously you don't always have this option when you're dealing with an external grammar, but for your own PL, you can design around that.…

Recursive descent parsers can have ambiguities, but like PEGs, they just resolve the ambiguity by arbitrarily picking one of the alternatives.

A famous example is ALGOL 60, which had the dangling else ambiguity (https://en.wikipedia.org/wiki/Dangling_else), but this was not discovered until the language had already been published. If they had been using a parser generator tool, it would have warned them that the grammar was not LL or LR.

Overall I do still prefer hand-written recursive descent parsers, but I do find this to be one of the biggest downsides of not using parser generators.

Re: Ruby 3.4.0

#237
post #228

Earlier quoted context omitted.

>thankfully the whole AI focus has made JITs finally matter in CPython world as well. Isn't most of the work in Python AI projects done in C or C++ extensions anyway?

Yes, but not everyone loves to have dual stack development, I surely didn't, back in the Tcl days, eventually we ask ourselves for how long.

That's not how it works in Python.

The C/C++ is shipped in the form of well-established libraries like Numpy and PyTorch. Very few end users ever interact with the C/C++ parts, except for specialists with special requirements, and library contributors themselves.

Re: Ruby 3.4.0

#238
post #39
post #10

Shopify strategy aka the story of YJIT If I cannot refactor my services, I shall refactor Ruby instead.

That has been the story of every dynamic language since forever, thankfully the whole AI focus has made JITs finally matter in CPython world as well. Personally I have learnt this lesson back in 2000's, in the age of AOLServer, Vignette, and our own Safelayer product. All based on Apache, IIS and Tcl. We were early adopters of .NET, when it was only available to MSFT Partners and never again, using scripting language…

> AI

The push for Python performance and JIT compilation has little to do with AI and more to do with Python's explosion in adoption for backend server applications in the 2010s, as well as the dedication of smaller projects like PyPy that existed largely because it was possible to make them exist. The ML/AI boom helped spread Python even farther and wider, yes, but none of the core language performance improvements are all that relevant for ML or AI.

As another commenter pointed out, the performance bottlenecks in AI specifically have essentially to do with the CPython runtime performance. The only exception is in the pre-processing of very large text corpora, and that alone has hardly been a blip on the radar of the people working on CPython performance.

Moreover, most of the "Python performance" projects that do sit closer to machine learning use cases (Cython-Numpy integration, Numba, Nuitka) are more or less orthogonal to the more recent push for Python interpreter performance.

Cython itself and MypyC are mainly relevant because they are intended to be general-ish purpose performance boosters for CPython, and in doing so helped fill the need for greater performance in "hot and loopy" code such as network protocols, linters, and iterators. Cython also acted as a convenient glue layer for ad-hoc C library binding. But neither project is all that closely related to AI or to the various JIT compilers that have arisen over the years.

Re: Ruby 3.4.0

#239

Earlier quoted context omitted.

Arbitrary backtracking in a recursive descent parser is very easy with exceptions. However, there's also an argument here that if the grammar is too complicated to be parsed with recursive descent, it's probably just too complicated in general and should be simplified if possible. Obviously you don't always have this option when you're dealing with an external grammar, but for your own PL, you can design around that.…

Recursive descent parsers can have ambiguities, but like PEGs, they just resolve the ambiguity by arbitrarily picking one of the alternatives. A famous example is ALGOL 60, which had the dangling else ambiguity ( https://en.wikipedia.org/wiki/Dangling_else ), but this was not discovered until the language had already been published. If they had been using a parser generator tool, it would have warned them that the gr…

Of course the Algol 60 committee could not have used a parser generator tool because they were not invented until later in the 1960s, but your point is valid for anyone developing a language after that time.
Post reply on HN