Sure, but I wouldn’t expect deepseek to either. And if any model did, I’d damn sure not bet my life on it not hallucinating. Either way, that’s not heresy.
The article only talking about single app per server without using hostnames. That you can do as the app will respond to the IP address. Currently you can't run multiple apps on each servers behind load balancer as the health check will not be successful as there is no way to set the default host.
"Modern" goto (well, there aren't many modern languages with goto, but anyway) is semi-structured. Most importantly, it's local: you cannot jump into or out of subroutines, which was Dijkstra's major peeve. Using goto for backwards jumps is also usually discouraged post-Dijkstra.
This was written by the recently deceased Noah Gibbs. The site is now under the control of his widow. It's a great course and I'd encourage people to check it out.
I think it's a combination of a lot of things over the last 2ish years:
1. Ruby 3.0 and YJIT have provided huge performance gains for the language with further improvements still left to be implemented.
2. Ruby releases new versions every year on Christmas day, so you're more likely to get new content around this time of year.
2. Large Rails shops like Github and Shopify have redoubled their commitment to Ruby/Rails and invested a lot of resources into improving the developer experience with ruby-lsp.
3. Prism, the new Ruby parser has been developed and merged into Ruby, from my understanding, it's a lot more user-friendly and fault-tolerant, allowing for the creation of more/better development tools.
4. Rails 7/8 released a ton of exciting new features such as Hotwire, Solid suite, auth generation and others. Promising a simpler way to make high-fidelity applications.
5. The Rails Foundation was created and has focused on improving documentation, organising Rails World and pushing the message of Rails being 'a one person framework' that can get you 'from hello world to IPO'.
6. A growing dissatisfaction with the needless complexity of the Javascript ecosystem and cloud providers, pushing people towards the simple but powerful solutions Rails provides.
All these individual contributions seem to have produced a snowball effect. As a long-time Rails developer, seeing there be a new Ruby and/or Rails post on the front page of HN nearly every day recently has been really exciting.
The gem isn't freezing instances of the objects, but rather the classes themselves. In Ruby (nearly) everything is an object, so for example Array is an object of type Class. Classes are also open by defualt, allowing them to be altered at run time. There's nothing stopping me doing the following in my app:
irb(main):001* class Array
irb(main):002* def hello
irb(main):003* puts "hello"
irb(main):004* end
irb(main):005> end
=> :hello
irb(main):006> [].hello
hello
This sort of monkey patching is used a lot in the ActiveSupport gem to give convenient methods such as:
irb(main):001:0> 3.days.ago
=> Sat, 28 Dec 2024 13:10:24.562785251 GMT +00:00
Integer is extented with the `days` method making date maths very intuative.
This gem freezes the core classes, essentially closing them, so doing the above raises an error:
irb(main):007> require 'refrigerator'
=> true
irb(main):008> Refrigerator.freeze_core
=> nil
irb(main):009* class Array
irb(main):010* def hello
irb(main):011* puts "hello"
irb(main):012* end
irb(main):013> end
(irb):10:in `<class:Array>': can't modify frozen class: Array (FrozenError)
Looking at the code in the gem, all it's doing is calling https://apidock.com/ruby/Object/freeze on all call modules. The frozen flag is an inbuilt part of the language and as far as I'm aware has a performance benefit. In fact the major verison of Ruby will have all string instances frozen by default.
I know that it freezes the classes (which are also objects, indeed). And I saw it does this by reading classnames from a list of textfiles. Both is not fast. The "freeze" isn't that invasive, from what I can see in the c code, it merely flips a flag at the objects metadata table. But I can imagine the reading from files isn't that fast.
And tracking the mutation flags isn't free either. Though I expect not that big. Checking for the state of this flag at every possible mutation is quite some overhead, I'd presume. But no idea how heavy that'd be.
Again, compared to typical boot stuff like Rails' zeitwerk autoload mapping, it's nothing. And in runtime the only penalty will be when something tries to mutate a class obj, which I'd expect happens almost only on boot in most codebases anyway.
Though I know quite some "gems" and even older Rails implementations (mostly around AR) that would monkeypatch in runtime on instantation even. Like when a state-machine gets built on :new or when methods get added based on database-columns and types, every time such an instance is returned from a db response.
I didn't mean to imply you didn't know that stuff, I just tend to write comments from the basics for anyone unfamiliar who may be reading. Yup I would expect it to have an (extremely small) boot time impact. Though I don't think it would have a runtime impact, since surely ruby has to check the frozen flag on mutation whether the flag has been set to true or not? Also by including the gem you preclude mutating the class objects anyway, since it raises an error.
The new getting started guide is great. Chris Oliver is a great teacher. Afterwards, if you want a 102-style tutorial, I'm a big fan of https://www.hotrails.dev/. It goes step by step and explains how Hotwire works and how to use it.
load_async is still concurrency, but not parallelism. The queries themselves can run parallel, but when materializing AR objects e.g., only one thread can run at a time. A greedy thread in process will still subject you to GVL waits
I find that a 6-month-old JS project will often not even boot since its exhaustive dependency list will be out of date and now mutually incompatible. You have to feed a JS project with updates every couple of hours, or it will die like a Tamagotchi.
I've seen comments like this almost daily this week.
Does HN not use lockfiles or something? Your node/npm project will work just fine if you use the same version of node/npm and have a lockfile.
Maybe you're using npm i (which can upgrade dependencies in some cases) instead of npm ci [0] (which always uses the lockfile dependencies).
In any case, this is a general problem of package managers and has nothing to do with the language. You'll need something similar if you're using _any_ external dependency in Rust, Python, Go, etc.
