hckrnws
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.
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.
Yes, many of us don't believe on monkey patching.
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 are deluded or trolling calling it monkey patching. Dynamically overriding a public method definition is monkey patching. Extending a public class and overriding some public or protected method is not monkey patching, you are crazy if you think it is.
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 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.
I tend to start off a project with typeless zero-build JS, because I've been working with dynamic languages so long that the types mostly don't actually help me find bugs in the early days, but if I don't convert it to reasonably typed TS before I release a 0.001.001 then I would expect people to judge me for it, and I would consider them to have every right to do so.
Much of it is such minimal translation.
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)
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?
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.
"tiling"? what do you mean by that?
Tooling, sorry, was on my phone.
> 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.
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.
> 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:
Community > Company
How 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.
Zig has been around for 9 years, and it looks like 1.0 is not even in the cards. Seeing a lot of flux, with lots of unresolved issues (per its GitHub).
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.
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?
I think your recollection of Python is a bit off. Python wasn't really obscure or developed in silence. If you needed a glue language for a unix system, then there were really only three choices: Perl 5, TCL/tk, and Python.
If you worked in a career where you needed a glue language, then you were at the very least aware that Python existed.
Python got a massive push from Google too. At one point (Early 2000s?) they were hiring a ton of python developers.
What kicked Python on 2000's was Zope, everyone was into Zope, like Rails almost a decade later.
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.
Note that the same individuals weren't that lucky with Plan 9, Inferno and Limbo, or Oberon.
Employeer vibes matter.
I think that's the point.
Google and Academia pushed Python in the 00s.
>Cannot think about much languages that haven't any bigger company behind it.
Ruby.
> 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."
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.
Especially taking into account the decade of systems languages predating that feat, and everything else happening outside Bell Labs.
Had UNIX been a commercial product from the get go, and most likely C wouldn't have taken off as it did.
> 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.
Static typing prevents reusing functions unless they're generic. The other option is to give up static typing and pass "all" everywhere, like a dynamic language.
Self imposed fault, by ignoring computing history since 1976.
> that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry
> The generics in Go have turned out dogshite
Pick one.
I guess it's fine for what it enables, Tree[T] of some kind basically. But we had that with codegen already.. People who really needed trees, could do that forever. However, the issue is the "unwashed"—like they said in adjacent comment—putting them everywhere now, where an interface would be more fitting. Hopefully I'm explaining in terms that you can comprehend.
This is dogshite because I have to fork a bunch of stuff to actually use it!
I used go for about 3 years, so yeah I understand... but I can't believe you actually like copy-paste/codegen more than actual native language facilities. Mind blowing to be honest.
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....
No, it's a way of writing a better language while using Go libraries extensively. The same way Kotlin is a way of writing a better language while using Java libraries extensively.
The difference is that JVM community welcomes languages PhD folks.
There is even the JVM Languages Summit.
Unthinkable in Go ecosystem.
Are we just ignoring when they invited Philip “Featherweight Java” Wadler to help them design Go generics? https://arxiv.org/abs/2005.11710
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/...
No, but that isn't what Rob Pike meant, that was the Go design team accepting they alone weren't capable to implement generics in Go, without help from those PhD folks.
Maybe because Go is not a VM?
Java compiles to native code for two decades now, it has always been a matter of how much one was willing to pay for a commercial JDK.
“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
> our programmers are Googlers ... They’re not capable of understanding a brilliant language
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.
That's what .NET is for (both C# and F#) - it has no private implementations (Unity does not count :P). Much more competent compiler too and smaller native binaries. Something you could confidently use in production.
.NET still doesn't have any real time GC, zero pauses GC, bare metal implementations, cloud JIT, a compiler development framework, has lost the mobile OS wars.
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.
Then you have to deal with:
- .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.)
“Contrary to us”? I can’t agree with this attitude.
.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.
The millions of us stuck on .NET Framework projects would disagree with that excelence in backwards compatibility.
Including Microsoft own products.
Yes, I'm talking about the platform, not the syntax.
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.
I don't know which developers you talked to. Honestly I should just flag this reply probably.
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.
Contrary to Native AOT, Java tools have always found a way to deal with reflection, instead of asking the ecosystem to rewrite their libraries.
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.
> I don't know which developers you talked to. Honestly I should just flag this reply probably.
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.
"We hire working-class college graduates from the normal population, and not ivy league graduates who have the time to waste on unproductive academic research languages that see no industrial use."
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.
Google is famous for tough interviews and accepting a small fraction of applicants. I was impressed with everyone I met, and Pike's "incapable" statement was baseless and insulting.
> Pike's "incapable" statement was baseless and insulting.
"incapable" != "never capable", especially when talking about fresh college graduates.
"Unwilling", "have no time", "can't be bothered" are all better than "incapable".
Googlers used to think about themselves as of elite engineers, having passed a very stringent and demanding interview process.
Mr. Pike's quotation assumes that the Googlers should not be expected to be too intellectually capable. That's the damning part for me.
Intellectually capable to do what? Orchestrate some of the largest distributed network systems in the world? I bet you all the best functional programmers wouldn't be able to create something as big as Google if you got them in a room together. Nor would they be able to create anything as important as UNIX, like one of Go's creators did. Nor UTF-8. Nor the JVM HotSpot machine. I could go on. What have you done that Ken Thompson couldn't?
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.
> 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).
The complaint is that it was designed for lesser brains and lacks many features professionals expect, and that's pretty much an objective truth.
This is a horrifically obtuse and offensive comment just because Go isn't Lisp-y or Haskell-y enough for you. Golang powers large swathes of distributed services and systems all over the world whether you like it or not, because it was designed with a very specific purpose in mind by people far more professional and accomplished than you ever will be.
I think that comment might actually have been because of this quote from one of Go's creators, which was posted further up in the thread:
“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
It's a huge and dishonest leap to jump from "our programmers are Googlers, not researchers." to "Rob Pike admitted anyone who uses Go is stupid and if they were smart they would be using Scheme instead."
That's just not what he said or implied.
And part of that specific purpose was to prevent lesser developers from making a mess, like it or not.
And the problem with that is? Honestly, the more experienced a developer is, the more their code naturally seems to look like what Go shepherds you towards.
It's not a perfect language, but it's a pretty good language for building shit and shipping stuff.
I've written a ton of Go, for fun and professionally.
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.
There is no such thing as the sufficiently smart developer.
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.
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'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.
And now Elm is gone, as its author failed to capitalise on it, to the point of having a talk about lack of funding in FOSS.
Technically not dead, rather stagnant, a difference that hardly matters regarding adoption and ecosystem future.
Along with Elm, another long time one-man show of significance (per GitHub and Wikipedia) is Seed7.
Is it mature? The project is a bit more than a year old and describes itself as "new"
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!!
> 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.
[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)
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
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.
Comment was deleted :(
I'll use it... for a hobby project! :-D
"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.
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'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.
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
D would fit in as well, if the community wasn't so tiny.
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.
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’m curious which are the well known projects or products that have ported or converted away from Go. Anyone have a shortlist?
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.
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.
Nim, but whether the syntax is modern is questionable.
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.
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.
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?
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.
+1 on the license.
What would be the point of compiling to Rust? Just use Rust in that case.
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.
There’s no license which makes a copyrighted work. This is just a performance without a license that permits usage of the language.
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)
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.
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.
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.
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.
I've been very hungry for a solution to golang's unsafe nil pointers, something as elegant as what dart lang got.
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?
Sounds interesting. Shame the entire linked site assumes you know Go and describes Borgo only in terms of deltas from Go. That essentially means I and anyone else unfamiliar with Go will learn nothing from the site and dismiss the language.
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'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!
Right, even the most opinionated of modern formatters don't go quite that far.
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
> 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)
This is almost what editing Java in IntelliJ is like. The most verbose multi line constructs are minified to only appear as one line on your screen.
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 :)
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.
this is basically what Go should have been!
The first thing I do when I hear of a new PL is to look at its bug tracker.
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.
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.
Discovered this at work and it's amazing. Between Gleam and Borgo, I don't know which one to use for the advent of code this year!
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 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?
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.
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)
Higher level easily end up more domain specific. Think SQL or other query languages. Future ones will likely be designed around AI somehow.
Eventually AI systems will be able to generate executables directly.
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.
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 ?
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.
Go provides excellent packaging, and runtime with good gc and goroutines. Those are some of the biggest investments to be made for a language.
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.
I’m wondering how idiomatic the generated Go code is. Would it be useful for generating code in a Go library?
That curve is generous in the amount of type safety it distributes.
While it looks interesting but what is the story for debugging?
Well done, looks almost enjoyable, a huge step up from Go.
Did someone finally fix/complete go?
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?
the syntax is clean ngl
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]
Comment was deleted :(
[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.
Crafted by Rajat
Source Code