...And my FoC project has a

It's static, but entirely inferred so I'm not sure it carries the implication that you'd take from it having a "Static Type System"

@Doug Moen and @Jimmy Miller — you're both building projects with a dynamic type system, using a statically typed language. On a cursory consideration, that feels very against-the-grain. Care to share your reasoning?

I have Chris's case too, but also if a type can't be inferred/narrowed statically, it reverts to dynamic

@Ivan Reese I'm building a runtime and virtual machine for a dynamically typed language. That is normally done in a systems language like C, C++, Rust, Zig, so you can have performance. Look at Python, Ruby, Javascript, Perl, etc, that's how it's done. I picked C++ because I'm familiar with it, but also because there are a lot of specialized 3D graphics libraries I'd like to link with that are in C++, and not replicated in other languages. Rust would be my second choice because there are an increasing number of interesting Rust crates for programming GPUs. C++ and Rust are both horrible, complex languages, with slow compilers, that kill your productivity. Any alternative language that I could switch to would be better in some ways, but would lock me into an ecosystem that would make some things I want to do extremely difficult or impossible. What if I want to build a small and performant native app, or a small and performance WebAssembly module, containing my language? Will Haskell or Python or Racket or O'Caml or Pharo get me there? I feel there are no good choices of implementation language. My language is dynamically typed because I prefer dynamic typing, it's easier to implement a dynamically typed language, and it's the best choice for exploratory and live programming. Curv is a language for making art, not for deploying applications on a server, so why do my users need static typing?

Re, your first comment: Ah, that all makes perfect sense. Re, your second comment: I can't tell if this is a recursion joke or a serious suggestion. If it is a serious suggestion, I'd suggest starting a new thread with what you have in mind. I have it on good authority (ie: forthcoming survey results) that there are a lot of folks here looking to collaborate on a project, just waiting for someone to issue the call to arms.

@Ivan Reese Mine is a bit related to Doug’s. But a bit different of a motivation. I am building a very dynamic language. A language that should have a very small core but with the power to implement most of the interesting things in itself. I’ve done a bit of exploration building it in Clojure (my preferred language for many things) but found a few problems. First, the language I was making was being too heavily influenced by what was convenient for me to do in Clojure. I always ended up with a lispy thing just because I could do it quick. I know that if I stick with clojure those things will leak in more than I wanted and so I decided to not use it. Second, and more importantly, I don’t want to spend time right now focused on speed, but I need an interpreter that is decently fast. Since most of the interesting things in my language should be implemented in itself, I will have a huge interpreter overhead. Of course, I could spend the time to optimize that away, but I’m still exploring the idea and optimization isn’t the interesting part. When I was doing things in clojure, my naive solution was already getting to the point where things weren’t interactive at the level I wanted them to be. So for those reasons I chose Rust as my implementation language of choice. I know that in the future when I really care about the speed of everything I can make it fast. And for now, my super naive code is already fast enough for what I’m doing. I haven’t gotten quite to the point where I can really test the interpreter overhead. But I expect things to be fast enough that I can make all the ideas I have in my head in my language itself, keeping the rust I have to write to a very small amount (hopefully 500-1000 lines at most).