That's two new languages compiling to Go making HN frontpage in as many days. It seems people like everything about Go except the language itself. Me? I like everything about Go including the language, these transpiled languages are interesting though.
But I keep wondering if they could integrate at a lower-level than the source code. Like how JVM languages integrate at the bytecode level, or LLVM languages at the LLVM level
> But I keep wondering if they could integrate at a lower-level than the source code.
I’m sure they could, but targeting go source code has the benefit of giving early adopters an escape hatch. If it targeted LLVM directly, I would never consider using this at work since the risk of it being abandoned is too high. But since it targets go source, I would perhaps consider it for some low importance projects at work.
Functional languages have some good and some bad features and there's no reason to copy them all. For example, you don't need to have a Hindley-Milner type system (bidirectional is better) or currying just because it's a functional language.
We need more pragmatic languages. E.g. Erlang and Elixir are functional, but eschew all the things FP purists advocate for (complex type systems, purity, currying by default etc.)
at first glance this looks amazing! basically provides everything I have ever wanted in a full stack language. looking forward to experimenting with it.
edit: looking through the docs/examples some more, it looks like javascript interop is fairly clunky, both because it relies on string concatenation to embed fragments of javascript, and because the string concatenation syntax is not great (and the formatter makes it even worse - see the example at https://github.com/anzellai/sky/blob/main/examples/13-skysho...)
I would encourage you to at the least add multiline strings with interpolation support, and ideally add a small compiler for html literals.
Elm's type system and architecture are genuinely pleasant to work with, so seeing those ideas ported to a Go compilation target is interesting. You get the safety and expressiveness of Elm but end up with a Go binary you can deploy anywhere. I wonder how the error messages compare, since that was always one of Elm's strongest features.
That's two new languages compiling to Go making HN frontpage in as many days. It seems people like everything about Go except the language itself. Me? I like everything about Go including the language, these transpiled languages are interesting though.
But I keep wondering if they could integrate at a lower-level than the source code. Like how JVM languages integrate at the bytecode level, or LLVM languages at the LLVM level
> But I keep wondering if they could integrate at a lower-level than the source code.
I’m sure they could, but targeting go source code has the benefit of giving early adopters an escape hatch. If it targeted LLVM directly, I would never consider using this at work since the risk of it being abandoned is too high. But since it targets go source, I would perhaps consider it for some low importance projects at work.
If we think of Go as different kind of C, then having Go as a compiled target seems to make sense as C is a compiled target.
Functional languages have some good and some bad features and there's no reason to copy them all. For example, you don't need to have a Hindley-Milner type system (bidirectional is better) or currying just because it's a functional language.
We need more pragmatic languages. E.g. Erlang and Elixir are functional, but eschew all the things FP purists advocate for (complex type systems, purity, currying by default etc.)
at first glance this looks amazing! basically provides everything I have ever wanted in a full stack language. looking forward to experimenting with it.
edit: looking through the docs/examples some more, it looks like javascript interop is fairly clunky, both because it relies on string concatenation to embed fragments of javascript, and because the string concatenation syntax is not great (and the formatter makes it even worse - see the example at https://github.com/anzellai/sky/blob/main/examples/13-skysho...)
I would encourage you to at the least add multiline strings with interpolation support, and ideally add a small compiler for html literals.
Elm's type system and architecture are genuinely pleasant to work with, so seeing those ideas ported to a Go compilation target is interesting. You get the safety and expressiveness of Elm but end up with a Go binary you can deploy anywhere. I wonder how the error messages compare, since that was always one of Elm's strongest features.
Great work :). Go doesn't have TCO. That means functional languages (no for loops) could blow up the stack. How did you solve that?
You can just compile any tail recursive function to a function with a loop and no recursion.
A bit too bleeding edge for me, but it does look super nice (ie exactly like Elm).
Can’t wait to play with it. Great design!