Newbie here. I'm following Til for a few weeks now and like the syntax and its simplicity. There is actually a somewhat similar actively developed attempt to create a simple Tcl/Rebol/Red/...-like language called Arturo but I must admit I like the syntax of Til more. Though Arturo is undoubtedly a very good source of inspiration regarding APIs, concepts, etc.

Of course, regarding functionality Til is extremely limited, but let me ask some other questions which IMHO determine the future direction of the language.

1. What are the expectations of maximum possible performance? In other words, will the language provide means to compile/transpile its static parts into highly efficient C/D/platform_specific_binary code or not (e.g. Red is a language with such a hybrid static-dynamic compilation approach)?

2. What are the expectations of the "safety degree" (defensive programming without any runtime performance cost - i.e. compile-time checking of correctness - e.g. using explicit compile-time types, immutable variables by default, no exceptions but effects on steroids or optionals_with_one_character_propagation instead unlike Go, contracts/protocols, static assertions, static code flow analysis, etc.)?

   And if you're wondering how to unobtrusively include "types" or alike, Phix has quite an interesting approach (though that's just half of the problem - the other half is compile-time checking of relations among types themself - i.e. which combinations of types at which point of the variable life are allowed - this is usually done with static asserts, but there might be other options...).

3. Actually related to (2) but still separate. What are the expectations of metaprogramming capabilities? I mean, rather no unconstrained eval (I can imagine "safer" eval variants - will elaborate if anyone asks), but maybe something like compile-time macro-like eval (but with hygienic variables etc.). For the language itself this is an enormous advantage as this guarantees long-term sustainability if used in the form of from future import feature5 ala Python while satisfying special needs of companies as well as freaks like me 😉 who need to have some specialties not suitable for upstream.

4. Is Til already used for some non-toy projects (preferably by some medium or bigger company)? Or are there at least any serious plans to do so?

5. Any true concurrency support (leveraging more CPU cores)? Don't be afraid of this - no need to introduce any new syntax nor any special primitives. After 10+ years of participating in designing concurrency APIs for languages like Nim, V, Red, etc. I've come to conclusion that CSP/async-await API shall be modeled identically as APIs for os-level threads/processes (usually fork-join with lock/unlock, but nowadays preferably nursery pattern with transactional memory).

6. If Til gets compile-time support (i.e. pre-run phase to accomplish e.g. (2)), do you plan to add "upfront" FFI support (i.e. compile time FFI with manually defined function signatures & manually defined struct signatures and their offsets etc. in dynlibs for maximum performance)?

Btw. let me say one more thing. Prudence says that the you're not supposed to write complex code in Til never happens. A language either died quickly (in which case it doesn't matter) or became popular/used_in_practice in which case it is being used for writing complex code.

Probably the most horrifying widely known example is Python which after many years culminated with saying "we can't develop Python 1.x 2.x any more and need to do major changes here and there in Python 3.x" which was extremely painful.

And only because they deliberately tried to pursue you're not supposed to write complex code in Python for too long instead of trying to watch out for mistakes soon after their creation. Btw. there is soon-to-be-accepted PEP about macro support in Python - I myself was really surprised by that, but this further underlines the fact I stated above - a language will either die soon or become full-featured for real life complex programming.

Generally it's better to accept this fact and rather outline how to tackle it generally (not necessarily a very concrete plan like Java has for the next 20 years but also not overlooking this problem for too long).