Hacker Newsnew | past | comments | ask | show | jobs | submit | jerrygenser's commentslogin

so if you pick max-5x or mx-20x than pro... are you getting 0 now?


It's also good as an @explore sub-agent that greps the directory for files.


Acquisition of noam shazeer to supercharge their Gemini flagship model line I think made a bigger impact.

To make an argument it was Kevin Hou, then we would need to see Antigravity their new IDE being key. I think the crown jewel are the Gemini models.


A common use of asyncio is a server framework like fastapi that schedules tasks. I used such a framework for a while before realizing that I needed to create_task for within-task concurrency.


Basedpyright is not rust but it's a fork of pyright with added features that are otherwise locked in vscode


It's written in Typescript, which is a super weird choice.


Wasn’t pyright made specifically for VSCode? That would explain TS.


Yes, but why they did not write it in a compiled language? Pyright is pretty slow in large code bases and takes a lot of RAM. Javascript can be faster than python in some cases, but Python is so easily extendable with C,C++, Cython, Rust. They could use Python with one of the compiled language.


Because they wanted it to be usable on the web, and I guess WASM wasn't where it is right now when they started.


It's also horrible for fasle positives unless your project happens to be the exact same setup as the maintainers' - I had to turn off the actual type checking on it. I've since moved wholesale to the Ty alpha and it feels a hell of a lot smarter.


It also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL):

https://github.com/microsoft/pyright/issues/1739

https://docs.python.org/3/glossary.html#term-EAFP

https://docs.python.org/3/glossary.html#term-LBYL


Sometimes dynamic Python idioms are incompatible with typed Python. I personally think that's fine, since I consider static typing a significant improvement overall.


This isn’t. They actually fixed that bug. Then they changed their minds and backed the fix back out again because they don’t think you should write Python that way:

> I think EAFP is a very unfortunate and ill-advised practice.

They want you to not write the idiomatic Python:

    try:
        foo = bar["baz"]["qux"]
        ...
    except KeyError:
        ...
…and instead write the non-idiomatic version:

    if "baz" in bar and "qux" in bar["baz"]:
        foo = bar["baz"]["qux"]
        ...
    else:
        ...
If this were a linter then I would accept that it is going to be opinionated. But this is not a linter, it’s a type checker. Their opinions about EAFP are irrelevant. That’s idiomatic Python.


Well I agree with them. The second code is clearly better. Exceptions should be used for error handling and if those keys are actually optional then you should explicitly check if they exist (or use something like `bar.get("baz")`).


You are welcome to that opinion, but type checkers should not be opinionated, especially if they push people to write non-idiomatic Python. If you think this should be written a different way, that’s what lint rules are for.


Actually Python type checkers must be opinionated. Python doesn't define the semantics of type annotations so type checkers have to choose them.

They don't always choose the same options, so some Python code may type check in one type checker and not in another.

Yes this is a dumb situation but that's how it is. So Pyright has to make a choice here, and they chose the most sensible option.

You're free to disagree of course.


Eww, what? I hadn’t seen that before. Yikes, I hope the situation’s improved. I’d be butting into that continually.


I'm sorry, I can't take seriously any piece of software which decided to prefix the previous version's name with "based". I'm aware this is a me problem.


Definitely this. I commend author of BPyright, but clown (?) avatar, unknown identity of maintainer, and name of the fork rub me off wrong way.


Hah. I love the name. It implies that whatever the original “pyright” was doing wasn’t keepin’ it real. This new version, it’s “based” so it must be somehow more “real” and “grounded” and “legit”.

All I know is it is much more strict about stuff than pylance was.

Also a me problem!


You still have to write the resolver for graphql. I've seen. N+1 with graphql if you don't actually use data loader+batch pattern OR if you use it incorrectly.


Corporations are picking the side that's in power. If team blue is in power they would pick blue. Corporations are (usually) not moral or inherently politically motivated other than to the extent of optimizing short term shareholder value.


You are being reflexively downvoted, but I am not certain as to why. The assessment strikes me as accurate. Few corps I worked for were willing to go on a limb 'for a cause'. The exceptions were smaller companies where owner had a much bigger say and could effectively align goals with their beliefs.


Re the overnight that's why some providers are offering there are batch tier jobs that are 50% off which return over up to 12 or 24 hours for non-interactive use cases.


Why do you suspect it was vibe coded? There are 2 substantive files that are each less than 100 lines...

Also the readme doesn't have the usual emojis for every bullet point.


The godoc on logging.go is in the "AI style" rather than in the style of a typical godoc.


Comments on every other line stating what the line does is very LLM


You could remove venture and it would still be accurate


Sorry, but I don’t find it a very insightful comment.

(Removed comment about it being AI-generated since that might be unfair.)


Its not AI generated. Sorry friend. Even if it was, assess the message, not the medium :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: