11–20 of 160 posts
But but but HN told me that python is only good for small scale and prototypes, the engineers at meta are wrong
In which Meta promises 3 engineer-years for enhancing python.
(It's a podcast, not an article)
The description links to the tech article. https://engineering.fb.com/2023/08/07/developer-tools/fixit-...
Just a test, for some reason your link isn't clickable for me.
But but but HN told me that python is only good for small scale and prototypes, the engineers at meta are wrong
But but but HN told me that python is only good for small scale and prototypes, the engineers at meta are wrong
The engineers at meta worte a language + runtime on top of PHP to make it work "at scale". If Facebook wants to make something work they have enough resources to throw at the problem to solve it. Regardless of whether it makes sense or not.
I don't think that Facebook necessarily made a mistake at the time, though. Static languages have come a long way. I can prototype in them very nearly as quickly as I can in dynamic languages now, with the crossover point for where the static language is simply straight-up an advantage being roughly one to two weeks. Circa 2004 I would not even remotely make that claim. By the time static languages reached that state they were already in deep.
But I would consider it a mistake for most cases to start right now, in 2023, with dynamic scripting languages as a base layer.
I'm happy with Ruff[0], it's very fast. [0] -- https://github.com/astral-sh/ruff
I'm happy with Ruff[0], it's very fast. [0] -- https://github.com/astral-sh/ruff
Earlier quoted context omitted.
The description links to the tech article. https://engineering.fb.com/2023/08/07/developer-tools/fixit-...
https://engineering.fb.com/2023/08/07/developer-tools/fixit-... Just a test, for some reason your link isn't clickable for me.
formatting.Like This
It looks like the interesting feature of their tool Fixit 2 is that its lint rules know how to auto-apply themselves. I'm fine with an auto code formatter, an auto import organizer, but not sure how much I trust a linter to auto-apply "fixes".
But but but HN told me that python is only good for small scale and prototypes, the engineers at meta are wrong
The engineers at meta worte a language + runtime on top of PHP to make it work "at scale". If Facebook wants to make something work they have enough resources to throw at the problem to solve it. Regardless of whether it makes sense or not.
It looks like the interesting feature of their tool Fixit 2 is that its lint rules know how to auto-apply themselves. I'm fine with an auto code formatter, an auto import organizer, but not sure how much I trust a linter to auto-apply "fixes".
In the C#/.NET world this is the standard and it works very well. It definitely increases productivity to not have to double check each and every instance of violating a lint error, as you can just have the fix applied to an entire project without having to worry to much.
At what cosmic speed should you be pumping out code for this to be a concern?
Also, in C#/.NET, where programmers predominantly use MSVS, which is an atrocious editor with MSBuild, which is an atrocious build system, both hampering productivity...
Also, plenty of linter errors are actual errors that need non-trivial fixing. So, I struggle to understand how that may be automatically fixed (at least in the context of Python). A trivial example: misspelled variable name -- how would the linter know if that's a typo, or that the programmer intended to declare this variable, but forgot to do that?