Astral • Hacker News Board

Re: Astral

#221

Post by globular-toast » Wed, Apr 19, 2023, 9:36 AM UTC

mixmastamyk wrote: post #185

throwaway2137 wrote: post #164

Earlier quoted context omitted.

> Not really a good sign, point-click developers are not usually the strongest. In principle I agree, but my point is - it was possible to be fully productive being just a point-click developer. > It doesn't happen in Python either. So that's good. pyright + black + isort hook in the project I'm working on takes 1-5 seconds on an M1 mac on save. We're moving to ruff for this reason. Never saw this anywhere else. > I…

I mentioned elsewhere but might as well here again. These tools should only be run on the files that changed, not every single one in the repo. I run my tools with the script equivalent of: git status | grep \.py | tools And it should exit in a split second. We have a pretty large codebase, though not gigantic.

People seem to forget the three ways to make things faster in computers:

1. Micro-optimisation,

2. Better algorithms,

3. Change the problem.

The potential impact of each of these increases as you go down.

Choosing Rust over Python is micro-optimisation. All things being equal, the impact isn't going to be that great. People are like "let me squeeze out every ounce of power from my CPU so I can run a linter on the entire codebase every time I save". Python folk are like "why on earth would you do that?" We simply changed the problem.

Re: Astral

#222

Post by mbwgh » Wed, Apr 19, 2023, 10:19 AM UTC

claytonjy wrote: post #170

PaulHoule wrote: post #99

Python needs something like pip and poetry that is (1) correct, and (2) faster than poetry.

This might be Pyflow, written in rust: https://www.github.com/David-OConnor/pyflow

Thanks for mentioning this, wasn't aware of this potential alternative to poetry (which I keep making mistakes with, since I only use it every few months or so).

Re: Astral

#223

Post by lozenge » Wed, Apr 19, 2023, 10:29 AM UTC

fsckboy wrote: post #202

rattray wrote: post #188

Earlier quoted context omitted.

Ruff is faster than many tools which don't do type checking. Ruff works well regardless of whether you use type hints.

that's dodging the question a little bit? let's say Ruff is faster because it's so good, how much faster than type checking alternatives would this great tool be if it did type checking?

That depends on how you do type checking and more specifically type inference. Mypy infers types of local variables but not function boundaries as it expects you to annotate function arguments and return values.

In mypy a variable taking values of two types is an error (unless explicitly annotated) which means you can assume the type from the first assignment statement and then use that assumption every other time the variable is used/assigned. In pylint it allows variables to take multiple types and only emits errors when an operation is invalid against one of the types. E.g. `x[0]` is valid for lists and tuples so you could assign it a list or a tuple depending on some condition.

The number of possibilities it considers quickly multiplies. Eg if your function is of the form `if blue_condition: x = blue_action(x)` that's a doubling of the possibilities and ten flags -> 1024 possibilities. (pylint has some heuristics on when to give up.)

The advantage of pylint is that it doesn't require your code to fit a certain style. But nowadays people have type annotations and they prefer to use them even if it means changing their code style a bit here and there.

Other type inferers with different approaches are pyright, Jedi, Pyre, pytype etc with different tradeoffs.

Re: Astral

#224

Post by thayne » Wed, Apr 19, 2023, 11:26 AM UTC

jeffparsons wrote: post #201

robocat wrote: post #169

Earlier quoted context omitted.

That email (from Dec 2017) ends with “Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.”. I presume Theo is actually complaining about using more than 3 GB (?) of memory, but still it really shows the different cost-versus-benefit decisions that we all make.

Is it actually reasonable to expect compiler toolchains to work on old or underpowered hardware? Or is the real problem that cross-compilation is still a special case, rather than being the only way compilers work? If it wasn't still normal to depend on your target environment being the same as your build host, would anyone really want to do serious development work directly on their RPi/Gameboy/watch/whatever, just…

The rust compiler runs on i86, the complaint is that it can't compile the rust compiler, because it uses more memory than is addressable on i86.

Re: Astral

#225

Post by bluewalt » Wed, Apr 19, 2023, 2:37 PM UTC

benjaminwootton wrote: post #215

throwaway2137 wrote: post #112

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 jup…

I agree on the venv, 'which python', and packages and I would add Python V2/V3. I work on a few Macbooks and have to occasionally return to Python. It's constant firefighting on environments.

Maybe People should take a closer look to dev containers: https://containers.dev/

Re: Astral

#226

Post by smt88 » Wed, Apr 19, 2023, 2:49 PM UTC

ehsankia wrote: post #184

smt88 wrote: post #139

Earlier quoted context omitted.

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…

> 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. I think most people would definitely disagree with you on the first point. As far as languages go, Python is probably one of the most readable ones out there. It's often even compared to pseudocode because well written Pytho…

> As far as languages go, Python is probably one of the most readable ones out there.

I could not disagree more. Python (as most people write it) has many things that make it less readable:

1. Semantic whitespace (absolute disaster for readability, almost as bad as YAML)

2. Choosing to "save keystrokes" by removing helpful visual cues that other languages have, like parentheses, semicolons, and brackets -- these things make scanning much easier

3. As most people write it, very few line spaces, making Python look like an unbroken run-on sentences instead of nice blocks of code

I've been writing and maintaining code for 26 years, and I've worked a lot with C#, JS/TS, Python, and PHP. I know other languages but haven't spent as much time with them.

Out of those, PHP is ironically the most readable because of its $ variables, and then the order is C#, TS, JS, and then Python. Python is hard to scan and just looks like a brick wall at first glance.

Re: Astral

#227

Post by smt88 » Wed, Apr 19, 2023, 2:55 PM UTC

ibejoeb wrote: post #155

smt88 wrote: post #140

Earlier quoted context omitted.

.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.

> .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.

> Presumably you're referring to ASP.NET

Sure, but .NET includes ASP.NET.

> If I want to make something very quickly

The difference in setup time between a modern .NET 7 web application and Django is basically nothing. You can have a boilerplate project in a few seconds, and the Hello World for the API side is 4 lines:

    var builder = WebApplication.CreateBuilder(args);
    var app = builder.Build();\
    app.MapGet("/", () => "Hello World!");
    app.Run();

> and need it to be trustworthy

I don't understand what this means.

Security? .NET is very likely more secure out of the box because it's supported by a far larger company and is used by so many large organizations.

Lack of runtime errors? You're going to have more in Python because it doesn't have a compiler with strict rules.

Re: Astral

#228

Post by jorams » Wed, Apr 19, 2023, 4:26 PM UTC

bin_bash wrote: post #26

qbasic_forever wrote: post #10

Earlier quoted context omitted.

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.

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

Having now switched several projects from webpack+babel to esbuild, with a bunch of plugins to replace various bits of resolution magic, SCSS compilation, and more, the performance gains are consistently astronomical. Simple builds go from taking several seconds to consistently completing in an unnoticeable amounts of time. Full rebuilds are still significantly faster than incremental (--watch) builds used to be.

Setting this up takes a bit more work than for webpack, and it's easier to run into limits on what's reasonably possible, but I don't intend to ever go back.

Re: Astral

#229

Post by mixmastamyk » Wed, Apr 19, 2023, 4:53 PM UTC

brenns10 wrote: post #196

mixmastamyk wrote: post #185

Earlier quoted context omitted.

I mentioned elsewhere but might as well here again. These tools should only be run on the files that changed, not every single one in the repo. I run my tools with the script equivalent of: git status | grep \.py | tools And it should exit in a split second. We have a pretty large codebase, though not gigantic.

You might be interested in pre-commit which does exactly that! https://pre-commit.com/ It probably will also support Ruff if it doesn't already.

Yup, I know it, thanks. Think of the above as pseudo code.

Still, I want some things to run more often than commit, such as pyflakes.

Re: Astral

#230

Post by criddell » Wed, Apr 19, 2023, 4:55 PM UTC

thayne wrote: post #224

jeffparsons wrote: post #201

Earlier quoted context omitted.

Is it actually reasonable to expect compiler toolchains to work on old or underpowered hardware? Or is the real problem that cross-compilation is still a special case, rather than being the only way compilers work? If it wasn't still normal to depend on your target environment being the same as your build host, would anyone really want to do serious development work directly on their RPi/Gameboy/watch/whatever, just…

The rust compiler runs on i86, the complaint is that it can't compile the rust compiler, because it uses more memory than is addressable on i86.

That’s what the person was getting at. Does it matter if it can be cross-compiled elsewhere?