F# and C# compile to the same intermediate language, are interpreted on the same runtime, and are produced by the same organization for the same IDE... Their libraries are compatible and they rely on shared access to the common .net ecosystem.
Your absolute worst case scenario would involve decompiling your F# source as C#. More realistically you would use dependency management to gracefully transition out of one of the languages.
Transitioning piecemeal works exceptionally well: it's exactly how I've transitioned numerous projects away from C# onto F# ;)
Ummm Purescript compiles to JS and shares the same runtimes. Both languages have support from popular text editors, and their libraries are compatible and rely on shared access to the common JS ecosystem. In what way is it an apples-to-oranges comparison?
The best ideas are those that you can share between languages. When you get hung up on idioms, or when you recreate idioms that don't matter in another language, that's where the problems are. Exposure to a lot of languages allow a person to figure out that union of computation that benefits all languages.
Like I say when I see python written in a Java style its verbose, and doesn't take advantage of much of the expressive syntax that Python provides over Java. You have given up the speed benefit of Java and have kept code that is nearly as verbose.
And don't get me started on the way people misuse Django.
The "no" was probably aimed at the fact that you were splitting hairs against their use of "sequence".
Optional can generally be thought of as a "sequence" of one or zero values. You could use an array of "[some]" or "[] /* none */" to manage control flow in an almost identical way (you'd just be adopting and managing an API that doesn't statically ensure that these arrays never have more than 1 value).
"map/flatMap" are predictable functions that can be used to manage the transformation of data (which is generally the entire point of code). The type/context that a computation is lifted into communicates a lot: Optional, for example, can be returned for a computation that may or may not return a value, and it can be "mapped" into another value by a pure computation that _always_ returns a value, or "flat-mapped" through a computation that may produce another nullable value. Anyone familiar with these basic functions can jump in, read the code, and generally know that every computation lifted into "map" can't fail, while every computation that is "flat-mapped" can. And in static languages it's all checked by the type system! No testing for "null" everywhere!
I have a hobby project that uses Elm on the front end with Elixir and Phoenix on the back end, and that has been working really well. Elm's event machine like architecture goes well with Phoenix's native support for channels, although the elm library for Phoenix Channels is definitely not production ready.
It has been a very bizarre experience having dynamic typing on the back end and static on the front end, though. Everything feels slightly topsy turvy.
Every single comment here is focused on just one aspect of this article: speed. Far more interesting points the article covers are around _how_ Elm optimizes and _how_ developers optimize Elm code. From the conclusion:
- Optimizing Elm only touches view code, unlike everyone else.
- Optimizing Elm cannot introduce sneaky bugs, unlike everyone else.
- These results should generalize to apps of any size.
Also interesting is how Elm's immutability allows it to use requestAnimationFrame by default, which plain vanilla JS libs can't use by default.
A related anecdote: One of the major reasons I decided to give elm a try was when Richard Feldman was giving a talk about writing Dream Writer in elm, and he got to a point where the performance was noticeably slowing down. He started trying to make it better by 'sprinkling a few `lazy`s through the view code', and then stopped because that had magically made everything super fast again.
What typed languages have you used and what aspects do you find tedious? I find that the experience of writing brittle type-checking logic and tests in dynamic languages is rather tedious in its own right.
I find that even the typing experience is faster with static types, since we get better autocompletion/intellisense and there is no need to lookup documentation or other code all the time.
I'm not sure what you're getting at with "useful," but it looks like it's going to be incredibly fun to play with, and I wish it were available when I was a kid messing around with HyperCard stacks.
I spent an hour trying to implement a 2d Turing Machine.
http://www.puzzlescript.net/play.html?p=6863139
So far, it is unsatisfactory because I do not know how to emulate an infinite playfield, and I cannot figure out how to put a delay between applications of the rules (so you cannot see it running).
That said, with a little tinkering, a Turing machine is possible.
[1]Languages like PureScript provide a much more convenient FFI for this glue, but the glue and escape hatch is still there with Elm.