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…
What was the other one? I'm working on a language that transpiles to Zig with a custom Go-like runtime (and no garbage collector, Rust-style Affine movement instead). Sky seems quite cool, as it's additive to Go in interesting ways. I originally considered keeping the GC and just transpiling to Go so I didn't need to write a Runtime. Go rules! It really does. But I HATE writing/reading Go. So I'm glad more people are…
Sky – an Elm-inspired language that compiles to Go
61–70 of 99 posts
Re: Sky – an Elm-inspired language that compiles to Go
#62That'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. Unfortunately nothing below source code level is stable, so they would constantly be chasing changes after any Go release. I personally wish they would focus on making it accessible, as Go actually has a nice runtime and would make a good language target.
Aha! That would explain things. I was wondering if the Go assembly at least is stable and documented, couldn't really find anything
Re: Sky – an Elm-inspired language that compiles to Go
#63That'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…
Go is simple. People like complexity. So the write abstractions to feel better about themselves.
Re: Sky – an Elm-inspired language that compiles to Go
#64I 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.
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 you into a propietary-ish ecosystem.
Re: Sky – an Elm-inspired language that compiles to Go
#65That'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…
I like Go as well, but I wish the Go team were slightly less conservative about language changes. Only asking for 10-15% less conservatism. It is OK to add one proper new language feature and one good standard library package per year. Or deprecating one language feature and one stdlib package every 2 years.
Re: Sky – an Elm-inspired language that compiles to Go
#66That'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…
Go is simple. People like complexity. So the write abstractions to feel better about themselves.
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 the fact that zero values are in 90% of all cases not what the dev intended. Sure, the mantra goes "make them useful" but thats hard. How to you know if a value (int) was zero initialised, or if the user did in fact input zero as value. No matter, you will need to validate every one of these "zero values" if you want some sort of robustness.
Re: Sky – an Elm-inspired language that compiles to Go
#67Earlier quoted context omitted.
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.)
ocaml has a complex type system but it's also very pragmatic in that it doesn't force you into any one paradigm, you can do whatever works best in a given situation. (scala arguably goes further in the "do whatever you want" direction but it also dials the complexity way up)
Ocaml's typesystem is rich, but not as complex as TypeScripts. It seems TS just adds more obscure features every year for little benefit.
Re: Sky – an Elm-inspired language that compiles to Go
#68Earlier quoted context omitted.
> Go rules! It really does. But I HATE writing/reading Go. Same. I love the Go toolkits, the compile story, the speed at which it compiles, its backwards compatibility, the fact that stale Go code 10 years old still compile and run, etc., just don't care much for the language itself. I wonder if the positive attributes of Go aren't compatible with clever types and other developer-friendly features?
It’s mostly that Go was already pioneering how to build a programming language that had an amazing scheduler, garbage collector, compiler, package manager, formatter, etc. They spent all of their “innovation budget” on the most important—and most neglected—features of any programming language and allowed the language itself to be pretty boring. Eventually Go’s runtime and tooling will be bog standard and everyone wil…
AI needs strong types just as much as human developers.
Strong types also improve the interaction between humans and AI: shitty code is way more obvious with strong types. Pure strong-type langs like Elm take this to an even higher level: all cases must handled, such that runtime errors are practically impossible to express.
I've worked professionally on a large Elm program that has had 5 devs on it, and the promise held out: no runtime error, ever. Other stories for this exist.
Re: Sky – an Elm-inspired language that compiles to Go
#69Earlier quoted context omitted.
Go is simple. People like complexity. So the write abstractions to feel better about themselves.
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).
Re: Sky – an Elm-inspired language that compiles to Go
#70That'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…
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.
I dont get your reasoning.