Re:From Markdown to remote code execution in Atom
by xfer on Thursday November 23, 2017 @05:27PM
(#15768228)
Adding Reason(which is Ocaml with bucklescript backend) and Purescript to the list.
Re:From Markdown to remote code execution in Atom
by codefined on Thursday November 23, 2017 @05:43PM
(#15768307)
Adding this[0] list of languages that compile to JavaScript to the list. There seem so many that no matter your taste in syntactical sugar there should be something for you.
[0] https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
Re:From Markdown to remote code execution in Atom
by xfer on Thursday November 23, 2017 @05:59PM
(#15768388)
Would like to clarify that it's not about "syntactical sugar" more like different semantics and/or safety(they treat js as machine code), hardly anyone would claim they are using these languages because of js syntax.
Re:From Markdown to remote code execution in Atom
by zghst on Thursday November 23, 2017 @07:05PM
(#15768682)
f# is the future
Re:From Markdown to remote code execution in Atom
by bonesss on Friday November 24, 2017 @04:15AM
(#15770232)
As clearly evidenced by how hard MS has been working to bring C# up to par these last few years :)
Naturally there are limits to how well you can retrofit something into a language compared to having that feature there from the start...
* clojurescript
* f# via fable
* c# via different means(even an MSIL compiler)
* Golang
* etc
I mean, clojurescript and F# are bomber if you want functional. Typescript may give the best interop with existing packages, but I've read good things about F#'s .d.ts file support for creating type providers. In any case, if the lang you pick creates a bit of extra work that's probably small beans compared to the work required to get all of what parent described with completely separate languages and platforms.