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