[ecky-l]

"I think if someone can rewrite tcl or a tcl like language, as the top level language, using a more modern low level language, like Rust or Go ... it will be a very nice combo, I think Tcl can serve as a really nice declarative language"

Why would someone rewrite Tcl in another language? That is just an immense amount of work and would (re)introduce bugs that have been found and fixed in Tcl over the last 3 decades.

Just the fact that Tcl is old doesn't mean that it is dead. It is actively developed and used, although mostly hidden (its not that kind of hype around as with Python or Ruby). That Tcl is old does in fact imply that the code base is mature and reliable, its well documented and doesn't come with surprises. Which in turn means that your code is almost never broken with a new Tcl version. In fact, scripts and extensions written for 8.4, 15 yrs ago, are mostly still functional in 8.6 without modifications. Yet Tcl does come with pleasant surprises that don't break old programs, as can be seen with the new features in 8.6 (TclOO, coroutines, tailcall, try/trap ...)

[systems]

well .. i am a big believer in the two layer separation

we program at two layers, high level, and low level

features needed or preferred in low level programming, may not be required in high level programming and vice versa

there are several ways to work like this, and many people do for example, many developers use lua or python with c/c++

the effort needed to make the two language interact vary

another approach is to use one language with optional features, like optional typing or optional garbage collection, a language i believe is adopting this approach is red

have a programming framework, where two languages optimized for the two different layer use each others entities (names, objects, values, interfaces) seamlessly is in my opinion a super good approach for most programming

tcl + c .. are not exactly that and i believe a more modern combo will be better

[ecky-l]

"well .. i am a big believer in the two layer separation"

I believe in this too. Not only two layers, if necessary there can be more.

For that to work, well designed interfaces are quite necessary.

"tcl + c .. are not exactly that and i believe a more modern combo will be better"

You don't necessarily need to reinvent Tcl in another "more modern" language to achieve that. You can compile Rust crates to dynamic libraries (.dll, .so) and use c types, or ffidl in Tcl (http://elf.org/ffidl/) to call the functions in your DLL-crates. Or write a small Tcl C extension to wrap function calls in the Rust code. That will do, without rewriting Tcl in Rust. For the other way around you can always call the Tcl library via its DLL interface in the same manner (which is the way to embed Tcl interpreters in other programs).

[lmm]

I do think we need a richer ABI than C offers (in particular, one with native support for sum types). .net was intended to be that (sort of) but people don't write low - level libraries in it because it ties you to GC.