71–80 of 248 posts
Earlier quoted context omitted.
Eating at a restaurant: - "This chef is a great cook!" - "How do you know, have you looked inside the kitchen?"
Code is not food. You can create a great product with shit code (Or just mediocre code!). Does that make someone a good dev, or a bad dev? How you come to the conclusion he's "just a damn good developer" is a very fair question.
Yes.
Earlier quoted context omitted.
Sentry had a natural path into cloud services because error monitoring has a server-side component to it. Serious question, what is the path for a linter? Where else are people paying for linting as a service?
A lot of companies would pay actual money for some semblance of supply-chain security. Hosted, verified, certified Python dependencies. This is how Red Hat made all their money in Linux. Something like "use our vetted and secure pypi instead of the free-for-all full of typo squaters and package takeovers that the public pypi.org offers." Starting with some nice developer tooling and going from there doesn't seem craz…
After the core-js debacle[0] earlier this year, it was evident that alot of companies actually do not care care about supply-chain security.
Those that do will happily roll their own hosted repositories that provide little to no guarantees.
[0] https://github.com/zloirock/core-js/blob/master/docs/2023-02...
Earlier quoted context omitted.
Eating at a restaurant: - "This chef is a great cook!" - "How do you know, have you looked inside the kitchen?"
Code is not food. You can create a great product with shit code (Or just mediocre code!). Does that make someone a good dev, or a bad dev? How you come to the conclusion he's "just a damn good developer" is a very fair question.
I don't use Rust - but can't deny Rust is saving the environment. countless CPU hours wasted by running dev tools written in slow as molasses languages now getting rewritten in Rust. build / lint times * number of times builds taken * kWH = saved energy
Speed is a non existent problem for linters. Pyflake is quick enough. I spend more time thinking than writing code. I just write in one file at a time, which can be linted in sub-second time. How does it compare with Pyflake8 in error messages? Does it find more errors? Does it have less false positives? Does it integrate well with other developers tools? Does it have sane defaults? These are the really important que…
https://github.com/charliermarsh/ruff#rules
> Ruff supports over 500 lint rules, many of which are inspired by popular tools like Flake8, isort, pyupgrade, and others. ... By default, Ruff enables Flake8's E and F rules. Ruff supports all rules from the F category, and a subset of the E category, omitting those stylistic rules made obsolete by the use of an autoformatter, like Black.
You can see the current list of supported rules here: https://beta.ruff.rs/docs/rules/
There's also a checklist on this PR which tracks progress on implementing pylint compatibility: https://github.com/charliermarsh/ruff/issues/970
I love Ruff and I'm glad that Charlie and the rest of the team are able to work on such tools full-time. I'm also happy to see that the author of Maturin (Rust+Python interop) is involved, as Maturin is a fantastic project with great ease-of-use. For those who aren't familiar, Ruff is a very fast Python linter that supersedes a variety of tools like isort, flake8, and perhaps eventually Black [1]. My understanding is…
Even if no VC was involved, how do you make money developing an open source linter?
Earlier quoted context omitted.
That's just a foot in the door. Like sentry made a good logging library, then pivoted to an observability service. And today I use sentry because I have a great history with their product. It's smart and a positive way to make money. I dig it. PS: ruff is not replacing black (although it will probably in the end), but compete with flake8 and pylint.
Sentry had a natural path into cloud services because error monitoring has a server-side component to it. Serious question, what is the path for a linter? Where else are people paying for linting as a service?
The natural end state is yet another build service.
I don't use Rust - but can't deny Rust is saving the environment. countless CPU hours wasted by running dev tools written in slow as molasses languages now getting rewritten in Rust. build / lint times * number of times builds taken * kWH = saved energy
Hopefully. But oftentimes the result is people just use more of something when it's cheaper.
I don't use Rust - but can't deny Rust is saving the environment. countless CPU hours wasted by running dev tools written in slow as molasses languages now getting rewritten in Rust. build / lint times * number of times builds taken * kWH = saved energy
Hopefully. But oftentimes the result is people just use more of something when it's cheaper.
I love Ruff and I'm glad that Charlie and the rest of the team are able to work on such tools full-time. I'm also happy to see that the author of Maturin (Rust+Python interop) is involved, as Maturin is a fantastic project with great ease-of-use. For those who aren't familiar, Ruff is a very fast Python linter that supersedes a variety of tools like isort, flake8, and perhaps eventually Black [1]. My understanding is…
I thought Black was an auto-formatter, similar to clang-format, but for Python. Ruff seems to be only doing linting, not formatting. Am I missing something?
ruff check . —-fix