[HN Gopher] Astral
___________________________________________________________________
Astral
Author : hasheddan
Score : 603 points
Date : 2023-04-18 17:38 UTC (5 hours ago)
(HTM) web link (astral.sh)
(TXT) w3m dump (astral.sh)
| ur-whale wrote:
| What is it beyond a linter.
|
| Also: speed is good, but when it comes to linting, that's not
| what I'd place first as a feature.
|
| How good is the code at spotting my potential mistakes would come
| before speed for sure.
|
| Hence: it's fast, but is it in any way better than the other
| solutions out there?
| voidfunc wrote:
| Yet another linter.
| kleaver wrote:
| I wonder if the eventual goal of this is similar to deno, where
| it's about building really good, no-hassle tooling/ecosystem for
| a language and then making it very simple to deploy/host (if I'm
| misspeaking about deno please correct me, I'm not well versed on
| it).
|
| One thing I like most about Go is actually the Go tool; having a
| ubiquitous linter, formatter, test framework, dependency
| management, etc, all built in and not having to install various
| tools is huge imo. I think a lot of languages are missing this
| ease of tooling. I think (?) this is what deno/astral is trying
| to address for javascript/python and then the business model is
| once you're using it, it's simple to host with them. Curious what
| other think
| BiteCode_dev wrote:
| It's true that being that much faster is interesting, but that's
| not the only reason.
|
| ruff is just really good.
|
| It has sane defaults, it is easy to use and configure. It can
| replace not one but multiple tools.
|
| From day one it had few bugs or integration problems.
|
| Charlie Marsh is just a damn good developer, on top of driving a
| good product vision.
|
| That's rare.
|
| Lots of respect to that.
| hardwaregeek wrote:
| That's a very good point. We love to talk about speed in dev
| tools, probably because it's an easy metric to track, but
| usability and good features are really the key points for
| making a tool that people want to use and keep using. Too many
| open source projects neglect the product angle in favor of the
| technical.
| swyx wrote:
| > Charlie Marsh is just a damn good developer
|
| curious how you assessed this. did you inspect the code or are
| you just commenting from the user POV?
| dangoor wrote:
| FWIW, some of my time at Khan Academy overlapped with some of
| Charlie's and I agree with this assessment :)
| twunde wrote:
| I think everyone that's worked with him, would agree :)
|
| For the brief time he was at Cedar, he contributed a lot of
| high quality code
| emoprincejack wrote:
| comments like this make me hate this site. i logged in JUST
| to reply to this.
|
| average developers write javascript at some random company
| doing nothing.
|
| one look at the repository would tell you this person is
| obviously above average at writing software.
|
| you sound jealous and pretentious, as 72% of the people on
| this site.
| Aeolun wrote:
| Is it bad to be jealous of people that are much better than
| you are?
|
| I mean, for your own sake, ideally you are not, but I think
| it's reasonable.
| swyx wrote:
| then you probably dont know that i'm actually more
| supportive of charlie than most and are reading negative
| intent from a perfectly neutral/innocent question that is
| perhaps badly phrased :)
| ZephyrBlu wrote:
| I thought more people would recognize your username, but
| I guess not. I suppose you're more prolific on Twitter
| than HN.
| ajkjk wrote:
| The rest of the post you're replying to is a list of
| evidence, that claim was summarizing everything else.
| BiteCode_dev wrote:
| Eating at a restaurant:
|
| - "This chef is a great cook!"
|
| - "How do you know, have you looked inside the kitchen?"
| ZephyrBlu wrote:
| 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.
| cacois wrote:
| Is the function of the developer to write outstanding
| code, or develop outstanding products?
|
| I think there's something to be said for praising the
| developer that is able to understand user needs so well
| that they create flawless experiences.
| burkaman wrote:
| > You can create a great product with shit code (Or just
| mediocre code!). Does that make someone a good dev
|
| Yes.
| [deleted]
| ashtonbaker wrote:
| I think it's actually basically the same. Being a clean,
| organized cook is probably positively correlated with
| making good food, but it's not strictly necessary. If
| someone is writing sloppy code but shipping a project of
| this overall quality without leaking the "low quality" of
| their implementation, then I wouldn't presume to call
| them a "bad dev" - I would probably conclude that they're
| more efficient than I am at prioritizing where to spend
| organizational energy.
| BiteCode_dev wrote:
| In this analogy, the food is the entire project, and a
| dev does much more than coding. You can do one thing
| right with luck, you can't do most things right by luck
| alone.
|
| The guy is fluent in 2 languages, one being known to be
| hard to master, create a tool that replace several
| others, get adopted in months by half the community,
| welcome 172 contributors on a project that is parsing
| stuff, a hard problem. Also the doc is good.
|
| As a professional dev, I never get all those right.
| Never.
|
| So yes, the food is good, and the chef is excellent to
| get all that stuff right.
| gardenhedge wrote:
| Oddly defensive. Why not answer the question?
| dzonga wrote:
| 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
| Waterluvian wrote:
| Hopefully. But oftentimes the result is people just use more of
| something when it's cheaper.
| gooseyman wrote:
| Ah yes! https://en.m.wikipedia.org/wiki/Jevons_paradox
| digging wrote:
| A bit optimistic to say "sometimes" IMO
| Thaxll wrote:
| This is a drop in the ocean, and really not saving anything
| meaningful.
| mdaniel wrote:
| heh, I would actually be curious about that environment claim
| when one balances the amount of power consumed by _compiling_
| rust; i.e. the savings for its users balanced against the
| horrific amount of wattage drawn on the developer 's
| workstations or cloud or ci servers
|
| I now have to compile Firefox overnight because I can no longer
| compile it and do something else with my (core i7) laptop
| simultaneously
| prisonguard wrote:
| nowadays, it's cool to say this new toy is faster than the rest
| because it is written in Rust without providing further details?
|
| When I visit the Bun project landing page[0], I get concise
| reasons as to why bun is faster than its peers.
|
| [0] https://bun.sh/
| mrkeen wrote:
| > nowadays, it's cool to say this new toy is faster than the
| rest because it is written in Rust without providing further
| details?
|
| It's usually true, too.
| stavros wrote:
| > nowadays, it's cool to say this new toy is faster than the
| rest because it is written in Rust without providing further
| details?
|
| What more details do you want? You run it, and it runs in
| milliseconds rather than seconds. I don't care if it's because
| it's written in Rust or because they sacrificed a goat to Baal,
| I care that it's fast.
| mhh__ wrote:
| Although I'm sure it is faster, comparing "Linting" speeds as a
| Blackbox strikes me as bullshit artistry (for any language other
| than python perhaps)
| PaulHoule wrote:
| Python needs something like pip and poetry that is (1) correct,
| and (2) faster than poetry.
| anilshanbhag wrote:
| I really hope they develop a faster mypy. In my dev workflows,
| mypy takes most of the time. Linting is a small fraction of it.
| davidhalter wrote:
| I'm currently speeding up Mypy + Jedi in Rust. I'm pretty far
| already and it's definitely a lot faster. Tests are currently
| running 500 times faster than Mypy.
| sergiotapia wrote:
| A VC raise gives the team cash to work on this full-time, that's
| great news.
|
| What worries me is what possible possible path can exist that
| gives VC-returns that is not at odds with customer happiness?
| Customers being Python developers.
| ossusermivami wrote:
| they sure know how to make a website! quite a change from ye old
| README.md
| hn_throawlles wrote:
| [flagged]
| haolez wrote:
| I hope they eventually attack package management and easy static
| bundling. It would make Python more attractive for people coming
| from other ecosystems.
| theusus wrote:
| Does it support type inference and stuff?
| neuronexmachina wrote:
| https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-mypy...
|
| > Ruff is a linter, not a type checker. It can detect some of
| the same problems that a type checker can, but a type checker
| will catch certain errors that Ruff would miss. The opposite is
| also true: Ruff will catch certain errors that a type checker
| would typically ignore. ...
| zephraph wrote:
| Congrats Charlie! Excited to see you launch and I wish you the
| best. Ruff is awesome and y'all are doing great work.
| slekker wrote:
| What's in the roadmap for what will be built by Astral?
| jonthepirate wrote:
| Somehow, ruff is linting my entire codebase 350x faster than
| pylint did.
| korijn wrote:
| If your codebase is as large as cpython's, I think the benefits
| are clear. But most projects aren't actually this big right?
| Flake8 runs less than a second on even my biggest projects. Is
| linting such a bottleneck in people's workflows? Why bother
| shaving a couple seconds off a linter when your test suite and
| Dockerfiles take minutes to complete?
|
| I don't really see why I should care about ruff.
| colincooke wrote:
| This along with pydantic [0] means that 2/3 of my favorite python
| open source projects are now commercially backed. I wonder how
| long FastAPI will last?
|
| As an aside, what is the issue with versioning these days? Ruff
| and FastAPI both have massive user bases and a reliable codebase,
| but haven't released v1.0.0! Ruff hasn't even got as far as
| v0.1.0.
|
| [0]: https://techcrunch.com/2023/02/16/sequoia-backs-open-
| source-...
| amlozano wrote:
| You aren't the only one that has noticed:
|
| https://0ver.org/
|
| More seriously though, for these projects, the first version is
| version zero. If they make no major backward incompatible
| changes, why would they ever release a version 1?
| fullstackchris wrote:
| Is anyone else sick of seeing "yet another" Python tool? Python
| is so slow and irrelevant by so many standards nowadays...
|
| Fully prepared to be downvoted for these because I am all too
| aware of Python's (IMO) undeserved popularity, but the facts are
| clear: Python lags in performance against nearly any other
| "backend" or "scripting" language (compare to C, C++, C#, Go,
| Rust, and many more)
|
| My reasoning: every day I see stack overflow filled with
| repetitive Python questions, and random finance furus talking
| about their cool data analysis tools, all in Python, all with
| poor performance and hacked together with god knows how many
| libraries.
|
| The problem is indeed because Python is so accessible: anyone who
| can write Python doesn't know enough about computing in general
| to even know what the concept of performance is, let alone risks
| of relying on 1903287012 libraries to get the job done.
|
| Hell, I know half a dozen companies still using Python 2... jeez
|
| Thanks for coming to my TED rant.
| sfink wrote:
| I agree with all of the naysayers here.
|
| Speed is not my problem today, so what's the point if it's not
| solving my personal problem? Speed was my problem yesterday, and
| probably will be again tomorrow, but today it isn't and I don't
| know why random people I don't know aren't invested enough in
| solving my today problem.
|
| Even worse, they're trying to get paid for it!
|
| Seriously: what does it take to impress people? A mere 1000x
| speed increase and single point of configuration isn't good
| enough? Personally, I've waited for my much slower tools to
| finish plenty of times, I've only run a subset of the tools
| because I didn't want to wait for all of them to finish every
| time, and I've avoided configuring them because I'd have to
| figure out which one does what and how to configure each one.
|
| Yes, it's a rearchitecture, which brings with it the pain of
| rearchitectures--mainly not supporting the bespoke tools built
| with the old architecture--but isn't it a good idea to identify
| when the existing base is problematic and be able to demonstrate
| that a superior solution could be gained by starting over? And
| they've even gone to the effort of bringing in the 90% case by
| encompassing the functionality of several existing tools!
|
| I would understand the complaints better if you were somehow
| suddenly unable to run any of your existing stuff, but this isn't
| an incompatible upgrade to an existing project.
|
| </rant>
| mrkeen wrote:
| > I agree with all of the naysayers ... Speed is not my problem
| today
|
| > A mere 1000x speed increase and single point of configuration
| isn't good enough? > this isn't an incompatible upgrade
|
| I genuinely can't understand if you are for or against this
| tool.
| intellix wrote:
| He's being extremely sarcastic. He's massively for it
| [deleted]
| nicbou wrote:
| HN is never happy. Everything should be fast, simple,
| configurable, extensible, portable, retro-compatible, future-
| proof, environmentally-friendly, inclusive, offline-first, and
| above all free.
|
| For some people, nothing is ever good enough. Such is the
| nature of getting feedback from strangers. The sooner you learn
| to filter out the naysayers, the better.
|
| This tool is probably fine. But positive feedback is usually
| expressed as an upvote.
| zokier wrote:
| > Seriously: what does it take to impress people? A mere 1000x
| speed increase and single point of configuration isn't good
| enough?
|
| It is great accomplishment for ruff the project. But the topic
| here is the launch of Astral the company, not ruff the project.
| And 1000x speed increase is not a business plan.
| sfink wrote:
| Meh. Fair point, but that isn't the only topic being
| discussed. And when the topic is whether ruff the tool is
| worthwhile, the discussion is more a pile of complaints.
|
| I agree that the topic you're describing, and that is
| suggested by the URL posted, are worth talking about. It
| makes me nervous to invest time into a VC-backed linter.
| Though it seems useful enough to be forkable if things go
| sour.
|
| "VC-backed linter" is a bizarre phrase, though honestly I
| think you could have described something like Purify in Ye
| Olden Days as a linter, and it was worth spending money on.
| (And the issues with being VC-backed go well beyond simply
| being whether or not something is worth spending money on.)
| almostdigital wrote:
| This is great, I'm going to switch to this from black. Being used
| to working in other languages I feel like I'm swimming in
| molasses when using Python.
|
| It's funny that all good things for Python are not written in
| Python. Says a lot about the language.
| sfink wrote:
| It doesn't replace black, at least not yet. It sounds like
| autoformatting is planned.
| almostdigital wrote:
| Yeah, just realized that and was about to edit my comment.
| Found an issue tracking the black replacement bit:
| https://github.com/charliermarsh/ruff/issues/1904
| hkt wrote:
| This sounds nice, but um, what's the benefit to faster linting?
| Is it being slow really a problem people have? I've no experience
| of this.
| ikornaselur wrote:
| Just because you don't have the issue doesn't mean it's non-
| existent. We went from 8ish seconds with flake8 to tens of
| milliseconds with ruff. Ruff can just run as a pre-commit hook
| because it's so fast.
|
| I for one have stopped using flake8 in favour of ruff because
| of both speed and the huge amount of supported rules in ruff
| already.
| hardwaregeek wrote:
| I'm glad people are continuing the promise of Rome. High quality,
| high performance programming language tooling is a great mission
| and very much an unsolved problem. And tbh, the Python ecosystem
| is a great space. There's plenty to be built.
| kitanata wrote:
| A faster version of black is not a strong enough value
| proposition for an entire company. Ruff should remain an open
| source product. What is the point of making every half decent
| Developer tool a whole startup?
| kvathupo wrote:
| I agree and would ask: is linting that much of a bottleneck to
| development?
|
| Having an automated lint run upon opening a PR seems like a
| minor expense, especially when you can work on other tickets
| while you wait.
| ohmahjong wrote:
| It's much more noticeable when running locally. Going from
| something like black + pylint + mypy running in a pre-commit
| hook to black + ruff + mypy has been wonderful for me.
|
| It lets me actually set up another terminal session to run
| ruff on every file change - where pylint would take seconds,
| ruff is essentially instant.
|
| Side note: I really hope mypy can get the same treatment; it
| runs quickly once its cache is established, but it's terribly
| slow running from scratch.
| davidhalter wrote:
| I'm currently speeding up Mypy + Jedi in Rust. I'm pretty
| far already and it's definitely a lot faster. Tests are
| currently running 500 times faster than Mypy.
| motbus3 wrote:
| I agree with you. On the other hand, if you build something
| cool you may want to make some money... The problem imo, is
| changing the speech in the middle of the way, aham openai
| swyx wrote:
| this is too narrowly focused on what Ruff does today and not
| enough on what it could do for the Python ecosystem as a whole.
| his focus and clear execution has built an incredible wedge and
| brand, and his next product will probably be well received, and
| the next, and the next.
|
| the opportunity to bring speed and sanity to the whole Python
| Ecosystem tooling is large (if you dont feel the pain, you
| don't do enough python) and honestly i cant belive anyone has
| been (crazy enough) to try this since Anaconda.
| qudat wrote:
| I'm inclined to agree and when they eventually die, what
| happens to the tool they built?
|
| I've been using https://rome.tools and really love the work
| they put into it. It's clear they had people working fulltime
| on it. But now, what? The code is open-source, there are people
| working on it, but development has mostly dropped off. I guess
| that's okay? It just adds a lot of doubt into the longevity of
| the project.
|
| I'd be wary adding these tools into your stack because their
| progress relies pretty heavily on VC funding and a tight runway
| to profitability.
| paulgb wrote:
| > What is the point of making every half decent Developer tool
| a whole startup?
|
| I mean, paying people who work on it, for one?
| kitanata wrote:
| I'm not against folks getting paid. My question is how does
| one build an entire company selling a slightly better version
| of a widely used open source tool? Ruff is not strong enough
| to build a company from.
| paulgb wrote:
| Python has become a hugely critical language for science,
| AI/ML, finance, etc. and the current state of tooling has
| lagged the language's importance. I can think of lots of
| ways a company that solves that problem could add adjacent
| products and monetize them. Enterprise support, tooling for
| building and deploying custom lint rules, supply-chain
| security, managed builds, etc.
| VWWHFSfQ wrote:
| > X is not strong enough to build a company from.
|
| I mean, these are the famous last words of a lot of non-
| visionaries. I'm not saying that Ruff is some kind of
| unicorn, but there are a lot of cases where a seemingly
| small improvement on an existing technology resulted in a
| very successful enterprise. Docker, for example. There are
| others that I'm sure people will chime in with.
| rwalle wrote:
| Maybe your answer is correct but it is not useful, at
| all. It does not answer the question, like, providing
| real solutions.
| [deleted]
| BiteCode_dev wrote:
| 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.
| overthrow wrote:
| 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?
| sangnoir wrote:
| > Serious question, what is the path for a linter?
|
| The natural end state is yet another build service.
| VWWHFSfQ wrote:
| 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 crazy at all.
| prisonguard wrote:
| > A lot of companies would pay actual money for some
| semblance of supply-chain security.
|
| 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...
| BiteCode_dev wrote:
| That's Anaconda's business model.
| baq wrote:
| SAST/DAST products cost truckloads of money, so that's a
| possible direction. The linter is a tech demo in this case.
| BiteCode_dev wrote:
| I don't know their plan, so I can't speak for them.
|
| What I would do is build an entire ecosystem of that
| quality that would include a tool to solve the Python
| distributions problem.
|
| Either you help with deployment on the server, and you
| offer hosting.
|
| Or you help with making an installer, and you offer nodes
| to build installers for multiple OS and upload to multiple
| app stores, manage updates, cdn, permissions...
|
| You can even start small and just help with a service for
| cross-compiling C extensions and scale from that.
|
| Or provide machine learning analysis of the quality of your
| code and make companies pay for it.
|
| Or go full Continuum.
|
| They are good enough that they can pick and choose whatever
| they want, really.
|
| When you solve pain, people pay. If readthedoc managed to
| survive by being a static rst site, astral has a shot
| provided they keep the business side of things in mind as
| nicely as they build their user stories.
| Aeolun wrote:
| Cloud linting! You send your content hash to the cloud, and
| it'll tell you what errors you have.
| M3L0NM4N wrote:
| I agree, but I also don't make the decision. The free market
| decides whether their value proposition is enough, so the
| company's success is dependent on the developer demand.
| rtuin wrote:
| Perfect timing, I'm excited to what Astral will bring.
|
| The python ecosystem keeps building momentum as "doing things
| with data" becomes bigger, more accessible, and also more (near)
| real-time and I think the ecosystem would really thrive with
| better, unambiguous tools that become de facto to the community
| of builders instead of plenty of suboptimal ones to choose from.
| akprasad wrote:
| 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 that since Ruff
| is an all-in-one tool, it can parse the underlying Python files
| just once -- and since this is the most expensive phase of these
| kinds of tools, adding any extra functionality on top (such as
| linting, formatting, ...) is very cheap. And that 's to say
| nothing of the fact that Ruff is built on Rust, with the usual
| performance wins that Rust projects tend to have.
|
| I'm a little apprehensive of how development will look given a VC
| raise with the expectation of VC returns. But for now, I'm
| delighted and can't wait to see what the team comes up with.
|
| [1]: https://github.com/charliermarsh/ruff/issues/1904
| cauthon wrote:
| just starting to dabble in Rust, and I've seen PyO3 mentioned a
| number of times for writing rust bindings. What's the
| difference between Maturin and PyO3?
| shadaj wrote:
| PyO3 is the library that enables Python <-> Rust bindings,
| Maturin is a build tool for packaging PyO3 Rust libraries
| (which export Python APIs) as Python packages!
| cauthon wrote:
| thanks!
| pid-1 wrote:
| Even if no VC was involved, how do you make money developing an
| open source linter?
| darkstar999 wrote:
| They are probably looking for an ecosystem around the tool,
| like how github built on git.
| mixmastamyk wrote:
| Telemetry probably. Remember the telemetry in your terminal
| folks, on here? :cry:
|
| But you might be able to do support contracts, like ansible.
| Tough road though.
| qbasic_forever wrote:
| How did Hashi corp make money (and an eventual billion dollar
| plus IPO!) developing open source tools like vagrant, consul
| and terraform...
|
| Clearly the creator of ruff is going to expand from an open
| source tool into a company focusing on Python tooling and
| developer experience, services, etc. There is a market for
| stuff like that just based on pycharm and jet brains' success
| in the space alone.
| nwellnhof wrote:
| HashiCorp made a $270 million loss last year, more than 50%
| of their revenue.
| spullara wrote:
| A lot of the money comes from Vault which is open source
| but only used by larger organizations that want support.
| quadrature wrote:
| im sure they have a ton of ideas. my bet is that they might
| launch something in the CI/CD space. like building python
| packages/images fast, speeding up python testing or tackling
| something in ML inference.
| nine_k wrote:
| Support contracts. Custom features built to order. Other
| commercial products based on the open-source libraries for
| parsing and analysis. Running a hosted service.
|
| All this while remaining a team of 2-3, hopefully, with all
| company-running stuff minimized and outsourced.
| toyg wrote:
| I actually cursed Maturin a few years ago, as it refused to
| compile on OpenBSD and hence broke some lib I planned to use.
|
| Python is becoming a bit too reliant on Rust. Rust is good but,
| in term of portability, is just not as mature as C. If your lib
| relies on Rust, please please please test it on something
| beyond Linux and Mac.
| Aeolun wrote:
| > please please please test it on something beyond Linux and
| Mac
|
| Why? Simply because you use something that even 95% of the
| _unix_ folk do not?
|
| I can totally see how they wouldn't be concerned with that.
| Just as I'm not concerned with making my JS lib work for
| those weirdos that still run IE 5.5.
| [deleted]
| criddell wrote:
| > please test it on something beyond Linux and Mac
|
| That's asking a lot. If your platform is poorly supported by
| Rust, then maybe that's where your efforts should be
| directed. If you fix that, lots of interesting stuff beyond
| one library is unlocked.
| senko wrote:
| Theo de Raadt engaging the Rust community would be a sight
| to behold :)
| steveklabnik wrote:
| I am not aware of him saying anything about Rust beyond
| this: https://marc.info/?l=openbsd-
| misc&m=151233345723889&w=2
|
| Which doesn't mean he hasn't, of course!
| lozenge wrote:
| The main reason pylint is slow is it tries to infer the types
| of the variables, and it predates type annotations so it can go
| through multiple functions/control paths across multiple files
| to figure these out. This approach is obviated by type
| annotations and type checkers.
|
| Ruff is built for speed from the start and doesn't look at type
| annotations because you should run a type checker alongside.
| swyx wrote:
| if it's any consolation, Accel is in my mind one of the "good
| ones". they have a record of backing "good" devtool companies
| that manage open source and commercial concerns well - Vercel,
| Sentry, etc. (i'm sure theres more, those are just the two that
| i'm closest to)
| echelon wrote:
| What are the good VC companies? Not just for dev tools, but
| in general. Where do you find this information?
| swyx wrote:
| just being "in the scene" for a few years :)
|
| tbh i care more about individual investors than the fund
| brand, but its a fallback whenever meeting someone new
|
| edit: https://overcast.fm/+t_0aYbn-o/12:00 listen to steve
| krouse talk about how accel encouraged him for val.town
| even tho he didnt initially believe in it himself. thats
| not normal investor behavior. look out for people like
| that, by definition they are rare
| Night_Thastus wrote:
| 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?
| NegativeLatency wrote:
| ruff check . ---fix
| senko wrote:
| Ruff will be getting more autoformat capabilities: see the
| link in parent poster and also read the first comment there,
| from one of Black maintainers.
| Night_Thastus wrote:
| Pretty bold to try to replace Flake8 _and_ Black with one
| tool. I hope they succeed. Would be great to have a tool
| that does both _and_ is substantially faster.
| senko wrote:
| Indeed.
|
| I do hope they'll expose Ruff as a Python module / API in
| the future. I'm currently using Black to format Python
| code that's in-memory (never gets written out to disk).
|
| With Black (as an imported Py module), it's just a matter
| of passing in a string and getting one back. With Ruff as
| it is now, I'd have to write that out to disk, spawn Ruff
| process, then read the formatted file back in. Do that
| for many files and the speed advantages disappear, and
| actually it's slower.
| BiteCode_dev wrote:
| You can mount the file system in memory for that, but I
| see your point.
| senko wrote:
| I am at once:
|
| - happy because Ruff deserves full time focus and having a team
| that can focus on tooling as their main product (not a
| nights&weekends hobby) is a clear win for everyone;
|
| but also
|
| - concerned because VC is not charity, and this must surely come
| with strings attached (in terms of future growth); I haven't seen
| many VCs aiming for "sustainable profitable business providing
| great value for the community" type exits; then again, if this
| turns into a Hashicorp-type story that wouldn't be too bad an
| outcome either
| andy_xor_andrew wrote:
| In the last few weeks I've been using Python to play with some
| LLMs locally, and at first I thought there was some bug in VS
| Code because the linting was so slooooooow.
|
| This seems long overdue! Looks like a great project :)
| throwaway2137 wrote:
| Yet another case of Python developers getting a basic utility
| which any other language had available for years and being amazed
| at something which is an industry standard literally anywhere
| else. Linter taking multiple seconds is not a problem which
| occurs in any other popular language.
|
| It really boggles my mind why is this lang so popular. Once you
| write something a little more involved than an utility script or
| jupyter notebook you start dealing with stupid problems like
|
| - venv
|
| - no standard package manager, dependency resolution taking
| forever
|
| - multiprocessing
|
| - untyped libraries (looking at you boto)
|
| - `which python`
|
| - wsgi
|
| - CLI debugging
|
| et cetera.
|
| I'm currently working daily with Python, and compared to the .NET
| world I'm coming from, it's MINDBLOWING how many things are
| annoying here. In my previous job I was able to spend several
| years working on a C# app barely ever needing to touch the
| terminal, everything came with batteries included, tooling /
| autocompletion / package management / performance / time spent on
| dealing with little issues was REALLY good in comparison.
|
| Reason I moved is that it's hard to find a job in C# which isn't
| soul sucking stuff like banking / maintainance / insurance, so
| I'm dealing with it as the project is interesting at least.
| serial_dev wrote:
| Same, the tooling makes a big difference when it comes to
| languages.
|
| I'm a Dart developer by day, Rust enthusiast by night, both are
| relatively modern languages and the tooling just feels right
| (of course nothing is perfect): the analyzer, linter, testing,
| dependency management, lsp, formatter are all just there.
|
| I never want to go back to 20-30 year old languages where, for
| all these tools, there are 10 different subpar solutions with
| three decades of baggage, history, and context (though, of
| course, congrats on the 1000x speed up).
|
| Python, JavaScript, Java, C++, are all in this category, and
| honestly, even community favorites like TypeScript and Kotlin
| have similar warts.
| mixmastamyk wrote:
| > Linter taking multiple seconds is not a problem which occurs
| in any other popular language.
|
| It doesn't happen in Python either. So that's good.
|
| > barely ever needing to touch the terminal
|
| Not really a good sign, point-click developers are not usually
| the strongest. That said I like things to work easily and don't
| have many quarrels with Python. Certainly fewer than most other
| languages.
|
| Sounds like you're not very familiar with it and got used to
| C#. I don't have a problem with anything you list.
| Phelinofist wrote:
| Coming from Java I have the same thought. Other languages seem
| infantile in comparison.
| booleandilemma wrote:
| _Once you write something a little more involved than an
| utility script_
|
| I only use Python specifically for utility scripts for this
| reason.
| robswc wrote:
| >It really boggles my mind why is this lang so popular
|
| a lot of problems can be solved well with python.
|
| The frameworks are also priceless. What is an alternative to
| Django, for example?
|
| Nearly every backend service I create is with python, unless it
| needs speed or rock-solid reliability. For that I use Go.
| Dynamic UI/UX I use nextjs with python backend.
| smt88 wrote:
| .NET is a phenomenal alternative to Django with excellent
| tooling, ecosystem, and performance.
|
| I think the only irreplaceable part of the Python ecosystem
| at the moment is the math/stats/NN stuff. I wouldn't hire a
| data scientist who refused to learn Python, but I would hire
| a web dev who refused to learn it.
| ibejoeb wrote:
| > .NET is a phenomenal alternative to Django
|
| Presumably you're referring to ASP.NET, but if not, I'd
| love to know what you're working with. They're not really
| all that comparable. If I want to make something very
| quickly and need it to be trustworthy, I'll use Django,
| especially with the admin site. That said, these days I'd
| much rather work in the .NET ecosystem.
| ehsankia wrote:
| Maybe tooling for other languages are faster because the dev
| has to spend a lot more time specifying a lot more things / are
| a lot more verbose. The reason tooling on Python is slow is
| exactly why people love it, because it's lightweight, easy to
| quickly whip up a script. Take a one line hello world vs having
| to create an entire project and 10 lines in C#.
|
| Not having to type annotate every tiny thing is also great. You
| can type only what brings you value and leave the rest to be
| inferred. It really is the best of all worlds.
| smt88 wrote:
| Choosing a language based on initial setup or Hello World is
| valuing the wrong things.
|
| You set up an application once, write each line a few times,
| read it dozens of times, and run it millions of times.
|
| The most costly part of that process is reading/rewriting
| because developer time is expensive.
|
| Language choice should be optimized to make it easy to read
| other people's code and to prevent mistakes from getting into
| production. Python is not near the top of the pack in those
| dimensions.
| Tossrock wrote:
| Roblox is a big C# shop that's pretty fun - platform tech in
| the gaming space. And hiring!
| Aeolun wrote:
| Good for him.
|
| I'm less enthusiastic about them hiring one of the core
| contributors of Rome away though.
|
| I don't care about Python, but I very much care about Typescript.
| singhrac wrote:
| I cannot comment on the feasibility of building a profitable open
| source business around Python tooling, but I can say that I'm
| very very glad someone is taking that risk: both Charlie in
| career/business risks, and the VCs in taking on the financial
| risk. I just get to benefit - ruff is really nice and I
| anticipate big improvements to Python tooling as a result, at no
| cost to me.
| traceroute66 wrote:
| I think HN should ban people who are too lazy to put a proper
| subject line on their post.
|
| I mean, "Astral" .... what's that ? The "astral.sh" domain
| doesn't tell me anything either.
|
| I'm sure those in the know automatically know what it is, but for
| the rest of us, the title is completely and utterly meaningless.
| rochak wrote:
| +1. Comes across as a bad attempt at gaining publicity.
| bityard wrote:
| Agreed. I have a policy of _never_ clicking on a link if I
| don't have at least _some_ idea of what's behind it, and that
| includes HN. It's the top link on HN right now and I came to
| the comments just to see what it was even about.
|
| And yes, I have regretted clicking on HN links before.
| Zanni wrote:
| Banning is a little extreme, but I agree that title is
| unhelpful. Better title would be "Ruff is a fast Python linter
| written in Rust" (which is a slight paraphrase from one of the
| subheads).
| swyx wrote:
| especially when it doesnt seem to be the ruff founder who
| submitted this particular post. maybe dang or someone will
| rename it something more appropriate but from hn comments its
| pretty clear what the context is
| 1f60c wrote:
| Or "Ruff creators found Astral Software Inc." or something.
| ricardobeat wrote:
| Editoralizing is discouraged and your post will end up
| edited to match the original URL's title either way.
| danpalmer wrote:
| Having written a bunch of Flake8 plugins, including custom
| plugins for internal use at a company, and using 5-10 popular
| plugins on every Python project I work on... rewriting the entire
| linting ecosystem in one monolithic Rust tool doesn't feel like
| the best solution. There's no good story for building an
| ecosystem around this yet, and I think that's a big hurdle to
| overcome.
|
| Ruff is fast, sure, but the benchmarking seems a little
| disingenuous, as I believe their number includes caching, but
| doesn't necessarily include caching for other tools. In fairness,
| not all the other tools have caching, but it is common to run
| them through pre-commit and therefore only on the current git
| diff, which speeds them up by orders of magnitude.
| neuronexmachina wrote:
| > Ruff is fast, sure, but the benchmarking seems a little
| disingenuous, as I believe their number includes caching, but
| doesn't necessarily include caching for other tools.
|
| It looks like the ruff benchmark is run with the `--no-cache`
| arg:
| https://github.com/charliermarsh/ruff/blob/main/CONTRIBUTING...
| qbasic_forever wrote:
| There's no reason your custom bespoke plugins couldn't be
| called by ruff as necessary. It's silly to burden the happy
| path of 99% of users who just need common sense python linting
| with those edge cases and custom needs.
| danpalmer wrote:
| That could be done in one of two ways:
|
| - Supporting flake8 plugins, using the existing community,
| and sacrificing the speed.
|
| - Requiring new plugins, in Python or another scripting
| language, sacrificing the community progress and goodwill,
| and sacrificing some of the speed.
|
| Neither of these options is good. The Python linting
| ecosystem is a mature one with a lot of investment into the
| existing tools, and rather than try to speed those up (which
| could be done in a number of ways), Ruff started from
| scratch.
|
| It doesn't feel like the right decision for an ecosystem that
| is as community focused as Python, and the engineering
| reasons feel like a toss up at best.
| qbasic_forever wrote:
| ???
|
| There is no downside to adding your bespoke flake8 plugins.
| For people that don't use them (99% of people) they get the
| benefit of blazing speed. For your custom plugins you live
| with the tradeoff of slower execution to do those AST
| passes with flake8/python tools. Even if ruff didn't exist
| you would still be burdened with your slow flake8 plugins
| speed. There is zero downside to you and only upside to
| people that aren't you.
|
| Kinda just sounds like you're grousing because somebody
| moved the cheese.
| danpalmer wrote:
| It's not just "custom" plugins, it's all third-party
| plugins though right? If someone wants to publish a new
| linter for something, right now they can, and others can
| use it easily, but Ruff centralises that and makes it
| harder.
|
| You're right that it will probably still be faster
| overall because "most" linting will be done with Ruff and
| any extras would be done externally, but now you've
| either got 2 tools when you had 1 before, or you've got
| to shell out to Python which adds overhead, or you've got
| to rewrite plugins in a Ruff-compatible format, or
| something else.
|
| > Kinda just sounds like you're grousing because somebody
| moved the cheese.
|
| I'm just disappointed that someone looked at slow linting
| and decided the answer was their own new tool, rather
| than participating in the existing community. Now the
| effort has forked, it'll take more work overall in the
| community, and we were already lacking engineering
| resource.
| qbasic_forever wrote:
| I'm disappointed the flake8 community hasn't prioritized
| performance and has led to python linting being much less
| widely utilized. I'm looking forward to tools like ruff
| giving much faster and more usable linting.
| bin_bash wrote:
| That's what esbuild did for their plugins--which made them
| useless since it kills any performance gains of switching to
| esbuild in the first place
| qbasic_forever wrote:
| Yes the point isn't esbuild will have magic pixie dust that
| makes nodejs AST processing magically faster--that's
| objectively impossible. The point is you can migrate to the
| new system over time without losing critical plugin
| functionality right now. It's not to live in a steady state
| with old slow nodejs plugins.
| jfb wrote:
| If they can get a good type checker in ruff, or produce one as
| comparably better than mypy than ruff is from pre-existing tools
| ... well.
| thelonelygod wrote:
| Does anyone have recommendations for a good jinja linter?
| nichochar wrote:
| Seems cool but i wish they had an auto-formatter.
|
| After years of coding, I have found that taking away the
| opinionated-ness and doing a format-on-save (ideally, that's
| supported by the language like Golang) is by far the most
| productive.
|
| I'm sad that python is still prevalent everywhere, given how
| terrible the language and its tooling is, but it seems it's not
| going away with the A.I wave, so companies like this will become
| more valuable.
| [deleted]
| lchengify wrote:
| User of Ruff here and follower of Charlie's work.
|
| I've been slinging python since 2003, and I've used a pretty wide
| swath of the toolchain. I've also had the (pleasure?) of using
| python in a lot of different contexts: desktop applications, web
| programming, custom scientific calculation plugins, grad school
| hacks, Maya, and obviously Juypter notebooks.
|
| My honest take: Toolchain tools like Ruff are the only way the
| Python ecosystem as a whole moves forward. In order to be broadly
| adopted by the wide swath of use cases, it needs to be
| universally applicable _and_ have a killer reason for being (in
| this case, speed, which opens up new use cases that didn 't exist
| before).
|
| Ironically, the commonality to these toolchain improvements for
| python ... is that they not be written in Python. If you want
| good analogues, you can look at the work that others have done
| with multithreading and trying to bypass the GIL, which is one of
| my other hobby horses with Python. Hot take: For most users,
| python is not used for itself, but more to flexibly orchestrate
| some other low-level problem. This is why Maya, scipy, most of
| data science, and other DSLs use python so much.
|
| To empower these users, you either need to (1) work in the
| compiler (2) below the GIL or (3) do the heavy lifting of
| wrapping around the language flexibility without requiring
| changing the python code itself. Ruff does that, and I imagine
| the thesis of Astral is to extend that philosophy to the rest of
| the toolchain.
|
| Lastly, in the spirit of this site, I'll give my second spicy
| take: I think web development in python is on the decline, and
| the future of python is in data science and related fields. These
| fields care _a lot_ about fast toolchain, and will use ruff and
| other tools to achieve those ends without modifying legacy code.
| For web, node has won. I know users that use python but you can
| 't really beat needing to learn just one language vs two to build
| a web app.
| coldtea wrote:
| > _Hot take: For most users, python is not used for itself, but
| more to flexibly orchestrate some other low-level problem._
|
| Well, there's nothing wrong with that.
|
| In fact, a great "glue language" (and Python sure needs lots of
| improvements in many areas) is kind of the holy grail of IT!
| TheAlchemist wrote:
| Don't have an opinion about it yet, but I love the website - it's
| really fast !
| clivestaples wrote:
| The site is very well done and impressed me too. It's built
| with Next and noticed Astral is backed by Guillermo Rauch
| himself.
| neves wrote:
| 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 questions that aren't answered in
| the site.
| plorkyeran wrote:
| There's three relevant speeds for linters:
|
| 1. Fast enough to be live updating as you type in an IDE.
|
| 2. Slow enough that running a linter has to be a separate
| action you take, but fast enough that you don't go do something
| else while it's running.
|
| 3. So slow that it's an asynchronous task that you launch and
| then come back to later.
|
| Ruff is in the first category, while most other python linters
| are in the second. This level of performance enables a
| qualitative difference in how you interact with the tool. If
| you are invoking it as a separate task, then going from 500ms
| to 50ms is indeed not very interesting, though.
| kstrauser wrote:
| I disagree about the speed. I don't have a problem with
| pyflake, but running `time ruff -s .` in a project with 1,236
| Python files took 78ms. At that speed, it could re-check the
| file I'm working on in an editor after every keystroke with no
| noticeable latency. It's not just a little bit faster. It's
| freakishly, ridiculously, gone-plaid faster.
|
| Edit: for comparison, flake8 took 8.19s and found approximately
| the same number of issues. pyflakes took 4.49s and found fewer.
| emptysea wrote:
| Speed is a problem for linters. If I spend 200ms of CI time
| instead of say 5minutes that's a real difference in toil and CI
| spend
|
| Ruff has an LSP too so it integrates well with editors unlike
| flake8 and similar which only work on save -- and are really
| slow
| neuronexmachina wrote:
| > How does it compare with Pyflake8 in error messages?
|
| 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
| divan wrote:
| Those progress bars with time of other linters - is it a joke or
| it's a data from stupidly enourmous codebase? Or slow (>1s)
| linters is something that is normal in python?
| qbasic_forever wrote:
| It's linting the entire CPython codebase and standard library,
| which is quite large (possibly one of the largest python
| codebases). But yes, pure python linters will be inherently
| quite a bit slower than a native implementation. The point of
| ruff is that it's so fast you forget or never even notice it's
| running. Every change, every little modification, etc. should
| always be linted with near instant feedback.
| overthrow wrote:
| I worked on a 50k-100k loc python codebase where the linters
| took a full minute to run if you deleted your cache. And I did
| try to optimize it. I wouldn't be surprised if that's normal.
| [deleted]
| bbkane wrote:
| Super excited about ruff improvements, but I gotta comment that
| the CSS for a clicked link in astral.sh looks like normal text. I
| clicked a link, hit back in Android Firefox, and couldn't find
| the link again.
| fnetisma wrote:
| I'm trying to use this via ssh into another instance on VSCode,
| but it doesn't work, any help?
___________________________________________________________________
(page generated 2023-04-18 23:00 UTC)