[dcreager]

[ty developer here]

We are happy with the attention that ty is starting to receive, but it's important to call out that both ty and pyrefly are still incomplete! (OP mentions this, but it's worth emphasizing again here.)

There are definitely examples cropping up that hit features that are not yet implemented. So when you encounter something where you think what we're doing is daft, please recognize that we might have just not gotten around to that yet. Python is a big language!

[flakes]

Really loving those markdown style tests. I think it's a really fantastic idea that allows the tests to easily act as documentation too.

Can you explain how you came up with this solution? Rust docs code-examples inspired?

[hathawsh]

That concept has been formalized as part of the Python standard library.

https://docs.python.org/3/library/doctest.html

[indiosmo]

Elixir has this.

https://hexdocs.pm/elixir/main/docs-tests-and-with.html

[__mharrison__]

I use this in my books to show the output but also to "test" that the code found in my books actually works.

[_whiteCaps_]

I love doctest as it works so well with a REPL but unfortunately it hasn't really gained traction anywhere I've seen.

[zem]

surfacing revealed types as `@TODO` made me laugh, but thinking about it it's actually a pretty neat touch!

[dcreager]

It really helps in our mdtests, because then we can assert that not-implemented things are currently wrong but for the right reasons!

[echelon]

Totally orthogonal question, but since you're deep in that side of Rust dev -

The subject of a "scripting language for Rust" has come up a few times [1]. A language that fits nicely with the syntax of Rust, can compile right alongside rust, can natively import Rust types, but can compile/run/hot reload quickly.

Do you know of anyone in your network working on that?

And modulus the syntax piece, do you think Python could ever fill that gap?

[1] https://news.ycombinator.com/item?id=44050222

[dcreager]

I don't know that I'd want the scripting language to be compiled, for reasons that are outside the scope of this reply. So removing that constraint, the coolest thing I've seen in this space recently is kyren's Piccolo:

https://kyju.org/blog/piccolo-a-stackless-lua-interpreter/

[mdaniel]

> And modulus the syntax piece, do you think Python could ever fill that gap?

I would never ever want a full fledged programming language to build type checking plugins, and doubly so in cases where one expects the tool to run in a read-write context

I am not saying that Skylark is the solution, but it's sandboxed mental model aligns with what I'd want for such a solution

I get the impression the wasm-adjacent libraries could also help this due to the WASI boundary already limiting what mutations it is allowed

[tadfisher]

There's Gluon, which doesn't share Rust's syntax but does have a Hindley-Milner-based type system and embeds pretty seamlessly in a Rust program.

https://github.com/gluon-lang/gluon

[julienfr112]

Most of the time, you want the type to be dynamic in a scripting langage, as you don't want to expose the types to the user. With this in mind, rhai and rune are pretty good. On the python front, there was also the pyoxidizer thing, put it seems dead.

[davedx]

I am very interested in both of these. Coming from the TypeScript world I'm really interested in the different directions (type inference or not, intersections and type narrowing...). As a Python developer I'm wearily resigned to there being 4+ python type checkers out there, all of which behave differently. How very python...

Following these projects with great interest though. At the end of the day, a good type checker should let us write code faster and more reliably, which I feel isn't yet the case with the current state of the art of type checking for python.

Good luck with the project!