Exhaustive pattern matching, too! Which I find to be the most valuable aspect in writing resilient code with ADTs, since it ensures you don’t miss any possible states when you add a new tag.
It does look cool. It reminds me in principle of CoffeeScript, which I did enjoy using for a while, and I guess it’s technically not dead though the last release was in 2022. But I would be wary of basing anything serious on this yet!
The “complexity vs type safety” graph on the front page is the realest thing I’ve seen all year, and a great argument for the language’s existence. Serious props to the creator.
Go is compiled as well. The toolchain you need on your dev environment includes Rust and Go in order to build a Borgo program. You get a static binary that do not need any interpreter.
This looks very cool, and might be a reason for me to actually use Go. I used it professionally severally years ago and really did not enjoy the experience, but that was mostly because it lacked a lot of the features that Borgo adds.
That said, the graph on the homepage made me laugh. Why is it linear until we get to Rust, and then exponential? Haskell and Idris are more type-safe (or, at least, have more type-related features) than Rust; is the implication that they’re dozens of times more complex as well? It’s weird.
Nice to see a language website with actual examples easily accessible!
Does anybody think the Rust “?” error propogating operator is too subtle & easily missed though?
To my eyes zigs try expression is a whole lot more readable
I agree. It’s funny, given one of the first languages I got into as a teenager was Perl, yet I really dislike how it is popular to have symbols all over the place. Sometimes I think I went into programming rather than math, because it’s easier to read and write most of of the time. In all honesty one of the things I dislike about Zig is that there are still way too many symbols.
It’s odd to me that on one hand people hope to make it less verbose and on the other hand people suddenly started using colons between type and name. I’ve heard people say “that way you know which side the type is on”, which I don’t really follow. Why does a colon plus space make that clearer than just a space? And things like ?*Foo make me unhappy.
For Go (when considering only the language) I think one of the biggest blunders is how there is a new(type) and &type{}, which is redundant, but in cases where you want to do new(int) for example. But then compared to most other languages, trying to copy whatever is trendy in a given year, ending up with eight ways to do the same thing and as a newcomer having to learn “that’s the old way” it feels like a pretty minor thing. Sadly now there’s also interface{} and any.
Before the ? operator rust used to have a tr!(expr) macro that did the same thing. The observation from moving to the ? macro was that post fix operators work really nicely in conjunction with method chaining.
I don’t think your alone in your concern, but in practice I think people used to rust have found it to be fine, and I think we really don’t want to switch to a prefix operator. If anything there’s a trend of thinking “what else can we make postfix”. expr.try might be an alternative worth considering for a new language.
How practical is it to debug apps written in this language with delve or other Go debuggers? Seems like it would be hard to match what you see in the debugger with the source code you wrote since it’s being “compiled” to Go first.
FWIW compiler output looks readable. Unless you have a lot of logic within long pattern match statements, it should be pretty straightforward to debug and follow the code with standard go toolchain.
I wonder if it will always keep compiling to Go, or if this is going to be to Go what C++ is to C. C++ also initially compiled to C, eventually people wrote standalone C++ compilers.
Rust and LLVM as a requirement, but also Go, so you don’t even get rid of the garbage collector, can’t really do more low level stuff easily. All of that to just bring more complexity to a language that set out to avoid it.
Don’t get me wrong, I find it really cool that people build new languages, yay LLVM, but it feels like lately pretty much the same language containing what is considered hip for the past few years has been built at least a dozen times and I am a bit worried that this will lead to a lot of tools that are really nice, well designed, but have to be rewritten eventually because the languages cease to exist - in the sense of them not being worked on other than a few people.
Even in the space of “Go with more features” there’s multiple languages now that are really rather similar, even though to be fair the way they are implemented are numerous. I think it could be super fun to have the project come together and talk about their differences and issues and maybe there would even be mergers, but even if not I think it could be really interesting.
Rust as a requirement only in the sense that you use it to build the compiler. If you just download a pre-built binary it’s not a requirement at all.
LLVM doesn’t appear to be a requirement at all. I mean sure, the rust compiler (not the borgo compiler, the compiler that compiles the borgo compiler) by default uses it to produce that binary if you aren’t downloading a pre-built one, but there are alternative backends and alternative rust compilers if you really want to avoid LLVM for some reason.
Rust as a requirement only in the sense that you use it to build the compiler. If you just download a pre-built binary it’s not a requirement at all.
If A requires B so I can compile it then B is a requirement to me. Also I don’t see an official pre-built binary.
This seems like an extremely shallow criticism.
You only picked one point you say doesn’t apply to you. So, sorry that my criticism isn’t good enough for you.
Maybe I also wasn’t clear enough. It wasn’t really about what you need to install, but the fact that with LLVM you have a tool box to make something stand alone and there are a list of similar projects out there that do exactly that. Targeting Go seems like an odd choice to me, because the Go compiler is specifically made to compile Go, while with LLVM you get a whole framework and ecosystem that is for designing languages.
Even if you say you don’t want to have LLVM you still have “Go with more features” . For example V, which also comes with sum types, result type, more strictness, enums, etc. It’s certainly not the only option though.
It seems like the author re-uses the Rust parser, and also a fan of the language. Now that Borgo exists, I suppose it can be used to implement the compiler with niceties such as pattern matching and ADTs.
I suppose you can also commit the compiler output so that users can just use go toolchain to compile and run the program.
Go with sum types, real generics, tuples, pattern matching, and thus proper error handling?
This is awesome.
Exhaustive pattern matching, too! Which I find to be the most valuable aspect in writing resilient code with ADTs, since it ensures you don’t miss any possible states when you add a new tag.
Typescript for Go?
It does look cool. It reminds me in principle of CoffeeScript, which I did enjoy using for a while, and I guess it’s technically not dead though the last release was in 2022. But I would be wary of basing anything serious on this yet!
The “complexity vs type safety” graph on the front page is the realest thing I’ve seen all year, and a great argument for the language’s existence. Serious props to the creator.
Shame that it seemingly hasn’t been developed for 8 months, it looks really neat.
Looks nice but wait, is requiring Go and Rust the new requiring Python and Ruby?!
I assume it requires Rust to build but only requires Go to run?
Go is compiled as well. The toolchain you need on your dev environment includes Rust and Go in order to build a Borgo program. You get a static binary that do not need any interpreter.
once borgo has binaries out you’ll not need a Rust toolchain just to build borgo programs, though.
This looks very cool, and might be a reason for me to actually use Go. I used it professionally severally years ago and really did not enjoy the experience, but that was mostly because it lacked a lot of the features that Borgo adds.
That said, the graph on the homepage made me laugh. Why is it linear until we get to Rust, and then exponential? Haskell and Idris are more type-safe (or, at least, have more type-related features) than Rust; is the implication that they’re dozens of times more complex as well? It’s weird.
My brain’s version of the graph is “convenience vs. control”. Sliced on that axis, Haskell and Idris offer a lot less control than Rust.
Fair enough, yeah! With those axes, I think I can swallow it.
Nice to see a language website with actual examples easily accessible!
Does anybody think the Rust “?” error propogating operator is too subtle & easily missed though? To my eyes zigs try expression is a whole lot more readable
vs
I agree. It’s funny, given one of the first languages I got into as a teenager was Perl, yet I really dislike how it is popular to have symbols all over the place. Sometimes I think I went into programming rather than math, because it’s easier to read and write most of of the time. In all honesty one of the things I dislike about Zig is that there are still way too many symbols.
It’s odd to me that on one hand people hope to make it less verbose and on the other hand people suddenly started using colons between type and name. I’ve heard people say “that way you know which side the type is on”, which I don’t really follow. Why does a colon plus space make that clearer than just a space? And things like
?*Foomake me unhappy.For Go (when considering only the language) I think one of the biggest blunders is how there is a
new(type)and&type{}, which is redundant, but in cases where you want to donew(int)for example. But then compared to most other languages, trying to copy whatever is trendy in a given year, ending up with eight ways to do the same thing and as a newcomer having to learn “that’s the old way” it feels like a pretty minor thing. Sadly now there’s alsointerface{}andany.Before the
?operator rust used to have atr!(expr)macro that did the same thing. The observation from moving to the?macro was that post fix operators work really nicely in conjunction with method chaining.I don’t think your alone in your concern, but in practice I think people used to rust have found it to be fine, and I think we really don’t want to switch to a prefix operator. If anything there’s a trend of thinking “what else can we make postfix”.
expr.trymight be an alternative worth considering for a new language.How practical is it to debug apps written in this language with delve or other Go debuggers? Seems like it would be hard to match what you see in the debugger with the source code you wrote since it’s being “compiled” to Go first.
FWIW compiler output looks readable. Unless you have a lot of logic within long pattern match statements, it should be pretty straightforward to debug and follow the code with standard go toolchain.
One would probably need a “source map”, a bit like the one people use when they compile TypeScript to JavaScript and try to find bugs.
This is what peak “programming language homepage” looks like.
The language itself looks pretty nice too.
I wonder if it will always keep compiling to Go, or if this is going to be to Go what C++ is to C. C++ also initially compiled to C, eventually people wrote standalone C++ compilers.
This is genuinely amazing. Go with sprinkles of Rust, a developers dream.
Love the graph on the page. The sweet spot for almost all software development.
I love this, I‘d try this for the enums alone.
Rust and LLVM as a requirement, but also Go, so you don’t even get rid of the garbage collector, can’t really do more low level stuff easily. All of that to just bring more complexity to a language that set out to avoid it.
Don’t get me wrong, I find it really cool that people build new languages, yay LLVM, but it feels like lately pretty much the same language containing what is considered hip for the past few years has been built at least a dozen times and I am a bit worried that this will lead to a lot of tools that are really nice, well designed, but have to be rewritten eventually because the languages cease to exist - in the sense of them not being worked on other than a few people.
Even in the space of “Go with more features” there’s multiple languages now that are really rather similar, even though to be fair the way they are implemented are numerous. I think it could be super fun to have the project come together and talk about their differences and issues and maybe there would even be mergers, but even if not I think it could be really interesting.
Rust as a requirement only in the sense that you use it to build the compiler. If you just download a pre-built binary it’s not a requirement at all.
LLVM doesn’t appear to be a requirement at all. I mean sure, the rust compiler (not the borgo compiler, the compiler that compiles the borgo compiler) by default uses it to produce that binary if you aren’t downloading a pre-built one, but there are alternative backends and alternative rust compilers if you really want to avoid LLVM for some reason.
This seems like an extremely shallow criticism.
If A requires B so I can compile it then B is a requirement to me. Also I don’t see an official pre-built binary.
You only picked one point you say doesn’t apply to you. So, sorry that my criticism isn’t good enough for you.
Maybe I also wasn’t clear enough. It wasn’t really about what you need to install, but the fact that with LLVM you have a tool box to make something stand alone and there are a list of similar projects out there that do exactly that. Targeting Go seems like an odd choice to me, because the Go compiler is specifically made to compile Go, while with LLVM you get a whole framework and ecosystem that is for designing languages.
Even if you say you don’t want to have LLVM you still have “Go with more features” . For example V, which also comes with sum types, result type, more strictness, enums, etc. It’s certainly not the only option though.
I’ve been hoping for “Go with sum types” for a long time - this is awesome!
Looks nice! But am I understanding it right that to use this I need both Go and Rust installed on my system?
Borgo itself is written in Rust so I first need Rust to build Borgo. And then I need Go to generate an executable for my Borgo program?
Why was this choice of using two separate compiler toolchains made? Couldn’t it have been possible to have written Borgo in Go?
It seems like the author re-uses the Rust parser, and also a fan of the language. Now that Borgo exists, I suppose it can be used to implement the compiler with niceties such as pattern matching and ADTs.
I suppose you can also commit the compiler output so that users can just use go toolchain to compile and run the program.
This sounds like a dream come true.