Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Borgo Programming Language

borgo-lang.github.io

Post reply on HN
Print view View original

151–160 of 204 posts

Re: The Borgo Programming Language

#151

Post by codr7 »

desumeku wrote: post #138
codr7 wrote: post #129

Earlier quoted context omitted.

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.

And part of that specific purpose was to prevent lesser developers from making a mess, like it or not.

Re: The Borgo Programming Language

#152

Post by pjmlp »

riwsky wrote: post #130
pjmlp wrote: post #89

Earlier quoted context omitted.

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.

Re: The Borgo Programming Language

#153

Post by pjmlp »

neonsunset wrote: post #116
skinkestek wrote: post #114

Earlier quoted context omitted.

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 b…

“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 applica…

The millions of us stuck on .NET Framework projects would disagree with that excelence in backwards compatibility.

Including Microsoft own products.

Re: The Borgo Programming Language

#154

Post by tucnak »

alfiedotwtf wrote: post #146
tucnak wrote: post #12

Earlier quoted context omitted.

> 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 be…

> 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.

Re: The Borgo Programming Language

#155

Post by tmountain »

yearolinuxdsktp wrote: post #148
oersted wrote: post #15

Earlier quoted context omitted.

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 bo…

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 hid…

The standard library is good, readable, and probably the best example of how to write Go code.

Re: The Borgo Programming Language

#156

Post by alexvitkov »

nine_k wrote: post #82
alexvitkov wrote: post #25

Earlier quoted context omitted.

> 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…

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.

Re: The Borgo Programming Language

#157

Post by nulld3v »

mst wrote: post #43
nulld3v wrote: post #31

Earlier quoted context omitted.

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 tra…

> 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,…

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!

Re: The Borgo Programming Language

#158

Post by LinXitoW »

tucnak wrote: post #154
alfiedotwtf wrote: post #146

Earlier quoted context omitted.

> 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.

Re: The Borgo Programming Language

#159

Post by rkerno »

jitl wrote: post #149
rkerno wrote: post #145

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 n…

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.

Re: The Borgo Programming Language

#160

Post by hnlmorg »

jitl wrote: post #149
rkerno wrote: post #145

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 n…

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.

Post reply on HN