zlacker

>>todsac+(OP)
I was really excited about the idea of a modern statically typed language with green threads ala Erlang / BEAM. I lost interest when Rust moved away from that direction and became focused on zero-cost abstractions instead.

>>pton_x+xKm
It certainly was a big shift, a lot of people both had your opinion and had the opposite, for sure.

Do you think Go fulfills that for you today or do you think there's still space for a new language here?

>>stevek+rLm
Not parent, but I think there is certainly space for a Typescript-esque language for Go. If the parent commenter was looking for a static type system, the implication is they would probably want a more functional language inspired type theory. Go’s runtime is not the BEAM, but it is usable for many of the tasks Erlang is pitched for.

I can readily see a Haskell inspired System F derivative the compiles down to valid Go, or a more flexible, special cases type theory that encompasses all of Go like Ts->Js. Likely a ‘transpiler’, I hate that term, to Go implemented in Go and you have a self-contained language with more advanced type features and Go’s green thread runtime.

>>throwa+ven
https://github.com/MadAppGang/dingo

This project proports to be typescript for golang

>>NortyS+Psn
I applaud the work that’s been done on Dingo (I also really like the name and inspiration, i.e. Dingo is a language that broke free from Google’s control). However, I don’t think Dingo is Typescript for Go, because it is too limited in scope.

Dingo adds Sum types and associated pattern matching elimination thereof, it adds a ‘?’ syntax for propagation of Optional types, and exhaustiveness checking for those pattern matching statements. There is no type system expansion, or syntax alterations that would make the Typescript comparison more appropriate.

I think Dingo probably addresses a lot of the common complaints with Go, but it is not nearly as far from Go as a baseline as I would assume a language positioned between Go and Rust.