IRB type completion comes as a result of a chain of events which starts from the incredible work done by Kevin Newton (et al) to write a new canonical Ruby parser called Prism in C99 with no dependencies [1].
With Prism, you can then create tool suites like syntax_tree [2], which then leads Prettier formatters [3], a new Ruby LSP [4], which unlocks a new Ruby LSP VS Code extension [5], not to mention a laundry list of other gems like Rubocop and of course Ruby itself that will benefit from a faster and more maintainable Ruby parser.
It's a beautiful illustration of the power of questioning conventions, going back to first principles to uncover better solutions to previously solved problems, whose new solutions create new capabilities which unlocks the ability to solve new problems.
As an H-1B holder, we are legally entitled (and required) to work for one specific employer and that's it. You cannot even think of starting a company, you cannot work a gig job, you can't work two "high-paying" tech jobs.
Everyone knows the "ton of money" doesn't come from working a salaried job, it's from creating something new / starting a company.
But only US green card holders or US citizens can even dream of considering that as an option they can pursue.
There was an internal joke / meme at Google that any announcement starting with "An update on X" == we are killing X, to the point that if someone was sending their resignation email the subject line of the email would be "An update on <name>"
It's interesting to read the replies in this thread because a lot of people are proposing alternative "it's just this" solutions to the same problem being solved here -- the over abundance of plastics.
But the solution can be all of these proposed "it's just this" strategies combined.
We do need a:
- standardization of plastics,
- a switch to alternative materials that are more compostable,
- a research lab to more deeply understand the true nature of plastics and their reuse,
- a tax on environmentally costly materials such as plastics,
- depolymerizing,
- and more...
These are all solutions to the same problem. Let's work on all of these problems simultaneously and combine them for compound effects.
> However there is one caveat. If some of the data members are of a mutable class, Data does no additional immutability enforcement.
Seems like an area of concern / gotchas. Either restrict Data to not allow mutable nested objects, or provide immutable versions of stdlib object types as well and enforce that those types are used.
Yet another Rubocop-that-should-just-be-built-into-the-language coming in 3...2...1...
Crazy that despite their progress behind the scenes, they appear to have not touched this website since.
I probably spent a little too much time tweaking the CSS to get the mosquitoes to not overlap the text on various viewport sizes :)