The Borgo Programming Language
borgo-lang.github.io
borgo-lang.github.io
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.
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?
Any and all linters for Go, to start. In theory, you could run them on the transpiled source, but the results would be very hard to apply to the original Borgo code. And they'd probably produce lots of false positives for things that the Borgo compile ensures are safe, even if they're not linting-correct.
And syntax highlighting, refactoring tools, an LSP server. I'm sure there are more things along these lines I'm failing to think of.
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!!
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.
Higher order functions often seems to be a way to complicate otherwise easy to read code. Kotlin manages to do it reasonably well, in Javascript I has beem behind some of my absolutely worst debugging experiences.
The problem with Go, as far as I have seen is not about functional programming, but rather about things like making a point out of not supporting generics for years.
For anyone who has experienced the Java 1.4 to Java 5 transition, and all the cruft it removed I cannot see how any of them can willingly accept a language that made a point out of being clumsy so one had to do it the old clumsy way agaim.
Or how a language that us supposedly a good fit for web backends had (don't know if it have now, I've given up) no simple way in the standard library or any popular templating solution to say in a template that it should be included in a bigger template, thereby forcing the code to know about things that belong in the design world.
I.e. to have
- a common header with dynamic title
- a dynamic part between
- and common footer
the correct way last I checked seemed to be to string them together like a php script from the late nineties.
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).
Had UNIX been a commercial product from the get go, and most likely C wouldn't have taken off as it did.
Those geniuses fought against implementing generics for almost 10 years.
It's lists, and maps.
> The generics in Go have turned out dogshite
Pick one.
This is dogshite because I have to fork a bunch of stuff to actually use it!
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.
JetBrains and Android manage to ship Kotlin software.
Unfortunately software architecture isn't part of most bookcamps, or many devs that rather code away.
You think you thought of the proper public API that your software modules should have? Especially your internal software? Of course you didn’t think of it all ahead of time. It’s a software architecture concept called “open for extension”, look it up.
JetBrains doesn’t ship anything with deadlines or that must always stay on. Users can always downgrade the IDE. The number of times I’ve been to turn off the latest feature and try again (to see if the IDE still crashes) is ridiculous. Number of times my build stayed stable after a major IntelliJ Idea upgrade? 50% success rate. I’m rolling the dice on every upgrade. Please let’s talk about shipping software with consequences.
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.
Community > Company
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.
It addresses complaints 1 to n but does nothing about complaint 0: Having a garbage collector with all its associated downsides.
I think Borgo sits at an interesting place in the design space. I just believe there are vast plains of unsettled land in the strongly typed GC-less direction and a language that really addressed all complaints about Go would have live there.
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.
https://learn.microsoft.com/en-us/dotnet/standard/memory-and...
It's worse at dealing with ref structs so C# is better for some low-level tasks. But it has other niceties like IL-level function and lambda inlining.
Tho point of Rust is to be safe language without GC. Even if not perfect, best thing about Rust is borrow checker and border between safe/unsafe. You can use several other languages, like Ocaml, if you want Rust with GC.
I could imagine people want a programming language that is: memory safe, without GC pauses. A bit slower by default than C / Rust, but with the _option_ to make it as fast. Then easier to learn, less vendor lock-in than Swift, and a modern syntax (no null pointers etc).
I don't think such a language exists currently.
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
OTOH I haven't seen a pure JavaScript project for a number of years. It's all Typescript now, maybe with some vestiges of legacy JS slated for eventual migration to TS.
Much, not so much.
I see JSX as basically 'compiling augmented javascript to javascript,' much of decorators is much like that as well, and things like e.g. vue's turning expressions on its reactivity based signals seen in templates into something more clever is also in the category I was trying to gesture at.
(TS is awesome but I should've predeclared that it wasn't really what I had in mind, sorry for any confusion induced by that mistake on my part)
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?
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.
Hence better invest into ecosytems that value language design PhDs....
There is even the JVM Languages Summit.
Unthinkable in Go ecosystem.
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
-- Rob Pike
Sounds pretty damning, I'd say. This of course illustrates why Go is called "systems PHP".
> how much one was willing to pay for a commercial JDK.
I strongly prefer open-source tools at the base of my stack. Not as much because of the money but more because of the level of trust. Things should be inspectable.
- .Net devs (they are almost as annoying as us Java/Kotlin devs)
- a language and ecosystem that consistently sacrifice backwards compatibility (contrary to us who have features sacrificed for backwards compatibility at every single step)
- you have to live without the JVM ecosystem (on this I have no self deprecating comment, C# is a better language, but the ecosystem, from libraries to build system to IDEs is something I always miss when I work in .Net.)
.NET maintains excellent backwards compatibility, C# and F# even more so. The changes either affect frameworks and libraries, which you can often update independently or are easily addressed. Most projects since .NET 5 only ever had to bump the target version and rebuild to move forward (notable exception: in .NET 6 ASP.NET Core introduced simplified API for application setup which required changes).
Neither JVM nor Go have the degree of low-level capabilities .NET provides first-class support for. And F# integrates in an easier way into existing C# solutions than Kotlin does into Java ones.
It is the GC-based Rust alternative many are looking for but are overlooking due to bias from the past.
It is my feeling that .Net developers with some years of experience get wide eyed when I tell them how I can use any old library that I need together with the newest JVM and my platform upgrades have mostly consisted of bumping numbers.
It's nothing surprising in .NET land. If you target netstandard2.0 the library will work on any version from .NET Framework 4.6.1 and upwards. For many newer features there are compat and polyfill pacakges too - that's one of the strengths to be able to use them even on the older targets.
All newer targets are forward compatible anyway. Wherever the notion of otherwise comes from it is likely a misunderstanding or trolling.
You can't make a serious argument when comparing baseline experience where .NET confidently places next to Cargo and Golang's user experience with the level of productivity it provides for setting up and managing projects and dependencies, building them and distributing them. JVM ecosystem still does not offer capability to properly and easily package the applications into a single binary except using very restrictive GraalVMs Native Image which does not have as wide ecosystem support as NativeAOT enjoys, and where it does not work .NET still gives you the ability to bundle managed assemblies into an executable together with runtime, apply trimming and get relatively compact result.
I think you should read up on the guidelines before abusing the flagging system as a way to punish someone you disagree with.
Anyway, I am out of here.
Yes there are AOT friendly frameworks, however JVM agents have also provided a way to gather the necessary data for a AOT compilation, since the Exelcisor JET days.
Including Microsoft own products.
So I would slow down on the whole Java versus .NET flamewars, regarding who's more competent.
I use both ecosystems, because both have plus and minus, and complement themselves.
Is this what is so damning about Go? The constant reposting of this quote as some sort of attack on Go's validity and reputation reeks of nothing but classism.
"incapable" != "never capable", especially when talking about fresh college graduates.
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
-- Rob Pike
That's just not what he said or implied.
It's not a perfect language, but it's a pretty good language for building shit and shipping stuff.
And it starts getting to you, because a lot of problems just don't have nice solutions in the language because of its limitations. So you start accumulating kludges, which lowers the bar for quality in the entire code base.
There are PLENTY of techniques and abstractions that are VERY useful yet not expressible in a sane way in Go.
It's a nice enough language for beginners, but acting like it's the end all of programming just makes you look like a fool.
Mr. Pike's quotation assumes that the Googlers should not be expected to be too intellectually capable. That's the damning part for me.
The fact that none of these highly accomplished individuals want anything FP-related in Go says far more than what typical Go-haters want to think it does.
Does it?
I'm not a Go hater but just because they were involved in making the things you listed doesn't mean they would do it again with Go. It just means they don't trust others with different languages.
I don't think what you said refutes people's perception of Go, which is its a fairly limited language that is good for keeping people on rails (like fresh grads). That might make sense for a large business hiring lots of people but maybe not for small companies.
Also there is a world of difference between FP features and the basic features people asked for in Go (like generics).
Or that Robert Griesemer literally is a language PhD, whose thesis was supervised by a little fellow by the name of “Niklaus Wirth”?
https://www.research-collection.ethz.ch/handle/20.500.11850/...
Syntax squiggles are not very important, but other language features, like a good design and removing whole classes of bugs, are.
If Andrew Kelly were kidnapped by aliens tomorrow, Zig would continue. I think that's the dividing point, when the bus factor is no longer one.
Elm, sadly, never achieved that. But I don't see why Borgo would necessarily follow the way of Elm and not of Zig or PHP.
Thankfully I've been able to scramble some syntax highlighting support and reverse engineer how to start and run it, and after a while it actually kind of makes sense.
But I am an engineer, not an artist, and elm code will not survive me in the code base if I can avoid it (unless there are teams of Elm programmers at a place).
Elm might remove classes of bugs, but when there is not a single developer except me who manages to wrestle with it, though luck. TypeScript also removes entire classes of bugs, and it does so while being well documented and easy to understand for devs from other mainstream languages so the other devs won't come running my way everytime they have to fix something written in it.
Technically not dead, rather stagnant, a difference that hardly matters regarding adoption and ecosystem future.
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.
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.
If you worked in a career where you needed a glue language, then you were at the very least aware that Python existed.
Employeer vibes matter.
>Cannot think about much languages that haven't any bigger company behind it.
Ruby.
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
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.
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)
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.
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?
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.
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.
You end up with the worst features as the common denominator and something you can never get rid of; the moment you call a Go library that can return nils, for example, you have to deal with those as nils (and run the risk of nil bugs) rather than the safer option type.
We've been there before. C++ chose to be largely compatible with C as it existed at the time, and that legacy casts a long shadow, even if it's no longer a strict superset. C++ still has C-style arrays, null-terminated strings, unsafe pointer arithmetic, implicit conversions, etc.
You could also argue that TypeScript's backwards compatibility with JS also adds a similar burden. It's had to provide a lot of mechanisms to allow untyped values to share the same universe as typed values.
Maybe the solution is to provide a kind of "unsafe" kind of block where you can interact safely with Go code but you're forced to deal with the discrepancies. For example, you can call a Go function that returns nil, but to pass the value out of the unsafe block, you have to convert it to an optional.
I will certainly try this out in my next personal project.
I was looking at nilsafe source analyzers etc, anything that can get prevent the programmer from referencing potentially nil pointers without checking them first!
Dart really got this handled well. This is the biggest weakness for me about go, so Borgo is worth checking out!
I was even considering also looking at making a lang that transpiles to go, that is almost syntactically identical to go, but just makes clear distinction between nillable. and never-nillable pointers, and forced check before use of any potentially nil ptr.
I'm glad Borgo now exists. I really am not motivated enough to create one myself. I just want to use one. Super happy to see I am not the only person frustrated enough by this. I'm almost at the point of throwing away my super efficient go-server code and redoing it in dart, knowing it will be far less performant, just so I can have less crashy code.
Borgo or something like Borgo could be the perfect solution. Go's toolchain is incredibly fast in build time and super efficient at run time, very few things beat it for the level of programmer productivity. Just a pitty about those damn nil pointer crashes. Would have been an almost perfect language then. Even the error by value ans dual return value stuff one can live with.
But nil pointer crashes in a high-level language in current year is too much for me. Literally a game changer in modern nil safe languages. Have pointers, but know which ones can be nil, and disallow code that can lead to nil pointer exceptions. Is this really such a strange preference to have?
And the reason I know nothing about Go is I bounced off it so hard probably due to all the things Borgo fixed! So I am probably the target developer.
That would mean pulling from git would get you code that’s harder to read than what you pushed (if that’s not the case, you wouldn’t have used that transpiler)
There also isn’t agreement on the common subset.
For example, scala has lazy sequences, Rust wants programmers to have control over memory deallocation, go (sort-of) requires threads to have small stacks, Swift has copy-on-write collections, python’s numbers automatically become bignums, many languages really need efficient boxing to have efficient implementations, etc.
Strip all that, and you end up with WASM (or, possibly, even something even smaller), and various language ecosystems would build libraries on top of that that are incompatible with each other (possibly sometimes in non-obvious ways, leading to hard to detect bugs)
- A language that transpiles down to human readable, idiomatic Go.
- Automatic folding of normal Go code into more concise/functional-style syntax.
- Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code. (Probably involving something like a lockfile).
- On-demand transpilation during VCS checkout, or transpilation can happen directly in your IDE during file load/save.
I think as long as some tricks are done, the in-IDE transpilation could even let you reuse all the existing Go syntax highlighting and autocompletion IDE infra.
I started working on an IDE plugin to prototype transpilation "Go -> new lang". The plugin would replace Go code using IDE "code-folds" so it effectively didn't exist and wouldn't impact autocomplete/highlighting. And then you could use IDE snippets that expand to Go code to "pretend" you were writing in the new language.
But unfortunately, I have too many other wild dreams in my head so it never went anywhere.
I wonder if you could cheat by insisting the original code must have been run through an opinionated formatter so there's a One True Represenation of the source and you can restrict the problem to byte-perfect reconstruction of -that-?
(I have the same dream too sometimes and keep wondering if that would, at least, be a more tractable goal for a version 0.1 if I ever get a round tuit)
But it still sounds totally doable!
The only thing I can think of that did is the Interlisp-D editing functionality provided by Interlisp Medley, where your code was stored within the system as parsed S-expr trees and when you opened an editor onto something it reverse engineered a textual expression of the thing according to your configuration.
Tagging every, single, node, with enough data to recreate the indentation and formatting seems theoretically doable, and if you're wanting to let people edit things that are, say, config file shaped, then you're going to have to do that if you want the resulting commit diffs to be sufficiently coherent that people will be willing to use it.
But taking the Medley approach for a first attempt/first release feels a lot more doable, and given the biggest obstacle to such a thing is almost certainly congruent to "being able to make a start over a weekend for the sheer fun of it" I think it's well worth considering :D
What about the other direction? I don't think it will be very useful to not be able to read the exact code you wrote after the fact. Feels like writing a book but every sentence you enter is instantly rephrased by ChatGPT to sound more convoluted.
My guess from the readme is that the author loves some of the rust features and syntax but the simplicity of having the go language and runtime take care of making it work is just too compelling. As far as the language itself, there's nothing here that you couldn't build with go and it would likely be more productive.
true rust developers will program with magnetic needle
They probably wrote the language in Rust for the same reason they wrote a new syntax for Go: they just don’t particularly like Gos syntax.
ADT in mainstream languages for me are a hard requirement. I literally think in terms of adt so often, that's frustrating modeling things differently
This fills a pretty good niche. There are several backend APIs that I want to use rust for, but ends up adding so much upkeep and complexity to deal with, but Go leaves errors uncaught.
Anyone that thinks transpilling to standard languages will remain are fooling themselves.
Like Assembly programmers always wanted to have the first generations of compilers to generate Assembly instead of machine code directly, because they didn't believe they could outperform them.
Is there an equivalent api that forces the use of Go? None that I know of. Maybe there are some domains where you need access to specialized Go packages that would be hard to recreate in another language. I see that sometimes with C and C++, but I haven’t seen it with Go.
As a happy Gopher, I’m aware I probably have blind spots about this.
Imagine you want all those three features without the original syntax vomit. Transpiling is a great way to leverage the underlying engine. Similar to how many other languages build on top of LLVM.
So while there is no strict lockin as js had with browsers, achieving a runtime on par with go is a huge moat to cross on your own.
Not true at all.
If you create and/or upload a repository to GitHub, you're giving others the permission to see and fork it. From the "Licensing a repository":
> If you publish your source code in a public repository on GitHub, according to the [Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-t...), other users of GitHub.com have the right to view and fork your repository.
https://docs.github.com/en/repositories/managing-your-reposi...
Also, GitHub’s terms say:
“If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license.”
Part of that reads as if you are only allowed to fork it into other GitHub repos.
Whether copying to your local machine or running are allowed will depend on what “use through the GitHub Service” and “perform through the GitHub Service” mean.
Would also depend on how exactly GitHub (or a court) would interpret "forking", as an argument could be made that a GitHub fork is just a "GitHub Create" + "Git Clone" operation, and having permission to do a "GitHub Fork" means you're also allowed to do a "Git Clone".
I guess we'll never know, as a case like this would never reach court so it's guesses all around.