Live data from Hacker News

Sky – an Elm-inspired language that compiles to Go

github.com

71–80 of 99 posts

Re: Sky – an Elm-inspired language that compiles to Go

#71

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 LL…

LLVM and JVM have stable interfaces. Go has an intermediate representation but it isn’t stable. Anyone who wanted to depend on it would be on the hook when the implementation changes.

From what the community says, it's pretty stable (as in BW compatible).

Re: Sky – an Elm-inspired language that compiles to Go

#72
post #64

I think you have an interesting spot in the design space here... Have you seen Lamdera? They have a way to use Elm on the server-side that is supposedly acceptable to the Elm-BDFL Evan Czaplicki. https://lamdera.com/ This talk explains it well: https://www.youtube.com/watch?v=4T6nZffnfzg Sky does all on the server (more popular lately with HTMX and LiveView), where Elm+Lamdera is basically 2 project and Lamdera ties…

Giving even a modicum of care of what Evan has to say in 2026 is a good joke. Only thing he's known outside the Elm community (aside from Elm) is how to antagonize your own community.

Re: Sky – an Elm-inspired language that compiles to Go

#73
post #31

Nice to see another language with Haskell / Miranda type syntax, but the vibe-coded implementation sure shows: e.g. src/Compiler/Infer.sky isUpperStart: isUpperStart : String -> Bool isUpperStart name = case String.slice 0 1 name of "A" -> True "B" -> True "C" -> True ... for 23 more cases. And the corresponding go code in the bootstrap compiler is even worse.

Does this language use ASCII or Unicode strings? I think this implementation is technically correct for the strict subset of ascii characters, but as soon as you add more, it stops working. EG I'm pretty sure Á or Ó are capitals, and are included in Windows-1252 which is apparently extremely common in non-unicode strings, and there are a huge amount of unicode characters that are uppercase, in which case this function isn't even slightly correct

Re: Sky – an Elm-inspired language that compiles to Go

#74
post #52
post #33

Earlier quoted context omitted.

That does not address the use case where I find tail recursion most tempting. That would be mutually recursive functions. If the function can be written as an idiomatic loop I probably would do so in the first place.

You _can_ do trampolines, but that is kind of infectious, or needs to be very explicit with extra code, etc.

Indeed. It's not very efficient though. If I remember correctly Scala does this.

Re: Sky – an Elm-inspired language that compiles to Go

#75
Keeps saying "no websocket required" like it's a good thing. The JS client (https://github.com/anzellai/sky/blob/main/docs/design/sky-li...) seems to rely on long polling.

Phoenix LiveView (the inspiration) defaults to using WebSockets because it's much more efficent, but falls back to Long polling if not available.

Re: Sky – an Elm-inspired language that compiles to Go

#76
post #69

Earlier quoted context omitted.

Complexity does not equal language features. Sometimes simple is good, but sometimes simple just simply means more bugs in your code. As a prime example, Go unwillingness to add even the most simple enum kind of type. Having enums (ADTs) with exhaustive pattern matching is NOT complex in any sense or form. It just takes away so, so many bugs you would normally see in production code. One other low hanging fruit is th…

Adding `null` to C was very simple to add. It added a lot of complexity that the language designer did not see coming (hence the billion dollar mistake he made on that).

`NULL` was originally added to ALGOL back in 1965. C was not even a thing back then. It was obviously a bad choice to port NULL to C, one that ADTs would have perfectly modeled, without the billion dollar cost.

In fact C was built sometime around the early 70s, and at the same time the first MLs where also being developed. One added null, while the other added a better mechanism for "nothingness".

Bottom line is you cant compare "adding null" and adding a feature that is over 50 years old, one that is battle-tested thru generations, and still holds up.

Solid maths does no suffer bitrot.

Re: Sky – an Elm-inspired language that compiles to Go

#77

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 LL…

> But I keep wondering if they could integrate at a lower-level than the source code.

For my version (aptly named "Goto" [1]), I forked the go compiler with the intent of keeping it up to date. All changes I made only apply to .goto files, .go files compile exactly as is and are interoperable both ways with goto.

I paused the project due to hitting type-checking bugs when trying to add non-nillable pointers. Everything before was just desugared directly when converting to AST, but for those I needed to touch the typechecker which was too time-consuming for a hobby project back then (pre-coding agents). I might give it another go sometime as I did like the full interoperability aspect.

[1] https://github.com/goto-lang/goto

Re: Sky – an Elm-inspired language that compiles to Go

#78
post #69

Earlier quoted context omitted.

Adding `null` to C was very simple to add. It added a lot of complexity that the language designer did not see coming (hence the billion dollar mistake he made on that).

`NULL` was originally added to ALGOL back in 1965. C was not even a thing back then. It was obviously a bad choice to port NULL to C, one that ADTs would have perfectly modeled, without the billion dollar cost. In fact C was built sometime around the early 70s, and at the same time the first MLs where also being developed. One added null, while the other added a better mechanism for "nothingness". Bottom line is you…

ALGOL indeed. I stand corrected.

https://www.infoq.com/presentations/Null-References-The-Bill...

Re: Sky – an Elm-inspired language that compiles to Go

#80
This is awesome! I love Haskell's syntax, but its adoption isn't where I'd like it to be.

One thing that I don't see is a way to mitigate the "andThen" pyramid of doom.

This happens when you have a language without early returns and you have chain multiple Result returning operations. You can use nested case expressions:

  case operation1 x of
      Ok value -> case operation2 value of
        Ok value2 -> value2
        Err msg -> "error from operation2: " ++ msg
      Err msg -> "error from operation1: " ++ msg

Or nested `andThen` calls

  operation1 x
     >> mapError (\msg -> "error from operation1: " ++ msg) 
     >> `andThen` (\value -> operation2 value)
     >> mapError (\msg -> "error from operation2: ++ msg)
This is nicer to read, but still a lot of noise.

Haskell has `do` notation to alleviate this but that brings with it the type-class that shall not be named.

Some languages, like Rust, introduce different per-type syntactical solutions such as `async/await` for Promises and `?` for Result.

I particularly like Gleam's `use` notation, which is syntactical sugar around functions that take a callback as their final argument.

Do you have a solution for this in Sky?

Post reply on HN