This is a language that everyone here says they want but no one will use, even though it's stable and mature (I assume because it compiles to stable and mature Go and can use every existing Go library).
It hits all the "ok, Go is popular but made by morons for morons and if only it had this X advanced feature, it would be totally great".
It has immutability. It has advanced enums. It has algebraic types. It has pattern matching. It has Result<> instead of returning an error. It gets rid of if err != nil. It gets read of of nil pointers.
On paper it's a perfect language. It literally addresses every major complaint people have with Go.
And I'll be here not using it and watching everyone else not use it.
Because the harsh truth is that none of those things are actually big issues that would justify learning slightly different syntax.
I do agree with you to a degree, but let's not forget the monumental successes that are TypeScript and Kotlin.
There have been lots of such languages that transpiled to JavaScript or worked on the JVM, adding nicer syntax and features. Many of them went nowhere, but quite a few of them did get widely adopted. Off the top of my head, CoffeeScript was also relatively popular for a while, and Clojure builds on top of both ecosystems, Scala comes to mind too.
Go might be in a similar situation right now, where it has become entrenched in certain domains (like DevOps), and lots of people are not entirely satisfied with it but they can't to switch to something else. Is Go getting a similarly bad reputation as JavaScript or Java to push this through? Is the lock-in as strong as in browsers or Android? No, I wouldn't say it's there yet, but still, it is worth a shot to try to build such an alternative language.
I do agree that Borgo will probably not be adopted widely, the pains it addresses are not strong enough and the language does not seem to be properly maintained and supported. But history shows it is not as unlikely as you suggest.
Kotlin so crazy with its default-closed, default-final method approach. Do these people even ship software? Or do they ship textbooks? People are acting likely they are writing chapters of Biblical verse with their code—they knew everything better than the user, including knowing what to hide. It’s OK/good to have extensible code, even if the original did not intend it.
To have every class be final by default and hidden from callers might be sane for shipping a library—-but you definitely should not adopt it as internal policy in your own code base, for your own’s sake. Why should I tax myself with having to worry about calling out extensibility by hand at every step? This is just crazy to me!
I’m all for Kotlin’s success as we desperately need something better than Java still. I’m rooting for you.
The lock-in with Go is the massive copy-pasta style and throw-away code mindset that is pretty much all that I see. But there is very little good Go code out in the wild to show us how it’s done.
It'll probably not get as much traction as Go, but for a simpler reason that may not be as ideologically satisfying for you. It's just really hard for a new language to get real traction, no matter how good it is. And it's even harder for transpiled languages, because they almost always gets overshadowed by the language they're transpiling to.
What I find truly fascinating is that given the complexity of most build systems (especially ones that use babel) basically every node project I encounter is in fact effectively transpiled, it's just it's "javascript compiled to javascript" rather than having a different source syntax.
I don't even mind[0], I think it's actually kind of amazing.
[0] I have all the usual complaints about build systems and about the node ecosystem in general, but I don't think the fact that it's javascript compiled to javascript in and of itself is a problem, only, well, almost everything about how that's usually implemented/achieved :D
I don't think the impediment to adoption is the syntax - that's straightforward enough - it's the ecosystem / tooling / network effects.
I love this, even though I don't interact with Go on a regular basis, but I recognise that I'd be locking myself out of a lot of the standard Go tooling if I adopted this wholesale. For better or for worse, there's a high ecosystem barrier that most languages must overcome to be adopted, and the vast majority of efforts never get to that.
What standard tooling would fail, given that the translation goes via a a generated Go source?
I suppose there must be some borgofmt that handles the particular syntax. Certainly debuggers would have to be updated to show the corresponding Borgo code line at least.
> Because the harsh truth is that none of those things are actually big issues that would justify learning slightly different syntax.
That's partially the cost, but the other cost is building this into existing tool chains and deployment mechanisms. Getting buyin from teams, ensuring _everyone_ learns the syntax.
And the unstated fear: The code it generates, is it actually good? Am I going to have silly issues down the road that are hard to debug and require diving into generated code to see some concurrency issue?
I don't think that's why nobody will use it. The real reasons are:
1. People who want Rust will just use Rust. You can keep your Rust code simple if you want, most of the time. I think most people that object to Go's issues have moved on from Go by now. Kind of like how safe C++ has no chance because most of the people that get it have left C++ already.
2. It's clearly not mature. Not many people jump on one man languages. If this was backed by a large company I suspect the story would be different.
Still, it seems to be tastefully designed. Might have a chance I guess.
> It hits all the "ok, Go is popular but made by morons for morons and if only it had this X advanced feature, it would be totally great".
The people who use Go despite its issues are using it because of the tiling and the massive Google backing. Neither of which this has. Someone who wants a language that implements some of the good ideas of the 1970s and is willing to leave Go for that already has many established options.
> This is a language that everyone here says they want but no one will use, even though it's stable and mature (I assume because it compiles to stable and mature Go and can use every existing Go library).
Note the thread here about the lack of a license. You cannot legally use it.
Even if you risk using it, people are also wary of using a language that has a single developer behind it, and would be even if it were open source.
Some people don’t like Go but have no reason (or something compelling them) to use it. So they use other languages. They don’t need a new source-to-source compiler. Your point is moot for this group.
But some people might have to use it. So this language is at least relevant to them. If indeed it addresses all of the complaints. But that might be hard for a language which only compiles to that other language to do.
> Because the harsh truth is that none of those things are actually big issues that would justify learning slightly different syntax.
The syntax has nothing to do with it, you already know the syntax. I'm fairly confident most people reading this comment can program in this language right now, without opening the docs.
The reasons I won't be using it are:
1. It's a source to source transpiler - even when done nearly perfectly, these always introduce problems. Debugging TS is never 100% seamless. Debugging minified JS is annoying, even with a sourcemap.
2. Go code tends to be very simple and "un-abstract", so the problems with the language's syntax and typesystem aren't bad enough to justify a wrapper.
3. I don't want to be an early adopter of programming languages. This may be harsh, but I won't consider a language until it reaches at least #50 in popularity someone is paid to work on the tooling full time. Hobbyists enjoy solving interesting problems like language design, but don't particularly enjoy the "gruntwork" some of which is critical - a comprehensive test suite, a fuzzer for the compiler, an LSP/IDE/editor plugins, a good standard library...
There have been a lot of promising one-man projects such as this one, that get abandoned when the lead developer moves on. You don't want to be stuck holding the bag with a large codebase in a zero user language.
JavaScript had Netscape behind it,
TypeScript has Microsoft behind it,
Rust had Mozilla behind it,
Go has Google behind it,
Java had Sun behind it,
C++ had AT&T behind it,
and so on..
Borgo?
Cannot think about much languages that haven't any bigger company behind it.
PHP maybe? To an extend Python? But today Python good pushed by the big companies of the AI hype.
Python was obscure and developed in silence for 15 years before it caught on. The team behind it just never gave up. Most people who develop independent languages give up after a year or five. Lua is similar, though it and PHP both caught on faster because they both put embedding upfront, which allowed them to be built into game engines and websites built with C.
The creators of Go have also built the foundation of everything you take for granted. The real "harsh truth" here, of course, is that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry, such that the likes of Rust "death by committee" people may only dream of. The long-lasting obsession that Rust people have with Go and the Go team has become a meme.
Borgo is the recognition of that: a handout to Rust people that they will never appreciate.
> The creators of Go have also built the foundation of everything you take for granted
Is it the foundation because it was built a long time ago, and is "good enough" .. or because it's just really good? "Worse is better" comes to mind.
There was another post on hn today about "pipelines getting stuck" that was really just about poor interaction between pipelines and programs changing their buffering behavior based on `istty()`. bash has been around a long time, and will stay around for a long time still, but that doesn't mean its design leaves nothing to be desired. It just means the benefits of changing it haven't crossed the 10x threshold of the costs (partially because it's foundational).
People seriously act like Rob Pike's quote was about appealing to the lowest common denominator of programmers possible without realizing that the functional programming concepts they hold so dearly have been lacking for 50 years in the world of C/C++ where it's creators came from. They are so quick to frustration over the fact that the some languages don't act like they think it should and don't require the extraneous baggage of higher-order programming in order to quickly be productive in, while at the same time the entire operating system their computer runs on contains not a single line of map(), reduce() or filter().
Fitting a C compiler on a PDP-11 was an impressive achievement, but as a language it was a poor foundation to build anything reliable, and we still live with the consequences.
The problem is that it is useless to try to fix Go, because that isn't what the community appreciates.
One is better off wasting brain cycles contributing to C#, Java, Kotlin, Swift, Scala, D,.... where a language being feature rich is appreciated by the community.
You're right nobody will use it: it's a one man language are you going to bet your codebase on it?
It probably doesn't have any tooling, debugggers.. Are the error messages from the compiler good?
Elm is also a one-man language, but it enjoyed some popularity. Zig has been a one-man language for some time, but it's got traction, following, and more contributors.
Syntax squiggles are not very important, but other language features, like a good design and removing whole classes of bugs, are.
I think it’d do a lot better with Rust fans than Go fans, to be honest. It may not he as safe or whatever but Rust build times are brutal for larger projects and their ecosystems are mature enough to be comparable.
It’d be even more useful with a Rust/Borgo interop layer but I bet that’d be really complicated.
I like languages that can be compiled, I like modern type systems. Rust is neat but my occasional dabbling hasn’t yielded much productivity. Go has too many icky bits.
> compiles to stable and mature Go and can use every existing Go library
Go+[1](goplus), around since 2020, is already an "extra features" version of Go, that compiles into Go
> It has immutability. It has advanced enums. It has algebraic types.
> It literally addresses every major complaint people have with Go
V[2](vlang) is a Go alternative language that has such features. It was originally given the title of child of Rust and Go[3]. On top of that, even has a Go2V transpiler available.
Speaking of Go alternatives, Odin[4] is not too far away as well, and has recently taken the position of labeling itself as an alternative to Go.
> if only it had this X advanced feature, it would be totally great
Not only are these languages labeled as Go alternatives (Go+, Vlang, and Odin), but they have a significant number of fans, more GitHub stars, and/or a large numbers of contributors.
It could be argued that the field is already kind of crowded. If we squint a little, several other languages could have been added to the list (like C3 and Jai), as alternatives.
I've been planning to use it, because of all the reasons you mentioned and because I prefer Rust but I also want access to the Go ecosystem and the Charm/Bubbletea TUI world in particular.
And by that I don't mean using Rc<> everywhere nor do I even mean making a GC library and then using GC<> everywhere. I mean having the runtime handle all memory things with you having to think about it only when some extremely rare corner case breaks.
This is quite beautiful. It hides several ugly warts of Go without necessarily adding more complexity. Result<T> instead of (T, error) and ? for propagation is just so nice. Structured enums is something I find myself needing all the time (and writing less self-explanatory code due to the lack of it). Option<T> instead of nil and zero values (which builds upon structured enum support) is what got me to say "yes please!"
Honestly, some of the things they changed are maybe unnecessary (like the additional impl syntax, the Zig influenced dereferencing, return values from statements, several other Rustisms, etc). One part of me wish Go would get all of this. But another part of me knows it would never happen because this is not a superset (Python 2 -> Python 3 anyone?)
I also wonder if this could even be compared to JavaScript / TypeScript for the same reason, not being a superset means you have to actively make a change to even start to migrate, and the revert path is not as trivial.
Zig is not a superset of C, and Rust is not a superset of C++; does this hinder their adoption a lot
Also, the pain of Python 2 -> 3 migration was that you can't mix py2 and py3 code in one project. This is not the case with Borgo apparently: you can mix it with Go, much like you can mix C++ / Zig / Rust with C, or TS with JS, or even Kotlin with Java.
By having excellent interoperability, Borgo may have a good chance of wider adoption. If I were its maintainer, I'd prioritize interoperability with plain Go and its stdlib highly.
There are various syntax changes, such as let. Of course, if Borgo could be modified to not have let, but that would be a backward incompatible change.
That would be cool; although I don't think that being a superset would be that useful.
I think just being able to use borgo and go files in the same project is more than enough for all practical purposes. Borgo and go living in the same file, or go files running as borgo files would be cool, but would have no practical benefits?
This is interesting except for the fact that there is no license. This makes this "language" technically only usable by the creator?
This is what GH says about no license being included. I almost think they should make including a license obligatory.
> You're under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you're creating an open source project, we strongly encourage you to include an open source license. The Open Source Guide provides additional guidance on choosing the correct license for your project.
Note
If you publish your source code in a public repository on GitHub, according to the Terms of Service, other users of GitHub.com have the right to view and fork your repository. If you have already created a repository and no longer want users to have access to the repository, you can make the repository private. When you change the visibility of a repository to private, existing forks or local copies created by other users will still exist. For more information, see "Setting repository visibility."
Also if it compiled to Rust instead of Go (it is written in Rust which made me think it compiled to Rust for a minute) we could do something about that darn GC.
Gleam compiles to Erlang. Kotlin compiles to JVM bytecode and has great interop with Java. Rust and Zig easily call C. Elm compiles to JS and has a clear means to calling JS. TypeScript/ReScript/ReasonML all do something similar.
All these languages add type-safety and/or sum types and/or immutability-by-default and/or explicit-nullability.
I wish Borgo the best in doing the same for the Golang ecosystem. It's sorely needed.
There are some interesting design ideas, but I'm not sure where the project is going. Based on the commit history, it was created by one person and there has been almost no activity in the last 12 months.
The current status is unclear (is anyone willing to use it in production) and the lack of license is of course a concern.
I can't immediately find it but somebody once said something like "on a long enough timeline, all languages become CommonLispScript with different syntax" and there's definitely some truth to that.
> Now give it to google, release it as .go2, and make it frictionless to use Go and Go2 in a codebase.
Has Google ever "taken" an already created project under their wing and ran with it? AFAIK, Google only does the opposite and releases projects from their grips, but never the opposite. "Everything Google does, Google must invent" is how it looks like from the outside at least.
If Google adopts an existing OSS technology, it usually takes the form of Google contributors joining a core team for the OSS in question. The OSS community generally isn't a fan of single companies taking _over_ a project and generally prefers ownership changes in the other direction (e.g. Kubernetes getting transferred to the CNCF).
That being said, the most noticeable example here that I can think of is Google migrating its internal C++ toolchain from using gcc/g++ to clang.
The graph showing complexity against type safety is nice. I'd love to see it as a scatter plot with C and Haskell and MUMPS for example. Nevermind how to quantify those things of course.
Readit News
This is a language that everyone here says they want but no one will use, even though it's stable and mature (I assume because it compiles to stable and mature Go and can use every existing Go library).
It hits all the "ok, Go is popular but made by morons for morons and if only it had this X advanced feature, it would be totally great".
It has immutability. It has advanced enums. It has algebraic types. It has pattern matching. It has Result<> instead of returning an error. It gets rid of if err != nil. It gets read of of nil pointers.
On paper it's a perfect language. It literally addresses every major complaint people have with Go.
And I'll be here not using it and watching everyone else not use it.
Because the harsh truth is that none of those things are actually big issues that would justify learning slightly different syntax.
But maybe I'm wrong. Time will tell.
There have been lots of such languages that transpiled to JavaScript or worked on the JVM, adding nicer syntax and features. Many of them went nowhere, but quite a few of them did get widely adopted. Off the top of my head, CoffeeScript was also relatively popular for a while, and Clojure builds on top of both ecosystems, Scala comes to mind too.
Go might be in a similar situation right now, where it has become entrenched in certain domains (like DevOps), and lots of people are not entirely satisfied with it but they can't to switch to something else. Is Go getting a similarly bad reputation as JavaScript or Java to push this through? Is the lock-in as strong as in browsers or Android? No, I wouldn't say it's there yet, but still, it is worth a shot to try to build such an alternative language.
I do agree that Borgo will probably not be adopted widely, the pains it addresses are not strong enough and the language does not seem to be properly maintained and supported. But history shows it is not as unlikely as you suggest.
To have every class be final by default and hidden from callers might be sane for shipping a library—-but you definitely should not adopt it as internal policy in your own code base, for your own’s sake. Why should I tax myself with having to worry about calling out extensibility by hand at every step? This is just crazy to me!
I’m all for Kotlin’s success as we desperately need something better than Java still. I’m rooting for you.
The lock-in with Go is the massive copy-pasta style and throw-away code mindset that is pretty much all that I see. But there is very little good Go code out in the wild to show us how it’s done.
I don't even mind[0], I think it's actually kind of amazing.
[0] I have all the usual complaints about build systems and about the node ecosystem in general, but I don't think the fact that it's javascript compiled to javascript in and of itself is a problem, only, well, almost everything about how that's usually implemented/achieved :D
I love this, even though I don't interact with Go on a regular basis, but I recognise that I'd be locking myself out of a lot of the standard Go tooling if I adopted this wholesale. For better or for worse, there's a high ecosystem barrier that most languages must overcome to be adopted, and the vast majority of efforts never get to that.
I suppose there must be some borgofmt that handles the particular syntax. Certainly debuggers would have to be updated to show the corresponding Borgo code line at least.
What else?
That's partially the cost, but the other cost is building this into existing tool chains and deployment mechanisms. Getting buyin from teams, ensuring _everyone_ learns the syntax.
And the unstated fear: The code it generates, is it actually good? Am I going to have silly issues down the road that are hard to debug and require diving into generated code to see some concurrency issue?
1. People who want Rust will just use Rust. You can keep your Rust code simple if you want, most of the time. I think most people that object to Go's issues have moved on from Go by now. Kind of like how safe C++ has no chance because most of the people that get it have left C++ already.
2. It's clearly not mature. Not many people jump on one man languages. If this was backed by a large company I suspect the story would be different.
Still, it seems to be tastefully designed. Might have a chance I guess.
The people who use Go despite its issues are using it because of the tiling and the massive Google backing. Neither of which this has. Someone who wants a language that implements some of the good ideas of the 1970s and is willing to leave Go for that already has many established options.
Note the thread here about the lack of a license. You cannot legally use it.
Even if you risk using it, people are also wary of using a language that has a single developer behind it, and would be even if it were open source.
Some people don’t like Go but have no reason (or something compelling them) to use it. So they use other languages. They don’t need a new source-to-source compiler. Your point is moot for this group.
But some people might have to use it. So this language is at least relevant to them. If indeed it addresses all of the complaints. But that might be hard for a language which only compiles to that other language to do.
The syntax has nothing to do with it, you already know the syntax. I'm fairly confident most people reading this comment can program in this language right now, without opening the docs.
The reasons I won't be using it are:
1. It's a source to source transpiler - even when done nearly perfectly, these always introduce problems. Debugging TS is never 100% seamless. Debugging minified JS is annoying, even with a sourcemap.
2. Go code tends to be very simple and "un-abstract", so the problems with the language's syntax and typesystem aren't bad enough to justify a wrapper.
3. I don't want to be an early adopter of programming languages. This may be harsh, but I won't consider a language until it reaches at least #50 in popularity someone is paid to work on the tooling full time. Hobbyists enjoy solving interesting problems like language design, but don't particularly enjoy the "gruntwork" some of which is critical - a comprehensive test suite, a fuzzer for the compiler, an LSP/IDE/editor plugins, a good standard library...
There have been a lot of promising one-man projects such as this one, that get abandoned when the lead developer moves on. You don't want to be stuck holding the bag with a large codebase in a zero user language.
https://survey.stackoverflow.co/2024/technology#most-popular...
The most important factor for a language is Big Tech backing. Little squabbles on syntax or language features or philosophies are entirely secondary.
Borgo?
Cannot think about much languages that haven't any bigger company behind it. PHP maybe? To an extend Python? But today Python good pushed by the big companies of the AI hype.
>Cannot think about much languages that haven't any bigger company behind it.
Ruby.
The creators of Go have also built the foundation of everything you take for granted. The real "harsh truth" here, of course, is that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry, such that the likes of Rust "death by committee" people may only dream of. The long-lasting obsession that Rust people have with Go and the Go team has become a meme.
Borgo is the recognition of that: a handout to Rust people that they will never appreciate.
Is it the foundation because it was built a long time ago, and is "good enough" .. or because it's just really good? "Worse is better" comes to mind.
There was another post on hn today about "pipelines getting stuck" that was really just about poor interaction between pipelines and programs changing their buffering behavior based on `istty()`. bash has been around a long time, and will stay around for a long time still, but that doesn't mean its design leaves nothing to be desired. It just means the benefits of changing it haven't crossed the 10x threshold of the costs (partially because it's foundational).
Those geniuses fought against implementing generics for almost 10 years.
One is better off wasting brain cycles contributing to C#, Java, Kotlin, Swift, Scala, D,.... where a language being feature rich is appreciated by the community.
Syntax squiggles are not very important, but other language features, like a good design and removing whole classes of bugs, are.
It’d be even more useful with a Rust/Borgo interop layer but I bet that’d be really complicated.
I like languages that can be compiled, I like modern type systems. Rust is neat but my occasional dabbling hasn’t yielded much productivity. Go has too many icky bits.
Borgo? I will definitely be trying it out!!
Go+[1](goplus), around since 2020, is already an "extra features" version of Go, that compiles into Go
> It has immutability. It has advanced enums. It has algebraic types. > It literally addresses every major complaint people have with Go
V[2](vlang) is a Go alternative language that has such features. It was originally given the title of child of Rust and Go[3]. On top of that, even has a Go2V transpiler available.
Speaking of Go alternatives, Odin[4] is not too far away as well, and has recently taken the position of labeling itself as an alternative to Go.
> if only it had this X advanced feature, it would be totally great
Not only are these languages labeled as Go alternatives (Go+, Vlang, and Odin), but they have a significant number of fans, more GitHub stars, and/or a large numbers of contributors.
It could be argued that the field is already kind of crowded. If we squint a little, several other languages could have been added to the list (like C3 and Jai), as alternatives.
[1]: https://goplus.org/
[2]: https://vlang.io
[3]: https://www.youtube.com/watch?v=puy77WfM1Tg (Is VLang Better Than Go And Rust? --Anthony GG)
[4]: https://odin-lang.org/
Just because it's compatible with Go doesn't mean that 3rd party Go dependencies will be a natural fit for it.
Existing IDEs and other tooling won't work.
Community is unlikely to grow.
etc
Deleted Comment
It addresses complaints 1 to n but does nothing about complaint 0: Having a garbage collector with all its associated downsides.
And by that I don't mean using Rc<> everywhere nor do I even mean making a GC library and then using GC<> everywhere. I mean having the runtime handle all memory things with you having to think about it only when some extremely rare corner case breaks.
Honestly, some of the things they changed are maybe unnecessary (like the additional impl syntax, the Zig influenced dereferencing, return values from statements, several other Rustisms, etc). One part of me wish Go would get all of this. But another part of me knows it would never happen because this is not a superset (Python 2 -> Python 3 anyone?)
I also wonder if this could even be compared to JavaScript / TypeScript for the same reason, not being a superset means you have to actively make a change to even start to migrate, and the revert path is not as trivial.
C++ is a superset of C; did it do much good?
Zig is not a superset of C, and Rust is not a superset of C++; does this hinder their adoption a lot
Also, the pain of Python 2 -> 3 migration was that you can't mix py2 and py3 code in one project. This is not the case with Borgo apparently: you can mix it with Go, much like you can mix C++ / Zig / Rust with C, or TS with JS, or even Kotlin with Java.
By having excellent interoperability, Borgo may have a good chance of wider adoption. If I were its maintainer, I'd prioritize interoperability with plain Go and its stdlib highly.
There are various syntax changes, such as let. Of course, if Borgo could be modified to not have let, but that would be a backward incompatible change.
I think just being able to use borgo and go files in the same project is more than enough for all practical purposes. Borgo and go living in the same file, or go files running as borgo files would be cool, but would have no practical benefits?
This is what GH says about no license being included. I almost think they should make including a license obligatory.
> You're under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you're creating an open source project, we strongly encourage you to include an open source license. The Open Source Guide provides additional guidance on choosing the correct license for your project.
Note
If you publish your source code in a public repository on GitHub, according to the Terms of Service, other users of GitHub.com have the right to view and fork your repository. If you have already created a repository and no longer want users to have access to the repository, you can make the repository private. When you change the visibility of a repository to private, existing forks or local copies created by other users will still exist. For more information, see "Setting repository visibility."
Also if it compiled to Rust instead of Go (it is written in Rust which made me think it compiled to Rust for a minute) we could do something about that darn GC.
What would be the point of compiling to Rust? Just use Rust in that case.
All these languages add type-safety and/or sum types and/or immutability-by-default and/or explicit-nullability.
I wish Borgo the best in doing the same for the Golang ecosystem. It's sorely needed.
The current status is unclear (is anyone willing to use it in production) and the lack of license is of course a concern.
Borgo is a statically typed language that compiles to Go - https://news.ycombinator.com/item?id=40211891 - April 2024 (545 comments)
Show HN: Borgo – a Rusty language that compiles to Go - https://news.ycombinator.com/item?id=36847594 - July 2023 (8 comments)
Now give it to google, release it as .go2, and make it frictionless to use Go and Go2 in a codebase.
Has Google ever "taken" an already created project under their wing and ran with it? AFAIK, Google only does the opposite and releases projects from their grips, but never the opposite. "Everything Google does, Google must invent" is how it looks like from the outside at least.
That being said, the most noticeable example here that I can think of is Google migrating its internal C++ toolchain from using gcc/g++ to clang.
I do know that adding C to that graph would require changing the Y axis to a logarithmic scale.