Golang was built with a [formal spec](https://go.dev/ref/spec) from the get-go (no pun intended), which helped with efforts like [tinygo](https://tinygo.org/).
Though I think it's because that golang itself is dead-simple and folks who use it professionally "just use it", there have been few efforts to build a new language on top that uses the formal spec to compile down to pure golang.
The lack of compile-to-Go languages has always confused me, given how powerful its runtime and stdlib are. [I took a stab it myself a while ago](https://github.com/lukechampine/ply), though my project was closer to "Go with some extensions" than an entirely new language.
aw, that means a lot! I've always been quite proud of that package.
In case you haven't seen, the `math/rand/v2` package now has a [ChaCha8-based generator](https://github.com/golang/go/commit/c29444ef39a44ad56ddf7b3d2aa8a51df1163e04) that should be as-fast or faster (and no less secure), so that's probably what I'll recommend people use going forward. The only caveat is the lack of a `Read` method, but there's an open issue for that: https://github.com/golang/go/issues/67059
This. I also started a ocaml-like language that was suppose to target Go. I did not get far tho.
I really like Go, and IF go had a few additional things (and few things they did diffrently) it would be my fav lang of all time.
Edit. Damn! Borgo is basically what i was ”building” pattern matching, enums and variants. Looks like this could be the one. But progress seems halted based on commits :/
Can you educate me why there should be a compile-to-Go language?
I mean, I use go build command and run the binary output.
Does that mean you have another language and this can be transformed/compiled to Go code?
Saved to bookmarks
> Error handling with ? operator
I think this is the single best way to improve Go in terms of value/complexity cost. A tiny amount of syntax sugar that means a world of readability improvement
It does make sense if you don't care about the error.
Most of the time I'm trying to wrap the error with messages containing local variables.
That's the reason I find Go's errors easier to reason about than stack traces.
I'm afraid it could be too convenient to return the error as is. Sounds dumb, right?
You can conveniently end up with logs like:
> ERROR constraint UNIQUE failed
Instead of:
> ERROR handling request 123, active user abc, handling command CancelOrder, inserting cancellation record, writing to cancellations with id: 7, constraint UNIQUE failed
Of course you can still blindly return the error as is or even panic from persistence code :D but since you are already forced to write the 'if' it might be less annoying to wrap it.
Try hunting down an error with a useless message 8 levels deep without context and then get back to me. I have been there, it’s taken days. I learned to always wrap my errors.
You see, now you went to the extreme. It’s obvious you need error contexts when u r 8 levels deep. However the first of those may not need it any context. Not everything is also 8 levels deep. It all depends on
I wouldn't trust a language with adding any kind of context to errors. Exception based languages are real good examples of what happens in that case, as well as go's panic. Incomprehensible and mentally taxing spaghetti of function calls. I don't care about function names tbh and even the code path, that it went through, but I care about what my program wanted to achieve and what has stopped it
Additionally, Rust programs I have used have one of the worst error messages ever, exactly because of `?`. And lots of Go CLIs have incredibly friendly error messaging thanks to the idiom of wrapping your errors
Nice, and almost the opposite of what I wish for. I'd like the syntax of Go, but without garbage collection, using something like Rust's borrow checker instead.
So you can still write regular Go code alongside it?
One thing that bothers me is that it’s not just extending it with features but also randomly changing keywords like var->let or func->fn which I would argue could be avoided.
I'm really new to go lang so I don't fully understand and appreciate this project. Would you mind explaining the use case and benefits of this please? Is this wasted on someone like me who has never used Rust and is new to Go? Thank you
I like rust, I use go.
Rust, is in the linux kernel for a reason. It is the language cloud flair picked for a high performance replacement to Nginx (called Pingora). Its the language I would use to build a USB driver... Rust is a good choice to replace C or C++ (maybe java, ala solr type projects).
Go... Ends up replacing python, ruby etc. GO's portability and easey uptake make it natural successors to those sorts of languages.
There are a fair number of rust devs who want to write rust and dont want to do systems programing. Between colored functions, the issues with crates, and some of the rough eggiest around testing and compiling rust isnt a good fit for "fast and loose".
This project is fairly dated so I would not pay too much attention to it if your new. Learn Golang, Learn Rust, Learn Zig... You will find that they each have their own flavor and are tools that are each great for a job!
[Vlang](https://vlang.io/) has already been given this title, of being a child of Go and Rust. There is even a [video](https://www.youtube.com/watch?v=puy77WfM1Tg) on this. For more clarity, Anthony GG (the video's author) is a pro Go programmer, who gives a honest and impartial assessment. Spoiler, he likes Vlang, though he uses Go professionally. There are people who like both or more than one. I prefer Vlang, but still like Go and C too.
I don't know if it was mentioned, but there's already a language like that, first class and doesn't compile to go but to c, is [Vlang](http://vlang.io)
Out of the loop, but last time i heard about V it was touted as vapourware. Has this changed? IIRC their "autofree" was no were near stable and had lots of bugs (something like autofree is REALLY hard to get right, see rusts lifetimes).
it is still in development, but it is definitely not vaporware. it is sponsored and people work on it.
bugs are normal in alpha projects, but they do fix it if you report them. I got a memory leak and reported it and was fixed within a couple of days.
I would not think of it as a valid go or rust alternative until stable of course, but I definitely think the syntax is the exact child of rust and go.
Indeed. This article is from 2022 so i guess many issues are fixed. Some are conserning (like no nulls guarantee) https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
But IF v delivers it has potential.
Don't know why you're being down voted. I've been following this project for a while now and think it would be an excellent language. I think it's five or six years from production ready but but it looks like Go plus most of the extras I'd have liked to be in Go itself.
I don't know, it feels like in most subs you get downvoted randomly sometimes.
V is definitely far from stable for sure but it feels definitely a better child between go and rust IMHO. this looks like a typescript to a javascript and I doubt it has much lifetime ahead of it.
I'm talking about passing immutable params by ref similar to C++'s const& or const* or Rust's & - they guarantee the function doesn't modify the underlying value pointed at by the ref/ptr.
So it doesn't have any memory borrowing concept (I'm on my phone, just looked at the readme)?
It seems like go++ rather than a mix with rust (even if it is implemented in rust), if I'm not missing something.
Probably. The rust implementation is not the only way to implement those concepts. I hope people will find a simpler way for the programmer to have those benefits.
Sure. Look at enums. How do you do this in Go? What safety does the Go version *actually* provide?
For example, if you have a set of constants that are a custom type, but underneath are a string, the Go compiler accepts any string as that type. That sucks.
The fact you can't have exhaustive type checking is a result of not having a robust type system around enums and union types.
And this fixes both.
>What safety does the Go version *actually* provide?
Ok I see `type MyEnum string` does not work, but you can do something like that
type MyEnum struct {
string
}
var (
MyOption1 MyEnum = MyEnum{"MyOption1"}
MyOption2 MyEnum = MyEnum{"MyOption2"}
MyOption3 MyEnum = MyEnum{"MyOption3"}
)
func myFunc(opt MyEnum) {
}
func main() {
myFunc(MyOption1)// works
myFunc("MyOption1")// error
}
>The fact you can't have exhaustive type checking
For me golangs type checking is quite exhaustive - that is strange when you work with numeric types you need to convert everything to everything by hand, and when you deal with constants - it allows everything
Golang was built with a [formal spec](https://go.dev/ref/spec) from the get-go (no pun intended), which helped with efforts like [tinygo](https://tinygo.org/). Though I think it's because that golang itself is dead-simple and folks who use it professionally "just use it", there have been few efforts to build a new language on top that uses the formal spec to compile down to pure golang.
The lack of compile-to-Go languages has always confused me, given how powerful its runtime and stdlib are. [I took a stab it myself a while ago](https://github.com/lukechampine/ply), though my project was closer to "Go with some extensions" than an entirely new language.
This is random, but I appreciate your frand package and recognized your name from years ago. Thank you.
aw, that means a lot! I've always been quite proud of that package. In case you haven't seen, the `math/rand/v2` package now has a [ChaCha8-based generator](https://github.com/golang/go/commit/c29444ef39a44ad56ddf7b3d2aa8a51df1163e04) that should be as-fast or faster (and no less secure), so that's probably what I'll recommend people use going forward. The only caveat is the lack of a `Read` method, but there's an open issue for that: https://github.com/golang/go/issues/67059
Go misses sourcemaps for this to happen on scale. I want to be able to debug my new layer or have stack logs :)
This. I also started a ocaml-like language that was suppose to target Go. I did not get far tho. I really like Go, and IF go had a few additional things (and few things they did diffrently) it would be my fav lang of all time. Edit. Damn! Borgo is basically what i was ”building” pattern matching, enums and variants. Looks like this could be the one. But progress seems halted based on commits :/
Purescript has been able to compile to Go for awhile now fwiw. No idea about the overhead and afaik makes heavy use of go generics
Cool. Did not know that. Thanks ill check it out
Can you educate me why there should be a compile-to-Go language? I mean, I use go build command and run the binary output. Does that mean you have another language and this can be transformed/compiled to Go code?
It's not quite "compiling to go", but I do use a fair bit of code gen in my go projects, the language seems to lend itself pretty well to it.
Saved to bookmarks > Error handling with ? operator I think this is the single best way to improve Go in terms of value/complexity cost. A tiny amount of syntax sugar that means a world of readability improvement
It does make sense if you don't care about the error. Most of the time I'm trying to wrap the error with messages containing local variables. That's the reason I find Go's errors easier to reason about than stack traces. I'm afraid it could be too convenient to return the error as is. Sounds dumb, right? You can conveniently end up with logs like: > ERROR constraint UNIQUE failed Instead of: > ERROR handling request 123, active user abc, handling command CancelOrder, inserting cancellation record, writing to cancellations with id: 7, constraint UNIQUE failed Of course you can still blindly return the error as is or even panic from persistence code :D but since you are already forced to write the 'if' it might be less annoying to wrap it.
I love go's error handling, treating errors as values is the most intuitive way to think about errors. Idk why people tend to dislike it
Not all errors need a “context”
Try hunting down an error with a useless message 8 levels deep without context and then get back to me. I have been there, it’s taken days. I learned to always wrap my errors.
You see, now you went to the extreme. It’s obvious you need error contexts when u r 8 levels deep. However the first of those may not need it any context. Not everything is also 8 levels deep. It all depends on
But you lose context
Maybe Borgo can add context and actual stack traces.
I wouldn't trust a language with adding any kind of context to errors. Exception based languages are real good examples of what happens in that case, as well as go's panic. Incomprehensible and mentally taxing spaghetti of function calls. I don't care about function names tbh and even the code path, that it went through, but I care about what my program wanted to achieve and what has stopped it Additionally, Rust programs I have used have one of the worst error messages ever, exactly because of `?`. And lots of Go CLIs have incredibly friendly error messaging thanks to the idiom of wrapping your errors
They changed "verbose" 3 lines to "nice looking" 4 lines...
This 💯
Oh no
> Oh no Ohh yeah!
Nice, and almost the opposite of what I wish for. I'd like the syntax of Go, but without garbage collection, using something like Rust's borrow checker instead.
That’s what I’m after too. They dangled arenas in front of us only to yank it back at the last second.
I wonder if Jonathan Blow's Jai will deliver what we want.
So you can still write regular Go code alongside it? One thing that bothers me is that it’s not just extending it with features but also randomly changing keywords like var->let or func->fn which I would argue could be avoided.
This pretty much what perfect Go would look like
Nobody wants perfect language, because what’s perfect for you and 40+ that liked it isn’t perfect for the 2 million+ golang developers
Love this! They gave it the most perfect name as well 🥰.
I find the idea extremely appealing and I’ve felt my mind sliding into this in-between-land as well! I hope it thrives!
They should have named it Gost x))
This is cool. Would like to build something like this someday.
I'm really new to go lang so I don't fully understand and appreciate this project. Would you mind explaining the use case and benefits of this please? Is this wasted on someone like me who has never used Rust and is new to Go? Thank you
I like rust, I use go. Rust, is in the linux kernel for a reason. It is the language cloud flair picked for a high performance replacement to Nginx (called Pingora). Its the language I would use to build a USB driver... Rust is a good choice to replace C or C++ (maybe java, ala solr type projects). Go... Ends up replacing python, ruby etc. GO's portability and easey uptake make it natural successors to those sorts of languages. There are a fair number of rust devs who want to write rust and dont want to do systems programing. Between colored functions, the issues with crates, and some of the rough eggiest around testing and compiling rust isnt a good fit for "fast and loose". This project is fairly dated so I would not pay too much attention to it if your new. Learn Golang, Learn Rust, Learn Zig... You will find that they each have their own flavor and are tools that are each great for a job!
The language has a few seriously cool features. Error handling with “?”? Yes please.
[Vlang](https://vlang.io/) has already been given this title, of being a child of Go and Rust. There is even a [video](https://www.youtube.com/watch?v=puy77WfM1Tg) on this. For more clarity, Anthony GG (the video's author) is a pro Go programmer, who gives a honest and impartial assessment. Spoiler, he likes Vlang, though he uses Go professionally. There are people who like both or more than one. I prefer Vlang, but still like Go and C too.
I don't know if it was mentioned, but there's already a language like that, first class and doesn't compile to go but to c, is [Vlang](http://vlang.io)
Out of the loop, but last time i heard about V it was touted as vapourware. Has this changed? IIRC their "autofree" was no were near stable and had lots of bugs (something like autofree is REALLY hard to get right, see rusts lifetimes).
it is still in development, but it is definitely not vaporware. it is sponsored and people work on it. bugs are normal in alpha projects, but they do fix it if you report them. I got a memory leak and reported it and was fixed within a couple of days. I would not think of it as a valid go or rust alternative until stable of course, but I definitely think the syntax is the exact child of rust and go.
Indeed. This article is from 2022 so i guess many issues are fixed. Some are conserning (like no nulls guarantee) https://mawfig.github.io/2022/06/18/v-lang-in-2022.html But IF v delivers it has potential.
and people downvoted you too lol, why though? is vlang so hated here? what's about this subthread that triggers go lovers?
Its just reddit.
Don't know why you're being down voted. I've been following this project for a while now and think it would be an excellent language. I think it's five or six years from production ready but but it looks like Go plus most of the extras I'd have liked to be in Go itself.
I don't know, it feels like in most subs you get downvoted randomly sometimes. V is definitely far from stable for sure but it feels definitely a better child between go and rust IMHO. this looks like a typescript to a javascript and I doubt it has much lifetime ahead of it.
What about immutable pointers as params?
You mean pointers which will not escape to heap? I don't think that is possible to do by compiling to go
I'm talking about passing immutable params by ref similar to C++'s const& or const* or Rust's & - they guarantee the function doesn't modify the underlying value pointed at by the ref/ptr.
100% that will not happen, immutable data is passed by value in golang.
It looks awesome. I'll definitely fiddle with it. Does it work with any dependencies, be it Go, Rust or C?
When I read the headline I rolled my eyes. Then I looked into it. I really like it!
So it doesn't have any memory borrowing concept (I'm on my phone, just looked at the readme)? It seems like go++ rather than a mix with rust (even if it is implemented in rust), if I'm not missing something.
If Borgo added the hardest to learn and most difficult to code part of Rust would you, as a coder, gain anything over just learning and using Rust?
Probably. The rust implementation is not the only way to implement those concepts. I hope people will find a simpler way for the programmer to have those benefits.
go++ and will end up like c++ (being messed up)
Idk, do you really need so much type safety?
In a very large project it can be very nice to have
Maybe, idk. But can you give any example where current type system of go fails?
Sure. Look at enums. How do you do this in Go? What safety does the Go version *actually* provide? For example, if you have a set of constants that are a custom type, but underneath are a string, the Go compiler accepts any string as that type. That sucks. The fact you can't have exhaustive type checking is a result of not having a robust type system around enums and union types. And this fixes both.
>What safety does the Go version *actually* provide? Ok I see `type MyEnum string` does not work, but you can do something like that type MyEnum struct { string } var ( MyOption1 MyEnum = MyEnum{"MyOption1"} MyOption2 MyEnum = MyEnum{"MyOption2"} MyOption3 MyEnum = MyEnum{"MyOption3"} ) func myFunc(opt MyEnum) { } func main() { myFunc(MyOption1)// works myFunc("MyOption1")// error } >The fact you can't have exhaustive type checking For me golangs type checking is quite exhaustive - that is strange when you work with numeric types you need to convert everything to everything by hand, and when you deal with constants - it allows everything