There have been lots of such languages that transpiled to JavaScript or worked on the JVM, adding nicer syntax and features. Many of them went nowhere, but quite a few of them did get widely adopted. Off the top of my head, CoffeeScript was also relatively popular for a while, and Clojure builds on top of both ecosystems, Scala comes to mind too.

Go might be in a similar situation right now, where it has become entrenched in certain domains (like DevOps), and lots of people are not entirely satisfied with it but they can't to switch to something else. Is Go getting a similarly bad reputation as JavaScript or Java to push this through? Is the lock-in as strong as in browsers or Android? No, I wouldn't say it's there yet, but still, it is worth a shot to try to build such an alternative language.

I do agree that Borgo will probably not be adopted widely, the pains it addresses are not strong enough and the language does not seem to be properly maintained and supported. But history shows it is not as unlikely as you suggest.

To have every class be final by default and hidden from callers might be sane for shipping a library—-but you definitely should not adopt it as internal policy in your own code base, for your own’s sake. Why should I tax myself with having to worry about calling out extensibility by hand at every step? This is just crazy to me!

I’m all for Kotlin’s success as we desperately need something better than Java still. I’m rooting for you.

The lock-in with Go is the massive copy-pasta style and throw-away code mindset that is pretty much all that I see. But there is very little good Go code out in the wild to show us how it’s done.

JetBrains and Android manage to ship Kotlin software.

Unfortunately software architecture isn't part of most bookcamps, or many devs that rather code away.

You think you thought of the proper public API that your software modules should have? Especially your internal software? Of course you didn’t think of it all ahead of time. It’s a software architecture concept called “open for extension”, look it up.

JetBrains doesn’t ship anything with deadlines or that must always stay on. Users can always downgrade the IDE. The number of times I’ve been to turn off the latest feature and try again (to see if the IDE still crashes) is ridiculous. Number of times my build stayed stable after a major IntelliJ Idea upgrade? 50% success rate. I’m rolling the dice on every upgrade. Please let’s talk about shipping software with consequences.

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.

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, ever. This may be harsh, but I won't consider a language until it reaches at least #50 in popularity, and frankly until someone is paid to work on the tooling full time. Hobbyists like solving interesting problems such as designing the language and building the compiler, but don't particularly enjoy a lot of "gruntwork" that is critical - writing a comprehensive test suite, a fuzzer for the compiler, an LSP/IDE/editor plugins, a good standard library...

There have been a lot of promising one-man projects such as this one, that get abandoned when the lead developer moves on. You don't want to be stuck holding the bag with a large codebase in a zero user language.

https://survey.stackoverflow.co/2024/technology#most-popular...

The most important factor for a language is Big Tech backing. Little squabbles on syntax or language features or philosophies are entirely secondary.

    Community > Company

I love this, even though I don't interact with Go on a regular basis, but I recognise that I'd be locking myself out of a lot of the standard Go tooling if I adopted this wholesale. For better or for worse, there's a high ecosystem barrier that most languages must overcome to be adopted, and the vast majority of efforts never get to that.

I suppose there must be some borgofmt that handles the particular syntax. Certainly debuggers would have to be updated to show the corresponding Borgo code line at least.

What else?

Any and all linters for Go, to start. In theory, you could run them on the transpiled source, but the results would be very hard to apply to the original Borgo code. And they'd probably produce lots of false positives for things that the Borgo compile ensures are safe, even if they're not linting-correct.

And syntax highlighting, refactoring tools, an LSP server. I'm sure there are more things along these lines I'm failing to think of.

It’d be even more useful with a Rust/Borgo interop layer but I bet that’d be really complicated.

I like languages that can be compiled, I like modern type systems. Rust is neat but my occasional dabbling hasn’t yielded much productivity. Go has too many icky bits.

Borgo? I will definitely be trying it out!!

The creators of Go have also built the foundation of everything you take for granted. The real "harsh truth" here, of course, is that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry, such that the likes of Rust "death by committee" people may only dream of. The long-lasting obsession that Rust people have with Go and the Go team has become a meme.

Borgo is the recognition of that: a handout to Rust people that they will never appreciate.

[1]: https://www.rust-lang.org/policies/code-of-conduct

Higher order functions often seems to be a way to complicate otherwise easy to read code. Kotlin manages to do it reasonably well, in Javascript I has beem behind some of my absolutely worst debugging experiences.

The problem with Go, as far as I have seen is not about functional programming, but rather about things like making a point out of not supporting generics for years.

For anyone who has experienced the Java 1.4 to Java 5 transition, and all the cruft it removed I cannot see how any of them can willingly accept a language that made a point out of being clumsy so one had to do it the old clumsy way agaim.

Or how a language that us supposedly a good fit for web backends had (don't know if it have now, I've given up) no simple way in the standard library or any popular templating solution to say in a template that it should be included in a bigger template, thereby forcing the code to know about things that belong in the design world.

I.e. to have

- a common header with dynamic title

- a dynamic part between

- and common footer

the correct way last I checked seemed to be to string them together like a php script from the late nineties.

Is it the foundation because it was built a long time ago, and is "good enough" .. or because it's just really good? "Worse is better" comes to mind.

There was another post on hn today about "pipelines getting stuck" that was really just about poor interaction between pipelines and programs changing their buffering behavior based on `istty()`. bash has been around a long time, and will stay around for a long time still, but that doesn't mean its design leaves nothing to be desired. It just means the benefits of changing it haven't crossed the 10x threshold of the costs (partially because it's foundational).

Had UNIX been a commercial product from the get go, and most likely C wouldn't have taken off as it did.

Those geniuses fought against implementing generics for almost 10 years.

It's lists, and maps.

> The generics in Go have turned out dogshite

Pick one.

This is dogshite because I have to fork a bunch of stuff to actually use it!

It addresses complaints 1 to n but does nothing about complaint 0: Having a garbage collector with all its associated downsides.

I think Borgo sits at an interesting place in the design space. I just believe there are vast plains of unsettled land in the strongly typed GC-less direction and a language that really addressed all complaints about Go would have live there.

And by that I don't mean using Rc<> everywhere nor do I even mean making a GC library and then using GC<> everywhere. I mean having the runtime handle all memory things with you having to think about it only when some extremely rare corner case breaks.

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.

https://learn.microsoft.com/en-us/dotnet/standard/memory-and...

It's worse at dealing with ref structs so C# is better for some low-level tasks. But it has other niceties like IL-level function and lambda inlining.

Tho point of Rust is to be safe language without GC. Even if not perfect, best thing about Rust is borrow checker and border between safe/unsafe. You can use several other languages, like Ocaml, if you want Rust with GC.

I don't even mind[0], I think it's actually kind of amazing.

[0] I have all the usual complaints about build systems and about the node ecosystem in general, but I don't think the fact that it's javascript compiled to javascript in and of itself is a problem, only, well, almost everything about how that's usually implemented/achieved :D

OTOH I haven't seen a pure JavaScript project for a number of years. It's all Typescript now, maybe with some vestiges of legacy JS slated for eventual migration to TS.

Much, not so much.

I see JSX as basically 'compiling augmented javascript to javascript,' much of decorators is much like that as well, and things like e.g. vue's turning expressions on its reactivity based signals seen in templates into something more clever is also in the category I was trying to gesture at.

(TS is awesome but I should've predeclared that it wasn't really what I had in mind, sorry for any confusion induced by that mistake on my part)

That's partially the cost, but the other cost is building this into existing tool chains and deployment mechanisms. Getting buyin from teams, ensuring _everyone_ learns the syntax.

And the unstated fear: The code it generates, is it actually good? Am I going to have silly issues down the road that are hard to debug and require diving into generated code to see some concurrency issue?

One is better off wasting brain cycles contributing to C#, Java, Kotlin, Swift, Scala, D,.... where a language being feature rich is appreciated by the community.

Hence better invest into ecosytems that value language design PhDs....

There is even the JVM Languages Summit.

Unthinkable in Go ecosystem.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”

-- Rob Pike

Sounds pretty damning, I'd say. This of course illustrates why Go is called "systems PHP".

> how much one was willing to pay for a commercial JDK.

I strongly prefer open-source tools at the base of my stack. Not as much because of the money but more because of the level of trust. Things should be inspectable.

- .Net devs (they are almost as annoying as us Java/Kotlin devs)

- a language and ecosystem that consistently sacrifice backwards compatibility (contrary to us who have features sacrificed for backwards compatibility at every single step)

- you have to live without the JVM ecosystem (on this I have no self deprecating comment, C# is a better language, but the ecosystem, from libraries to build system to IDEs is something I always miss when I work in .Net.)

.NET maintains excellent backwards compatibility, C# and F# even more so. The changes either affect frameworks and libraries, which you can often update independently or are easily addressed. Most projects since .NET 5 only ever had to bump the target version and rebuild to move forward (notable exception: in .NET 6 ASP.NET Core introduced simplified API for application setup which required changes).

Neither JVM nor Go have the degree of low-level capabilities .NET provides first-class support for. And F# integrates in an easier way into existing C# solutions than Kotlin does into Java ones.

It is the GC-based Rust alternative many are looking for but are overlooking due to bias from the past.

It is my feeling that .Net developers with some years of experience get wide eyed when I tell them how I can use any old library that I need together with the newest JVM and my platform upgrades have mostly consisted of bumping numbers.

It's nothing surprising in .NET land. If you target netstandard2.0 the library will work on any version from .NET Framework 4.6.1 and upwards. For many newer features there are compat and polyfill pacakges too - that's one of the strengths to be able to use them even on the older targets.

All newer targets are forward compatible anyway. Wherever the notion of otherwise comes from it is likely a misunderstanding or trolling.

You can't make a serious argument when comparing baseline experience where .NET confidently places next to Cargo and Golang's user experience with the level of productivity it provides for setting up and managing projects and dependencies, building them and distributing them. JVM ecosystem still does not offer capability to properly and easily package the applications into a single binary except using very restrictive GraalVMs Native Image which does not have as wide ecosystem support as NativeAOT enjoys, and where it does not work .NET still gives you the ability to bundle managed assemblies into an executable together with runtime, apply trimming and get relatively compact result.

I think you should read up on the guidelines before abusing the flagging system as a way to punish someone you disagree with.

Anyway, I am out of here.

Yes there are AOT friendly frameworks, however JVM agents have also provided a way to gather the necessary data for a AOT compilation, since the Exelcisor JET days.

Including Microsoft own products.

So I would slow down on the whole Java versus .NET flamewars, regarding who's more competent.

I use both ecosystems, because both have plus and minus, and complement themselves.

Is this what is so damning about Go? The constant reposting of this quote as some sort of attack on Go's validity and reputation reeks of nothing but classism.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”

-- Rob Pike

That's just not what he said or implied.

It's not a perfect language, but it's a pretty good language for building shit and shipping stuff.

And it starts getting to you, because a lot of problems just don't have nice solutions in the language because of its limitations. So you start accumulating kludges, which lowers the bar for quality in the entire code base.

There are PLENTY of techniques and abstractions that are VERY useful yet not expressible in a sane way in Go.

It's a nice enough language for beginners, but acting like it's the end all of programming just makes you look like a fool.

"incapable" != "never capable", especially when talking about fresh college graduates.

Mr. Pike's quotation assumes that the Googlers should not be expected to be too intellectually capable. That's the damning part for me.

The fact that none of these highly accomplished individuals want anything FP-related in Go says far more than what typical Go-haters want to think it does.

Does it?

I'm not a Go hater but just because they were involved in making the things you listed doesn't mean they would do it again with Go. It just means they don't trust others with different languages.

I don't think what you said refutes people's perception of Go, which is its a fairly limited language that is good for keeping people on rails (like fresh grads). That might make sense for a large business hiring lots of people but maybe not for small companies.

Also there is a world of difference between FP features and the basic features people asked for in Go (like generics).

Or that Robert Griesemer literally is a language PhD, whose thesis was supervised by a little fellow by the name of “Niklaus Wirth”?

https://www.research-collection.ethz.ch/handle/20.500.11850/...

Syntax squiggles are not very important, but other language features, like a good design and removing whole classes of bugs, are.

If Andrew Kelly were kidnapped by aliens tomorrow, Zig would continue. I think that's the dividing point, when the bus factor is no longer one.

Elm, sadly, never achieved that. But I don't see why Borgo would necessarily follow the way of Elm and not of Zig or PHP.

Thankfully I've been able to scramble some syntax highlighting support and reverse engineer how to start and run it, and after a while it actually kind of makes sense.

But I am an engineer, not an artist, and elm code will not survive me in the code base if I can avoid it (unless there are teams of Elm programmers at a place).

Elm might remove classes of bugs, but when there is not a single developer except me who manages to wrestle with it, though luck. TypeScript also removes entire classes of bugs, and it does so while being well documented and easy to understand for devs from other mainstream languages so the other devs won't come running my way everytime they have to fix something written in it.

Technically not dead, rather stagnant, a difference that hardly matters regarding adoption and ecosystem future.

Some people don’t like Go but have no reason (or something compelling them) to use it. So they use other languages. They don’t need a new source-to-source compiler. Your point is moot for this group.

But some people might have to use it. So this language is at least relevant to them. If indeed it addresses all of the complaints. But that might be hard for a language which only compiles to that other language to do.

Borgo?

Cannot think about much languages that haven't any bigger company behind it. PHP maybe? To an extend Python? But today Python good pushed by the big companies of the AI hype.

Employeer vibes matter.

If you worked in a career where you needed a glue language, then you were at the very least aware that Python existed.

>Cannot think about much languages that haven't any bigger company behind it.

Ruby.

Just because it's compatible with Go doesn't mean that 3rd party Go dependencies will be a natural fit for it.

Existing IDEs and other tooling won't work.

Community is unlikely to grow.

etc

1. People who want Rust will just use Rust. You can keep your Rust code simple if you want, most of the time. I think most people that object to Go's issues have moved on from Go by now. Kind of like how safe C++ has no chance because most of the people that get it have left C++ already.

2. It's clearly not mature. Not many people jump on one man languages. If this was backed by a large company I suspect the story would be different.

Still, it seems to be tastefully designed. Might have a chance I guess.

The people who use Go despite its issues are using it because of the tiling and the massive Google backing. Neither of which this has. Someone who wants a language that implements some of the good ideas of the 1970s and is willing to leave Go for that already has many established options.

Go+[1](goplus), around since 2020, is already an "extra features" version of Go, that compiles into Go

> It has immutability. It has advanced enums. It has algebraic types. > It literally addresses every major complaint people have with Go

V[2](vlang) is a Go alternative language that has such features. It was originally given the title of child of Rust and Go[3]. On top of that, even has a Go2V transpiler available.

Speaking of Go alternatives, Odin[4] is not too far away as well, and has recently taken the position of labeling itself as an alternative to Go.

> if only it had this X advanced feature, it would be totally great

Not only are these languages labeled as Go alternatives (Go+, Vlang, and Odin), but they have a significant number of fans, more GitHub stars, and/or a large numbers of contributors.

It could be argued that the field is already kind of crowded. If we squint a little, several other languages could have been added to the list (like C3 and Jai), as alternatives.

[1]: https://goplus.org/

[2]: https://vlang.io

[3]: https://www.youtube.com/watch?v=puy77WfM1Tg (Is VLang Better Than Go And Rust? --Anthony GG)

[4]: https://odin-lang.org/