Live data from Hacker News

Ruby 3.4.0

ruby-lang.org

141–150 of 282 posts

Re: Ruby 3.4.0

#141
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.

Sure, like `a ?b :c` is nothing like `a ? b : c` (I guess the former is actually invalid), but that's obviously not what the previous message was referring to when speaking of Python which uses spaces as main facility to determine block scope.

Re: Ruby 3.4.0

#142

I want to try Ruby since the news of Rails 8 came out, but it's been so difficult that I just gave up. Installing Ruby on Mac and Windows and actually getting the 3.3 version required for Rails 8 was a huge mission and test of patience because every installer defaulted to older versions of both Ruby and Rails even one month after the release. And yes, even Docker required tweaking to get the versions and I had issues…

Use asdf (https://asdf-vm.com/) to manage your Ruby versions.

You should be able to do

$ asdf plugin add ruby

$ asdf list all ruby (you'll see 3.4.1, the latest is available)

$ asdf install ruby 3.4.1

And now you can use Ruby 3.4.1 with no issues. Follow that up with

$ gem install bundler

$ gem install rails

$ rails new ...

Re: Ruby 3.4.0

#143
post #10

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

Classic story. Didn't Dropbox do the same for Python? ANd Facebook for PHP (and then forked it)?

Re: Ruby 3.4.0

#144

Every year-end, I update my Rails app. Lately, it's been stable, and the updates just improve performance, so it's gotten easier.

I haven’t worked in ruby or rails in a few years but both seem like they’re in great spots and I’ll be spinning up a new project with Rails 8 soon. Hype

Re: Ruby 3.4.0

#145
post #10

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

Classic story. Didn't Dropbox do the same for Python? ANd Facebook for PHP (and then forked it)?

Roblox did the same with luau https://luau.org/performance

Re: Ruby 3.4.0

#146
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.

A very very long list of CVEs disagrees with that parsers are "not too difficult".

Binary formats are rarely context free.

Re: Ruby 3.4.0

#147

Earlier quoted context omitted.

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

Heh, he's so right in every regard although I use Node.

Worst of all, they made npm packages dead easy, so most of them don't even have a readme file, not to mention inline docs like POD or RDoc. This is how you end up with spam pacakges, malware in npm and lpad disasters.

Re: Ruby 3.4.0

#148
post #97

Earlier quoted context omitted.

My hot take is that the allure of parser-generators is mostly academic. If you're designing a language it's good practice to write out a formal grammar for it, and then it feels like it should be possible to just feed that grammar to a program and have it spit out a fully functional parser. In practice, parser generators are always at least a little disappointing, but that nagging feeling that it _should_ work remain…

It is not academic. It is very practical to actually have a grammar and thus the possibility to use any language that has a perser generator. It is very annoying to have a great format, but no parser and no official grammar for the format available and being stuck with whatever tooling exists, because you would have to come up with a completely new grammar to implement a parser.

> It is very practical to actually have a grammar

I fully agree that you need to have a grammar for your language.

> and thus the possibility to use any language that has a perser generator.

See, this is where it falls down in my experience. You can't just feed "the grammar" straight into each generator, and you need to account for the quirks of each generator anyway. So the practical, idk, "reusability"... is much lower than it seems like it should be.

If you could actually just write your grammar once and feed it to any parser generator and have it actually work then that would be cool. I just don't think it works out that way in practice.

Re: Ruby 3.4.0

#149

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

Google hired all the best JIT engineers and set them to work on v8. If you want better performance you'd have to choose an AOT compiled language.

Google also made Dart which is better than Js in every regard.

Re: Ruby 3.4.0

#150

Earlier quoted context omitted.

Rails has some very, very good features that make standing up a CRUD app with an administrative backend _very easy_. It's also got a bunch of semi-functional-programming paradigms throughout that make life quite a bit easier when you get used to using them. Honestly, if it had types by default and across all / most of its packages easily (no. Sorbet + Rails is pain, or at least was last I tried), I'd probably recomme…

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.

Can you elaborate more in this? Years ago, I used to primarily do Rails development. Recently I built some web apps that use a JVM backend (one app uses Java & Spring and the other Kotlin & Micronaut) and a React frontend. One thing I ended up really missing issue the the frameworks, especially with disjointed fronted, don't solve the standard issue of a request sending an invalid form entry and showing the validation errors on the form. I ended up building my own implementation of that which of course also requires a convention on message format. Since most apps need to solve this it's so weird to be that frameworks nowadays don't solve this out of the box.
Post reply on HN