4 ms·

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 ev

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

MichaelNolan 7mo ago
> 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.
- seabrookmx 7mo ago
  The standard go toolchain doesn't use LLVM. Go has its own assembly format and machine code generation.
ksec 7mo ago
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.
- flossly 7mo ago
  I dont get your reasoning.
onlyrealcuzzo 7mo ago
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 doing this!
- styluss 7mo ago
  https://lisette.run/ https://lisette.run/
  - onlyrealcuzzo 7mo ago
    Awesome, this is very close to what I originally considered.
- osigurdson 7mo ago
  I understand the motivation as I don't really like writing Go code. Interestingly, I don't mind reading it though (as long as the if err != nil isn't too exhausting). A transpilation step though? I'll accept that in Typescript (barely) but not for any other language really.
- gottorf 7mo ago
  > 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?
  - throwaway894345 7mo ago
    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 will think of them as boring and then people will start building more exciting languages on top of them. Assuming AI doesn’t blow everything up.
    - flossly 7mo ago
      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.
nu11ptr 7mo ago
> 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.
- melodyogonna 7mo ago
  Aha! That would explain things. I was wondering if the Go assembly at least is stable and documented, couldn't really find anything
deleted 7mo ago
[deleted]
sbrother 7mo ago
> people like everything about Go except the language itself. Thanks for putting so succinctly exactly how I feel about Go!
throwaway894345 7mo ago
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.
- flossly 7mo ago
  From what the community says, it's pretty stable (as in BW compatible).
gethly 7mo ago
Go is simple. People like complexity. So the write abstractions to feel better about themselves.
- phplovesong 7mo ago
  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.
  - flossly 7mo ago
    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).
    - phplovesong 7mo ago
      `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.
      - flossly 7mo ago
        ALGOL indeed. I stand corrected. https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...
lenkite 7mo ago
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.
anaumann 7mo ago
> 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 https://github.com/goto-lang/goto

MichaelNolan 7mo ago

> 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.

seabrookmx 7mo ago
The standard go toolchain doesn't use LLVM. Go has its own assembly format and machine code generation.

ksec 7mo ago

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.

flossly 7mo ago
I dont get your reasoning.

onlyrealcuzzo 7mo ago

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 doing this!

styluss 7mo ago
https://lisette.run/ https://lisette.run/
- onlyrealcuzzo 7mo ago
  Awesome, this is very close to what I originally considered.
osigurdson 7mo ago
I understand the motivation as I don't really like writing Go code. Interestingly, I don't mind reading it though (as long as the if err != nil isn't too exhausting). A transpilation step though? I'll accept that in Typescript (barely) but not for any other language really.
gottorf 7mo ago
> 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?
- throwaway894345 7mo ago
  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 will think of them as boring and then people will start building more exciting languages on top of them. Assuming AI doesn’t blow everything up.
  - flossly 7mo ago
    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.

nu11ptr 7mo ago

> 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.

melodyogonna 7mo ago
Aha! That would explain things. I was wondering if the Go assembly at least is stable and documented, couldn't really find anything

deleted 7mo ago

[deleted]

sbrother 7mo ago

> people like everything about Go except the language itself. Thanks for putting so succinctly exactly how I feel about Go!

throwaway894345 7mo ago

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.

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

gethly 7mo ago

Go is simple. People like complexity. So the write abstractions to feel better about themselves.

phplovesong 7mo ago
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.
- flossly 7mo ago
  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).
  - phplovesong 7mo ago
    `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.
    - flossly 7mo ago
      ALGOL indeed. I stand corrected. https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...

lenkite 7mo ago

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.

anaumann 7mo ago

> 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 https://github.com/goto-lang/goto