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

241–250 of 282 posts

Re: Ruby 3.4.0

#241

Post by pjmlp »

nerdponx wrote: post #238
pjmlp wrote: post #39

Earlier quoted context omitted.

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…

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.

Re: Ruby 3.4.0

#242

Post by pjmlp »

nerdponx wrote: post #237
pjmlp wrote: post #228

Earlier quoted context omitted.

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.

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.

Re: Ruby 3.4.0

#243

Post by pjmlp »

maccard wrote: post #231
pjmlp wrote: post #39

Earlier quoted context omitted.

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.

Which happens to have a JIT compiler, and contributed to standard PHP having one as well.

Re: Ruby 3.4.0

#244

Post by pjmlp »

riffraff wrote: post #207
ksec wrote: post #43

Earlier quoted context omitted.

1. Wondering 3.4 JIT performance vs 3.3 JIT on production rails. 2. Also wondering what upside could Ruby / Rails gain on a hypothetical Java Generational ZGC like GC? Or if current GC is even a bottleneck anywhere in most Rails applications.

There's ongoing work to allow pluggable GCs, and specifically to allow using MMTk which would be IBM's Jikes GC https://bugs.ruby-lang.org/issues/20470 https://www.mmtk.io/

Not quite, MMTk was rewriten from Java into Rust.

So already something else from Jikes days.

Re: Ruby 3.4.0

#245

Post by emptiestplace »

debo_ wrote: post #233
pests wrote: post #6

Earlier quoted context omitted.

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.

It's rather compelling even without the context. :(

Re: Ruby 3.4.0

#246

Post by mdaniel »

codesnik wrote: post #100
tyre wrote: post #13

Earlier quoted context omitted.

Not really a niche language. Fantastic web server development. A more flexible and powerful language than python—the metaprogramming can be ridiculously powerful (when done well)—without the nonsense of white space sensitivity. ActiveRecord is perhaps the best ORM out there. Rails has tons of functionality to get running. Overall, a pleasant and expressive language with an incredible community. Python ends up "winnin…

...but ruby is whitespace sensitive too. It's hard to notice, because rules mostly follow intuition, but there're cases when not only a missing newline, but absense or addition of a space changes resulting syntax. Currently I remember only difference in parsing unary vs binary operators, like + and *, and ternary operator ? : vs : in symbols, but there're certainly more other cases.

There was a recent thread about parsing Ruby wherein I learned that the % quoting character accepts any character following it as the opening/closing delimiter https://news.ycombinator.com/item?id=42032212> Crazypants.

Re: Ruby 3.4.0

#247

Post by chucke »

bendangelo wrote: post #194
jstummbillig wrote: post #166

Earlier quoted context omitted.

What sucks about it?

Most gems with native extensions won't work. Gems that listen to filesystem changes like guard can be buggy. I recommend using Mac or Linux for Ruby on Rails development.

The listen gem works on windows: https://github.com/guard/listen?tab=readme-ov-file#listen-ad... . Not sure whether guard builds on top of it.

Re: Ruby 3.4.0

#249

Post by int_19h »

lucasoshiro wrote: post #221
int_19h wrote: post #184

Earlier quoted context omitted.

Everything is an object in Python, as well. Stuff like map() is generic iteration, over any structure that exposes iteration. When it's a member function, it means that every collection has to implement map itself basically. When it's separate, the collections only need to provide the interface needed to iterate over it, and the generic map() will just use that.

> over any structure that exposes iteration Taking OOP more seriously, this kind of thing should be implemented through inheritance, interfaces, mixins, etc. Even though I've got used to it, Python has these inconsistencies that sometimes it wants to be more OOP, sometimes it wants to be more FP. Ruby has chosen OOP as its size, and implements nicely those functional operations as methods (same for Kotlin, for exampl…

Kotlin is still rather different though in that it still implements stuff like map and filter outside of specific collection classes. If you look at the definition of, say, List, there's no map & filter there, only iterator. Instead, map & filter are defined as extension functions that work on any Iterable.

So semantically it's actually closer to Python, with the only difference that, since Python doesn't have extension methods, it has to use global functions for this, while Kotlin lets you pretend that those methods are actually members. But this is pure syntactic sugar, not a semantic difference.

Re: Ruby 3.4.0

#250

Post by int_19h »

Maledictus wrote: post #217
int_19h wrote: post #184

Earlier quoted context omitted.

Everything is an object in Python, as well. Stuff like map() is generic iteration, over any structure that exposes iteration. When it's a member function, it means that every collection has to implement map itself basically. When it's separate, the collections only need to provide the interface needed to iterate over it, and the generic map() will just use that.

Still looks much less beautiful. Python feels to me like it can't make up its mind.

I'll take "properly generalized" over "looks beautiful" any time. At the end of the day, the purpose of the code is to do something, not to be pretty.

FWIW you can have both in this case; you just need to make dotted method calls syntactic sugar for global function invocations.

Post reply on HN