I'm actually working on solving this problem at the moment with https://darklang.com. Our approach is to allow the quick prototyping of python via tooling built-into the editor, within a language that has strong static types (similar to Haskell or OCaml).
As an example, you never change types in Dark, you only make new types and switch over to them, so if you want to test out a type change for just one HTTP route, you can do that.
Dark also doesn't have nulls or exceptions because they're hard to reason about. The usual tools to replace them (Result and Option/Maybe types) require you to handle all the cases when you write code using them. We're allowing you to write code that doesn't handle these cases (again, using editor tooling). Instead it tells you exactly what errors can happen at every point in your code. Once you have your initial prototype/algorithm figured out, you can use that information to handle all the edge cases.
> Instead it tells you exactly what errors can happen at every point in your code. Once you have your initial prototype/algorithm figured out, you can use that information to handle all the edge cases.
While I can't say much about Dark (the available blog posts [1] are shallow), I do think that the automation may be one key aspect of future programming languages. For example, when I'm thinking about gradual typing I don't only want to mix the hodge-podge unitype and actual types but also convert the former to the latter, and a large portion of the process can be automated in various ways (for example, one can track the typical runtime types that unityped variables have; the programmer can solidify compile-time types using that fact).
Instagram had something similar [1] where they extracted mypy types from actual run-time instrumentation. I could see something like that working for typescript and sorbet too.
Yeah, that kind of things! I think it should be a more frequent operation though, available from an editor with one or two keystrokes. I see Dark is heading to that direction; I wish you good luck.
In the longer term, OutOfMemory errors will be handled by automatically rerunning the request with more memory enabled. (Or even longer term, requests will be split and parallelized and checkpointed, etc, automatically). But yeah, if you run out of memory, it will probably simple return a 500.
As an example, you never change types in Dark, you only make new types and switch over to them, so if you want to test out a type change for just one HTTP route, you can do that.
Dark also doesn't have nulls or exceptions because they're hard to reason about. The usual tools to replace them (Result and Option/Maybe types) require you to handle all the cases when you write code using them. We're allowing you to write code that doesn't handle these cases (again, using editor tooling). Instead it tells you exactly what errors can happen at every point in your code. Once you have your initial prototype/algorithm figured out, you can use that information to handle all the edge cases.