What languages / libraries / frameworks would you use to implement your future of coding vision and why?

when webassembly gets support for GC (in the roadmap) I think anything that compiles to webassembly will be a good choince

C. I've tried all the others. C.

Haskell. For me part of the future of coding vision is Live programming, and I believe that an important part of it is distinguishing between pure computation and side-effects. More on that in: Me and @eyal have been discussing the future of coding ever since @jonathoda’s first Subtext demos at 2005. In 2008 @eyal told me about Haskell and how it makes this important distinction that we have decided is crucial. So we use Haskell both because it does things “the right way” and we believe that’s productive but also because familiarity with something similar to what we’re striving to make is very important 🙂

At our company we use F# and the SAFE stack (https://safe-stack.github.io/) as a pretty good compromise (F# is almost an OCaml dialect but runs on the .NET platform and can be crosscompiled to Javascript and there is a nice elm architecture like library to use react that way). So you get ADTs, immutability and non-nullability as defaults (but they are possible because both are used in the wider ecosystem), first class functions etc. It's not as principled as Haskell or Purescript but we feel it has a couple of very nice pragmatic points in it's favour (e.g. the size of the ecosystem, speed at which it can be learned etc)

I'm prototyping my thing in CoffeeScript — I want it to run in the browser, and CS has very minimal tooling, instantaneous build times, and all the stuff from JS I like with less of the stuff I don't. I'm loosely planning to write the 1.0 in ClojureScript — I want it to run in the browser, and CLJS is just such a robust, stable, reliable language. WASM doesn't buy me much because 90% of my perf budget is spent on rendering. I don't current have a WebGL render backend, but will add one at some point — though only if I can do it in a way that doesn't have a high energy cost (because this system runs on phones for long periods of time). No libraries, no frameworks. I've been building highly interactive SPAs on my own JS stack for longer than React & Angular have existed, and I haven't regretted it in the slightest.

Part of my vision is that the "language" that code is written in, is defined by the code itself (e.g. by an interpreter or compiler or UI tool embedded within the very code it is editing or viewing or generating). JavaScript is a great fit for this because it's already heavily centered around the kinds of building blocks that I think are ideal for this. Also, that means my tool can be bootstrapped into any browser from the console. I actually talked about this a bit more in a previous post: https://futureofcoding.slack.com/archives/CCL5VVBAN/p1552529707088600?thread_ts=1552463735.064500&cid=CCL5VVBAN

@Daniel Bachler F# is attractive. What are the main pain points for browser programming?

integrating with existing libraries mainly

@jonathoda we really like F# for frontend development with the elmish library. In Elm it's of course impossible to directly call javascript and you have to send messages through ports and then have JS code listening for events; in f# you can call whatever you like, you just have to create F# type annotations for the js functions. For most of the browser apis this is done for you by the Fable project (Babel AST emmiting backend for the f# compiler), as is it for react and a couple of other common libraries. Writing these yourself is not too hard either. There is also support for untyped access to properties for example, so if you prefer to live fast and dangerously you can 🙂. There are some things that are a bit peculiar but they are mostly around the tooling/packing story. All in all it's a pretty neat full stack functional setup by now.

How’s the debugging experience? Are F# data structures understood?