I love it.
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.
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.
What prevents this from being a superset?
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.
>What prevents this from being a superset?
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 it would be cool if we had something like this except as a superset.
Is this TypeScript of Go?
The graph and syntax, individually, inform the answer succinctly. No.
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.
the syntax is clean ngl
Almost the perfect language. I don't get why it's they didn't make it compatible with normal Go. It should have been like Typescript where you can compile plain Go, it just adds features on top it. The "let" and struct changes are totally unnecessary. Then you can interop with existing libraries and convert large Go projects to this incrementally.
Interop would force the language to keep certain core features, like nil pointers and zero values, that in Borgo are presumably considered anti-features.
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.
The easy way to deal with this is to just treat any pointer coming from regular Go that isn't annotated as //@NotNull or something as an Option<*T> - no need to ask the user to do the conversion, the compiler can just handle this. You don't even need a different representation -- just keep the type as the pointer in compiled Go. The user will still need to do the nil check, but the compiler is enforcing it, and you can use `?` or another macro to propagate the null. It's the same with Typescript as you say, if there's some library and you're not sure if `function getThingy()` will always return `Thingy`, you can declare the type as `Thingy | undefined`; potentially you check the return value right away or you just propagate it and it's totally fine.
The original ShowHN https://news.ycombinator.com/item?id=36847594
See also https://news.ycombinator.com/item?id=40211891, which has the bulk of HN discussion about Borgo
Thanks! Macroexpanded:
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)
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.
There’s no license which makes a copyrighted work. This is just a performance without a license that permits usage of the language.
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.
I've no idea how to quantify such things.
I do know that adding C to that graph would require changing the Y axis to a logarithmic scale.
If you're targeting Go to cross-compile to, why would you build the language in Rust? Keeping to the go tool chain would reduce a lot of friction for those who are using go already, which I presume is a significant chunk of your target audience.
I don't work on the language, but I think building a compiler in Go (or C) is a pain in the ass compared to using a language that has discriminated union types, and based on the aesthetics of the language, the authors probably agree with me. The language is styled enough like Rust to make it seem like this is for "rust people" more than "Go people" anyways – I think if this was targeting Go people, it would use the native Go syntax for things like import (here replaced with "use") and adding methods, here replaced with "impl ..."
There might be an audience for disillusioned rust people who get bored with fighting the borrow checker etc, but true rust developers, like c++ devs want control and won't want to hand that to go's runtime.
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
true rust developers will program with magnetic needle
I’ve written a compiler in Go. The language is fine for doing that kind of development.
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.
Looks similar to Haxe (and to the language that C++/Java/Python/TypeScript/etc are converging).
Now give it to google, release it as .go2, and make it frictionless to use Go and Go2 in a codebase.
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.
They've bought and kept running many projects. YouTube, Writely (now google docs), Android to name a few.
Webkit.
This is great. I would love to see an implementation of exceptional flow control for error handling. Do I really have to copy paste all my error-check throws on every refactor, on every method extraction? Halp, expressive language savior?
This is cool! I won’t be using it in production but this will definitely be (one of) my advent of code languages for 2024 :)
I hate semicolons. They are such visual garbage, and mental overhead for having to type them. Many languages are successful without them. Good on you for ditching them.
That's very close to what I want, I wonder if we'd ever have customization for programming languages on the client side but when pushing to git it would get transpiled to the most common subset. A small change I would have loved at first glance would be the double colons (::) for namespace path along with explicit extraction and pub for public types.
I have this same dream wayyy too often (uunfortunately).
- 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.
> Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code.
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)
That is a really intriguing idea! Not sure if Go has exactly the sort of tool you are talking about, `go fmt` still allows for some minor differences, and I believe the same applies to `gofumpt` as well.
But it still sounds totally doable!
> but when pushing to git it would get transpiled to the most common subset.
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.
I was assuming that each contributor would have their custom rules on what the code looks in their editors. I agree that we should have a different solution so everyone reads the exact code they wrote in the style and format they wrote it...; Scratch all that, the more I think about it that sounds like a very bad idea, what about pair programming, collaboration, being able to talk about some parts of the code or it's design? Back to Go and Rust for me :)
> when pushing to git it would get transpiled to the most common subset.
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)
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.
This looks neat, but I think requiring declaration files makes interop with Go code tedious enough that nobody will bother (along with all the usual maturity arguments). I'd prefer it if this was using the Go compiler as a library to get all necessary information automatically, or if it was a straight up fork of Go.
this is basically what Go should have been!
Might I suggest a purple logo, since its half Go (blue) and half rust (reddish). Lol
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.
Feels like this is something I could learn before moving trying Rust properly for the second time. What do Rust developers here think about that ?
I wonder if there will ever be another programming language on top of the most high level languages we currently have (like to python what python was for C)
The first thing I do when I hear of a new PL is to look at its bug tracker.
I’m wondering how idiomatic the generated Go code is. Would it be useful for generating code in a Go library?
Go deserves to get TypeScripted. Another effort in this vein is Go+
How do you figure this. Javascript got TypeScripted because it was forced on us by browsers.
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.
Well done, looks almost enjoyable, a huge step up from Go.
This is freaking awesome. Golang is an amazing language and runtime for application development. But the language does show its heritage insofar that it lacks many niceties that languages like Rust have.
I will certainly try this out in my next personal project.
That curve is generous in the amount of type safety it distributes.
Did someone finally fix/complete go?
While it looks interesting but what is the story for debugging?
How does it compare to OCaml?
How come on HN the comments which are tangential to the main topic always get voted to the top?
Note that the compiler is not open source.
Even worse than that, it has no license at all. It cannot legally be used.
> It cannot legally be used.
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...
Corrections welcome, but I don’t think the right to view and fork code gives you the right to run it.
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.
Yeah, true, thanks for expanding the context.
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.
That doesn't make it open source, just "source available".
Yeah, but "view and fork" does not imply "compile and run", unfortunately.
[dead]
[dead]
[flagged]
The nerve, creating a new language when you have already discovered Clojure!
Ya kind of, the nerve of creating a non lisp dialect :D
Let's be substantive : What makes Borgo junk? Can you seriously see nothing interesting here compared to Clojure?
For example, having the equal to (=), to assign variable is junk. I am sorry if people can't understand what I say.
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.
The standard library is good, readable, and probably the best example of how to write Go code.
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
But it's the minimal translation to allow newer language features and APIs to be still used in older browsers.
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.
There are people who insist on writing JS (with types in JSDoc), but Svelte is the only such project I can name off the top of my head.
> 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.
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.
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.
What else?
> 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.
IDEs, profilers, instrumentation agents, code coverage tools... essentially any tooling really.
> 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?
> 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.
> 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.
Top 50 is incredibly generous. I wouldn’t use anything outside of the top ~20 for anything I’d be getting paid to produce.
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.
I would say:
In fact, after what Sun/Oracle did to Java, people should be skeptical if a language was not community runHow does Zig look from where you sit?
They keep changing the syntax and they've pulled out major features out of the language, that's a non-starter for me.
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.
In my mind the fact that Go has Google behind it is the main reason it caught on (and quickly). It would have been completely ignored otherwise.
That + the individuals involved. Without the company backing + different (not already-"famous" [programmer famous]) people involved, it would have been completely ignored.
I think that's the point.
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.
Python also fits its design space amazingly well (that's what's meant by "Guido's time machine"). It's a glue language, with a REPL, but it's not a shell (i.e. it's not meant to glue programs primarily through stdin/stdout/argv, but instead libraries through their APIs). It was a very useful (Greenspun's tenth rule) and somewhat underserved niche (perl, scheme and tcl come to mind).
I know this is a really late reply, but your comment says ‘[i]t was a …’. Was that just an odd choice of tense or are you arguing that Python is no longer useful for its niche? If so, and I’m genuinely asking, is there a replacement for the glue language aspect that retains Pythons wide standard library approach?
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.
It's not trying to fix Go, it's trying to be a new programming language. It just happens to compile to Go, and allows Go interop.
Which is a way to use Go, while not using Go.
Hence better invest into ecosytems that value language design PhDs....
The difference is that JVM community welcomes languages PhD folks.
There is even the JVM Languages Summit.
Unthinkable in Go ecosystem.
Is it mature? The project is a bit more than a year old and describes itself as "new"
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've had to deal with Elm alone (the original devs had left, leaving next to no docs, because who needs docs with such a beautiful language I guess).
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.
That it enjoyed some popularity doesn’t mean it was the right choice. Teams who adopted it were, in all likelihood, betting that it would see wider adoption—and if they’d known how Elm (vs, say, TypeScript) ended up by 2024, they probably wouldn’t have gone down that path in the first place.
Zig is a BDFL language, but it's far from a one-man language. There's a Zig Foundation with several full-time paid contributors, with a larger design team who collaborate on the big picture.
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.
Exactly my point: Zig managed to pass from a one-man-show stage to a more mature, more established stage. Same happened much earlier with PHP and Perl.
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.
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.
That’s me!
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!!
Who are you talking to?
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.
> made by morons for morons
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().
> 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
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.
For a community supposedly "committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience"[1] Rust activists perhaps unsurprisingly lack in tolerance, empathy, and awareness. The community has changed, too. I liked them more circa ~2015 from before the corpos caught on to "the most loved" language, and have since blown evangelists' expectations for future adoption way out of proportion. As long as the drawn-out vendetta lead by Rust activists contra Go is concerned, old proverb comes to mind: "Hating popular things does not make you interesting."
[1]: https://www.rust-lang.org/policies/code-of-conduct
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.
> that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry
Those geniuses fought against implementing generics for almost 10 years.
And they were right. The generics in Go have turned out dogshite... I try to avoid them at all costs because besides simple data structures like Trees and so on, they're just more trouble. Go was not meant to have generics.
It literally had generics from the very first day. They were just gate kept from the "smelly, lowest common denominator code monkey morons", because noone could match the genius of their creators, or ever have the same issues to solve as the creators (because their little brains are too tiny).
It's lists, and maps.
The issues with language adoption come down to tooling, libraries, and community.
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
"It literally addresses every major complaint people have with Go."
It addresses complaints 1 to n but does nothing about complaint 0: Having a garbage collector with all its associated downsides.
If it skipped the GC wouldn't it just be Rust?
Valid question, but no. Borgo takes inspiration from Rust but is still a vastly different language. Even though it has algebraic data types its type system is not Rust's. Another big difference is that it sticks with Go's interfaces instead of traits.
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.
Rust with GC is actually what many people want.
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.
That sounds like C#?
https://learn.microsoft.com/en-us/dotnet/standard/memory-and...
I have been a huge (but lonely) proponent of C# and rust being the best two-language combo. But once (someday! Soon they say!) first-class discriminated union support lands, it’ll be the ideal recommendation for anyone that wants to get away from manually taking care of lifetimes.
You are correct, C# straddles that line better than any other language right now imo thanks to the APIs you linked. There was a good write up about this Rust vs C# Span comparison on HN a few weeks ago but the link escapes me
C# was derided as "Microsoft's Java" from the beginning, even though it pulled ahead very early on with generics and never looked back. Microsoft was loathed by many for a long time. Go is popular because Google is (was?) loved/admired.
I'm finding F# to be even closer because it has HM type inference, discriminated unions (note they are not as layout-efficient as Rust's, it is better in F# 9 though), is fully expression oriented and overall a quite terse language (Rust isn't really terse but can be made so in some cases).
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.
Rust with GC wouldn't look much like rust anymore.
I think people want is Rust, but simpler. At least by default.
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.
When companies move from Go it is usually because of GC.
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 have seen a lot of large projects do this but don’t keep a list. The ones that remember from recently reading about them is Discord and IndexedDB.