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

141–150 of 204 posts

Re: The Borgo Programming Language

#141

Post by trehalose »

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.

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

Re: The Borgo Programming Language

#144

Post by alfiedotwtf »

foooorsyth wrote: post #63
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…

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
In fact, after what Sun/Oracle did to Java, people should be skeptical if a language was not community run

Re: The Borgo Programming Language

#145

Post by rkerno »

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.

Re: The Borgo Programming Language

#146

Post by alfiedotwtf »

tucnak wrote: post #12
kjksf wrote: post #6

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

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

Re: The Borgo Programming Language

#147

Post by alfiedotwtf »

etse wrote: post #113
timeon wrote: post #54

Earlier quoted context omitted.

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.

Re: The Borgo Programming Language

#148

Post by yearolinuxdsktp »

oersted wrote: post #15
kjksf wrote: post #6

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

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

Re: The Borgo Programming Language

#149

Post by jitl »

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 native Go syntax for things like import (here replaced with "use") and adding methods, here replaced with "impl ..."

Re: The Borgo Programming Language

#150

Post by jitl »

atombender wrote: post #109
nmilo wrote: post #77

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

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 - 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.
Post reply on HN