Update Coding environment

Coding-environment.md

@@ -21,18 +21,22 @@ Non-negotiable items:
 Other items
  (should be fleshed out, but things like easy lists and dicts, nice comprehension expressions for them, what else?)
 
+## Language lists/data
+
+The [Stack Overflow survey](https://survey.stackoverflow.co/2024/technology#admired-and-desired) is potentially relevant/useful. I've annotated the language list below with the SO used/want-to-use score for each language we mention. Tellingly, the highest ranked significant-indentation statically typed language is Scala,  followed by F#, and then Nim. So we seem to have found the main options. This suggests two things (1) Since both Nim and F# seemed to have issues for us, perhaps we should also give Scala a closer look; and (2) so maybe then that means we will have to go the syntax crufter/decrufter route, in which case why not go with Rust that has the highest "want-to-use" score (and has for 9 years running!) and sixth highest "use" score.
+ 
 
 Next let's try to collect various language options, with their pros and cons:
 
-### Civet
+### Civet (SO Unranked, unsurprisingly)
   + 👍 Nicest syntax I've ever used
   - ❌ Tied to the dreadful TypeScript type system (probably disqualifying)
 
-### Julia
+### Julia (SO 2.1/61.7)
   + 👍 has been very useful for prototyping
   - ❌ Littered with "end" keywords, not clear any current good path for building for in browser use
 
-### Nim
+### Nim (SO 0.9/50.5)
   + 👍 Nice rational syntax with lots of features
   + 👍 Compiles to JavaScript or WASM (via either C/C++ > emscripten or a third-party LLVM backend)
   - ⇓ The user community is very small, and even the most basic tools and libraries seem sporadically maintained. *(Aaron)*
@@ -55,24 +59,27 @@ is better than
       otherLongThing
 ```
 The gist of the most significant argument for the upper version is that one reads the beginnings of lines more easily (they are aligned, after all), and looking there it's easy to see how the parts of the long expressions are connected, and hence code written in the upper style is easier to understand. Perhaps Nim is still new/flexible enough that we could contribute a PR to _also_ make the split+indent  just before a binary operator legal as well, backwards-compatibly still allowing a split+indent after a binary operator? I think if we go with Nim I would like to try to do that. But we can wait until after we make the decision as to which language to start the "full implementation" in.
+  - Aaron reports the state of linear algebra packages is not good, and one has broken based on language/compiler changes, which is all kind of scary -- we might have to do a significant amount of maintenance ourselves. This is the curse of that 0.9 "use" rating on SO.
 
-### Lobster
+### Lobster (SO unranked)
   * (Is this worth a more careful comparison with Nim, or is it just too small/fringe?)
   * ❌ Aaron consulted with the Lobster community who says that intercommunication with JavaScript is cumbersome
 
-### Scala, now with significant indentation
+### Scala, now with significant indentation (SO 3/50.9)
   * (I think targeting the JVM invalidates this? Or is there now a decent build process to WASM? Is Scala sufficiently more active/bigger community/more mainstream than Nim to make it worth looking into this more?)
+  - Actually, there is Scala.js that compiles to JavaScript, that seems quite mature. There does not currently seem to be a way to compile to WASM, but it appears to be pretty close as an optional backend in Scala.js (see https://github.com/scala-js/scala-js/issues/4928). One can use existing JavaScript frameworks via Scala.js -> JavaScript; there also exist Scala frameworks/servers like [Xitrum](https://xitrum-framework.github.io/) but not sure what that does as far as client-side computation.  So it seems as though trying to go with Scala would at least at first mean sticking within JavaScript per se, so there is a potential trap if in fact WASM ends up being needed for performance reasons (assuming that a language well-compiled to WASM will be faster than basically equivalent JavaScript). On the other hand, the ongoing work for the WASM backend could provide a way out of that trap, although some commenters online say that the WASM backend will not likely be any faster than the pure-JavaScript backend because it will not be able to get close enough to the underlying WASM architecture to take advantage of its possible speedups. So there is some risk here; not sure how to evaluate whether it's worth looking deeper?
+  - Nevertheless, being the statically-typed significant-indentation language with the highest SO score is suggestive that we should put a bit of effort into seeing what using it would be like.
 
-### C++ with our own civet-like syntax unmangler
+### C++ with our own civet-like syntax unmangler (SO 18.3/53.1)
    -  ⇓⇓ Big con: we would have to implement this!
 
-### F#
+### F# (SO 2.2/53.1)
    - Deeply tied to the .NET ecosystem.
   - ⇓ The basic template for a Bolero application seems *very* heavy. It's not clear how to write a bare-bones application.
   - ⇓ Projects are auto-generated and opaquely structured.
   - [Glen:] These things do seem icky.
 
-### Ruby
+### Ruby (SO 4.7/50.1)
   - Well-established, with a large user community.
   - Can transpile to JavaScript using [Opal](https://github.com/opal/opal#readme).
   - May someday support WebAssembly as a build target using [Artichoke](https://www.artichokeruby.org/).
@@ -82,10 +89,10 @@ The gist of the most significant argument for the upper version is that one read
   - ❌ I don't think dynamic typing is right for dyna3
   - Has a linear algebra library written in C/C++: [NMatrix](http://sciruby.com/nmatrix/).
 
-### Ada
+### Ada (SO 1.1/40.2)
   - Well-established.
 
-### Rust with our own civet-like syntax unmangler
+### Rust with our own civet-like syntax unmangler (SO 28.7/82.2)
   - ⇓⇓ Big con: we would have to implement this! (but it is probably less work than for C++ since the syntax is much simpler/cleaner; i.e., we could probably actually base it on a proper parser, like civet does, rather than by local string transforms, which is the only way I could think of to do unmangled C++)
   - If we decide to bite the bullet and implement our own unmangling, is Rust enough better than the far more mature C++ with vast legions of existing packages to make it worth doing this for Rust rather than C++?
   - There's at least one linear algebra library—[nalgebra](https://www.nalgebra.org/)—that's explicitly designed to support WASM builds.