This might be financial prudence of sorts - doesn't something like 80% of their yearly monetary contributions come from Google, particularly for search partnerships? If they are concerned that Google will start paying them less because search has diminishing future returns, diversifying their income sources through investments in AI might be a good idea.
This is a really awesome project! If you have time/interest, you could try to build a simple http server now, that your browser could communicate with. Then you could try to implement a simple version of TCP/IP, and look into how lower level networking works. Great job!
Polars took a lot of ideas from Pandas and made them better - calling it "inferior in every way" is all sorts of disrespectful :P
Unfortunately, there are a lot of third party libraries that work with Pandas that do not work with Polars, so the switch, even for new projects, should be done with that in mind.
Calling PETG "utterly problem free" is quite a stretch lol. PLA is pretty objectively much easier to print than PETG, and perhaps than all the popular filament types out there, especially if you are trying to print anything where precision/detail matters. .
PETG is just oozier and stickier by default, so stringiness is almost guaranteed to happen, bridging at a greater risk of failure, etc. It is tougher, so unless you have a printer that can use multiple filaments on the same print, removing supports is more difficult.
Can you reduce these factors by tuning your 3D printer - yes, a bit. But that's not "utterly problem free".
PLA is the plug and play of the 3D printing world right now.
In many ways HN is Reddit in denial at this point :) Comments and upvotes that are based mostly on vibes, with depth and discussion usually happening somewhere towards the middle of the comment tree.
I think both of us are ultimately wary of using the wrong tool for the job.
I see your point, even though my experience has been somewhat the opposite. E.g. a pipeline that used to work fast enough/at all up until some point in time because the scale of the data or requirements allowed it. Then some subset of these conditions changes, the pipeline cannot meet them, and one has to reverse engineer obscure SQL views/stored procedures/plugins, and migrate the whole thing to python or some compiled language.
I work with high density signal data now, and my SQL knowledge occupies the "temporary solution" part of my brain for the most part.
I'd say the author's thoughts are valid for basic data processing. Outside of that, most of claims in this article, such as:
"We're moving towards a simpler world where most tabular data can be processed on a single large machine1 and the era of clusters is coming to an end for all but the largest datasets."
become very debatable. Depending on how you want to pivot/ scale/augment your data, even datasets that seemingly "fit" on large boxes will quickly OOM you.
The author also has another article where they claim that:
"SQL should be the first option considered for new data engineering work. It’s robust, fast, future-proof and testable. With a bit of care, it’s clear and readable." (over polars/pandas etc)
This does not map to my experience at all, outside of the realm of nicely parsed datasets that don't require too much complicated analysis or augmentation.
Did I use the word "all" anywhere in my comment? There are good developers in Europe. What I am saying is that there would have been even more of them had the incentives not been so lackluster. More talent seems to generally result in a greater competitive ability.
Fwiw, I have doubts that currently Europe can compete with the US at the startup level, let alone at the bigco one.
I am not trying to drag Europe down - it worries me that sophisticated complacency, overconfidence based on the achievements of previous generations, and addiction to comfort, will start eroding the very aspects that make it a great place to live at.