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.
Ruby 3.4.0
141–150 of 282 posts
Re: Ruby 3.4.0
#142I 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…
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
#143Shopify strategy aka the story of YJIT If I cannot refactor my services, I shall refactor Ruby instead.
Re: Ruby 3.4.0
#144Every year-end, I update my Rails app. Lately, it's been stable, and the updates just improve performance, so it's gotten easier.
Re: Ruby 3.4.0
#145Shopify 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
#146Earlier 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".
Re: Ruby 3.4.0
#147Earlier 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...
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
#148Earlier 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.
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
#149Why 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.
Re: Ruby 3.4.0
#150Earlier 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.