[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

[flakes]

Ah very nice! Did not realize this was a part of the standard library!

[lmz]

It's been there since Python v2.1 https://docs.python.org/release/2.1/lib/module-doctest.html

[sakesun]

Here is the first announce of doctest I can find (1999) I think it's Python 1.5 time.

https://groups.google.com/g/comp.lang.python/c/DfzH5Nrt05E/m...

[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

[mdaniel]

Please no

  let { (*>), (<*), wrap } = import! std.applicative

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

[echelon]

Not necessarily!

These are the strong vs weak, static vs dynamic axes.

You probably want strong, but dynamic typing. eg., a function explicitly accepts only a string and won't accept or convert a float into a string implicitly or magically.

You're free to bind or rebind variables to anything at any time, but using them in the wrong way leads to type errors.

JavaScript has weak dynamic typing.

Python has strong dynamic typing (though since types aren't annotated in function definitions, you don't always see it until a type is used in the wrong way at the leaves of the AST / call tree).

Ruby has strong dynamic typing, but Rails uses method_missing and monkey patching to make it weaker though lots of implicit type coercions.

C and C++ have weak static typing. You frequently deal with unstructured memory and pointers, casting, and implicit coercions.

Java and Rust have strong static typing.

[tadfisher]

If the language has types at all, they're exposed to the user, even if the time of exposure is a runtime failure. I suspect you want inferred types, which can be had in statically-typed languages.

[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!