Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Astral

astral.sh

Post reply on HN
Print view View original

231–240 of 248 posts

Re: Astral

#231

Post by mixmastamyk »

kstrauser wrote: post #212
mixmastamyk wrote: post #187

Earlier quoted context omitted.

Don't need to lint the whole repo, just the files you're working on currently. Git can tell you what has changed.

That’s not true unless you have a dependency map between all modules. (Note: that’s what I did in pytest-fastest to only retest modules that had changed, or that imported modules that had changed.) Otherwise, if you rename a function, you wouldn’t know what all broke.

You don’t need to check everything, every time. (Another case of yours is when you want all types checked.)

Good time for a full check is when new feature is complete. Run all linters, typers, and full test suite, until clear. Then commit and push.

Re: Astral

#232

Post by steveklabnik »

criddell wrote: post #230
thayne wrote: post #224

Earlier quoted context omitted.

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?

It matters to Theo, due to policies created for specific objectives. It does not matter to many other people.

Re: Astral

#233

Post by steveklabnik »

jeffparsons wrote: post #218
robocat wrote: post #210

Earlier quoted context omitted.

I am wildly guessing that Theo’s beef is more that rust uses a lot of memory (paraphrase: 640kb should be enough for anybody). OpenBSD does integration builds on a variety of different systems, and maybe Theo noticed the OpenBSD/386 build failing due to lack of necessary memory?

That seems a reasonable guess, but it brings me straight back to wondering why such a diversity of build environments is necessary or useful. And my wild guess is that it's mostly because cross compilation is still a second class citizen in most languages today. Though I guess it could be a kind of cultural expectation that you should be able to compile the whole OS on the hardware you're running it on.

My understanding is that the policy of the project is that the base system must not be cross compiled. My understanding of why is that they want to be able to fully bootstrap from base itself.

Re: Astral

#234

Post by neves »

emptysea wrote: post #40
neves wrote: post #33

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…

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

No linter takes 5 minutes to analyze a bunch of modified files for your next commit.

Re: Astral

#235

Post by muglug »

baq wrote: post #81
overthrow wrote: post #16

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?

SAST/DAST products cost truckloads of money, so that’s a possible direction. The linter is a tech demo in this case.

Some SAST products cost a truckload of money.

There's a FOSS SAST product for Python already, though, called Pysa: https://pyre-check.org/docs/pysa-basics/

Re: Astral

#236

Post by riceart »

unethical_ban wrote: post #203
riceart wrote: post #194

Earlier quoted context omitted.

No it was not. The question was directed at the commenter about assessing skill, never made any statement disparaging said skill. Also you seem to be unaware of the relationship of this commenter - you may want to examine their Twitter from before this story was submitted here. Or go on and prove yourself a prat, I won’t stop you.

You're out of line, no need to name-call. I may not want to examine the website and twitter feeds of every commenter on here. Perhaps it wasn't rude, but given how pedantic many people here are, I took the original comment to be a criticism of praising the coder, not a genuine question of evaluating code quality.

> I may not want to examine the website and twitter feeds of every commenter on here.

While that sounds fair enough, the commenter had already noted their relationship within the original thread here by the time you decided to make that completely dismissive reply.

If you’re going to just tritely counter a statement it seems rather foolish not to do a bear minimum of observation.

Re: Astral

#237

Post by meatjuice »

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…

Using something like [poetry](https://python-poetry.org) would make your workflow much better. With this tool, you don’t need to care about venv and `which python`.

Re: Astral

#238

Post by jeffparsons »

steveklabnik wrote: post #232
criddell wrote: post #230

Earlier quoted context omitted.

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

It matters to Theo, due to policies created for specific objectives. It does not matter to many other people.

I guess at the end of the day this is all that really matters. If there are specific goals that Theo has around this, then there's no point in me second-guessing whether those are "reasonable"; it's a matter of values and preferences and whatever.

Whereas if this conversation was about something with broader stewardship, like _Linux_, I'd be saying this is silly, you shouldn't be compromising other things just so you can build your RPi kernel on an RPi.

Re: Astral

#239

Post by ehsankia »

smt88 wrote: post #226
ehsankia wrote: post #184

Earlier quoted context omitted.

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

Do you honestly think "readability" is only about whitespace and semicolons?

Compare

    namespace HelloWorld
    {
        class Hello {         
            static void Main(string[] args)
            {
                System.Console.WriteLine("Hello World!");
            }
        }
    }
to

    print("Hello World!")
and

    std::ifstream t("foobar.txt");
    std::stringstream content;
    content
to

    with open('foobar.txt') as file_object:
        content = file_object.read()
How can you honestly look at any of that and claim Python isn't far more readable. It literally reads like English. "With open foobar.txt as file object, content equal file object read". Compare that to whatever monstrosity the ifstream string stream << rdbuf crap is...

Re: Astral

#240

Post by senko »

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…

I think latchin onto this example misses the crux of his raitonale:

> In OpenBSD there is a strict requirement that base builds base. So we cannot replace any base utility, unless the toolchain to build it is in the base.

> Such ecosystems come with incredible costs.

Basically, the cost of adding rust to the OpenBSD base system currently far outweights the proposed benefits (reimplement fileutils), especially considering people will probably not want to pour in the effort needed to rewrite those with strict POSIX compliance (which is another requirement).

He's not saying rust isn't useful but that it wouldn't be a net benefit to have a hard dependency on it in the base system. In the BSD world folks take a very strict and conservative view of what can go in base (and for good reason IMHO).

This is different from the GP comments about just making it possible to use rust programs/libraries in OpenBSD, so we're definitely on a tangent here.

Post reply on HN