pytype VS Laminar

it's open source! check out https://github.com/google/pytype and https://github.com/google/pytype/blob/main/docs/developers/t... for more on the multi-file runner

Pytype checks and infers types for your Python code - without requiring type annotations. Pytype can catch type errors in your Python code before you even run it.

Pyre from Meta, pyright from Microsoft and PyType from Google provide additional assistance. They can 'infer' types based on code flow and existing types within the code.

we've written a little bit about what pytype does differently here: https://google.github.io/pytype/

our main focus is to be able to work with unannotated and partially-annotated code, and treat it on par with fully annotated code.

So, I tried out pytype the other day, and it was a not a good experience. It doesn't support PEP 420 (implicit namespace packages), which means you have to litter __init__.py files everywhere, or it will create filename collisions. See https://github.com/google/pytype/issues/198 for more information. I've since started testing out pyre.

What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to use unless you're an engineer for those companies.

Am just curious if mypy is really the best option right now?

[1] https://github.com/google/pytype

At Luma, we're using mypy to check nearly our entire code-base, including our Maya-related code, thanks to these latest changes. Fully adopting mypy (or an alternative like pytype) is no small feat, but working within a fully type-annotated code base with a type checker to enforce accuracy is like coding in a higher plane of existence: fewer bugs, easier code navigation, faster dev onboarding, easier refactoring, and dramatically increased confidence about every change. I wrote about some deeper insights in these posts.

Check out https://github.com/google/pytype

i work on https://github.com/google/pytype which is largely developed internally and then pushed to github every few days. the github commits are associated with the team's personal github accounts. pytype is not an "official google product" insofar as the open source version is presented as is without official google support, but it is "production code" in the sense that it is very much used extensively within google.

pytype dev here - thanks for the kind words :) whole-program analysis on unannotated or partially-annotated code is our particular focus, but there's surprisingly little dark PLT magic involved; in particular you don't need to be an academic type theory wizard to understand how it works. our developer docs[1] have more info, but at a high level we have an interpreter that virtually executes python bytecode, tracking types where the cpython interpreter would have tracked values.

it's worth exploring some of the other type checkers as well, since they make different tradeoffs - in particular, microsoft's pyright[2] (written in typescript!) can run incrementally within vscode, and tends to add new and experimentally proposed typing PEPs faster than we do.

[1] https://github.com/google/pytype/blob/main/docs/developers/i...

My quite niche open source project broke this threshold last year, via Github sponsorships. Of course, I put a lot of time into it, so it's not "passive income" or even "market rate income", but still, without these sponsorships I wouldn't be able to work on it so much.

The project is Laminar, a UI library for Scala.js https://laminar.dev

I've noticed that Laminar and the newly released Kyo point that they don't use a lot of macros as a feature. Laminar says "Easy to understand: no macros", while Kyo emphasizes "Note: defer is currently the only macro in Kyo. All other features use regular language constructs." It seems that using less macros is something library users will like.

https://laminar.dev/ might be what you need. Though I wish there was a more beginner friendly (I'm not from front-end world) tutorial for me to follow along.

Have you looked at Laminar and Tyrian? Especially Tyrian seems to be close to what you're looking for.

For Scala there is Laminar, which has an even flashier website with nice docs. I haven't tested it out though, as I have never used Scala.

I found this scala library called Laminar which looks super similar to solid. They use signals and has no virtual dom. State changes are represented by signals and events by event streams. Thus they seems to have feature parity with RXJS as they can model all sorts of async stuff. Best part is they get to keep writing their markup in C-style syntax than XML based JSX. It looks super elegant,minimalist and has type safety.

This is very true. I really hate svelte single file components. But then I tried JSX for breaking things down. I love solid but I don't feel really good about angle brackets within C style syntax. I saw this Scala library that stick with simple statically typed function syntax than html tags. I don't understand why people still wants to stick with xml like tags. In laminar markup is written like this scala div( h1("Hello world", color := "red"), inputCaption, input(inputMods, name := "fullName"), div( ">>", button("Submit"), "<<" ) ) I wish solid team makes their HyperScript syntax as performant as JSX.

Laminar (Scala framework) hasn't been mentioned yet so dropping it here as an awesome framework that support HTML-over-the-wire. It can be used together with React, HTMX, and many other frontend frameworks -- but doesn't have to be.

https://laminar.dev/

Scala.js core itself, which I maintain, does not need much innovation. We support all of Scala, and interact with any JavaScript library. That's what the core promises.

If you want to compare to Scala 3, it's worth pointing out that you can use Scala.js with any Scala version >= 2.12.2. In particular, you can use it with Scala 3 and benefit from all its innovations. ;)

Innovation comes mainly from libraries, notably UI libraries. Laminar (https://laminar.dev/) is a great example.

In terms of roadmap, we are mostly working on "boring" stuff: improving performance (of the generated code, and of the linker), fixing bugs when they get reported, etc.

Perhaps, when Wasm gets more features for deeper interoperability with JavaScript (manipulating objects notably), we will take another look at targeting Wasm. People usually expect all languages to target Wasm now, "because it's fast". Truth is, it's fast for languages with linear memory. There is no evidence yet that it will be fast for memory-managed languages with objects and virtual dispatch.