11 ms·

The Borgo Programming Language

361 points by MrBuddyCasino 2y ago

brudgers 2y ago
The original ShowHN https://news.ycombinator.com/item?id=36847594 https://news.ycombinator.com/item?id=36847594
- Philpax 2y ago
  See also https://news.ycombinator.com/item?id=40211891 https://news.ycombinator.com/item?id=40211891, which has the bulk of HN discussion about Borgo
  - dang 2y ago
    Thanks! Macroexpanded: Borgo is a statically typed language that compiles to Go - https://news.ycombinator.com/item?id=40211891 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 https://news.ycombinator.com/item?id=36847594 - July 2023 (8 comments)
blixt 2y ago
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.
- howenterprisey 2y ago
  I think it would be cool if we had something like this except as a superset.
  - bmacho 2y ago
    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?
- miohtama 2y ago
  Is this TypeScript of Go?
  - Supermancho 2y ago
    The graph and syntax, individually, inform the answer succinctly. No.
- nine_k 2y ago
  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.
  - Thorrez 2y ago
    >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.
Y_Y 2y ago
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.
- anthomtb 2y ago
  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.
taosx 2y ago
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.
- Someone 2y ago
  > 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)
- nulld3v 2y ago
  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.
kjksf 2y ago
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.
- Philpax 2y ago
  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.
  - nine_k 2y ago
    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?
    - autarch 2y ago
      > 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.
cies 2y ago
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.
mrhonza 2y ago
Note that the compiler is not open source. https://github.com/borgo-lang/borgo/issues/11 https://github.com/borgo-lang/borgo/issues/11
- graemep 2y ago
  Even worse than that, it has no license at all. It cannot legally be used.
  - diggan 2y ago
    > 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-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-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#choosing-the-right-license https://docs.github.com/en/repositories/managing-your-reposi...
    - Someone 2y ago
      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.
      - diggan 2y ago
laurentlb 2y ago
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.
- jjallen 2y ago
  There’s no license which makes a copyrighted work. This is just a performance without a license that permits usage of the language.
mindaslab 2y ago
[flagged]
- erokar 2y ago
  The nerve, creating a new language when you have already discovered Clojure!
  - mindaslab 2y ago
    Ya kind of, the nerve of creating a non lisp dialect :D
- cosmic_quanta 2y ago
  Let's be substantive : What makes Borgo junk? Can you seriously see nothing interesting here compared to Clojure?
  - mindaslab 2y ago
    For example, having the equal to (=), to assign variable is junk. I am sorry if people can't understand what I say.
bmacho 2y ago
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.
- diggan 2y ago
  > 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.
  - mkl 2y ago
    Webkit.
  - joatmon-snoo 2y ago
    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.
  - rererereferred 2y ago
    They've bought and kept running many projects. YouTube, Writely (now google docs), Android to name a few.
- mst 2y ago
  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.
vfclists 2y ago
How come on HN the comments which are tangential to the main topic always get voted to the top?
darkest_ruby 2y ago
this is basically what Go should have been!
sixthDot 2y ago
The first thing I do when I hear of a new PL is to look at its bug tracker.
jjallen 2y ago
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.
- snthpy 2y ago
  +1 on the license. What would be the point of compiling to Rust? Just use Rust in that case.
arvidj 2y ago
How does it compare to OCaml?
darthrupert 2y ago
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.
kbd 2y ago
Go deserves to get TypeScripted. Another effort in this vein is Go+ https://github.com/goplus/gop https://github.com/goplus/gop
- onionisafruit 2y ago
  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.
  - Too 2y ago
    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.
renox 2y ago
While it looks interesting but what is the story for debugging?
Insanity 2y ago
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 :)
3a2d29 2y ago
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.
dvdkon 2y ago
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.
nmilo 2y ago
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.
- atombender 2y ago
  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.
  - jitl 2y ago
    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.
skybrian 2y ago
I’m wondering how idiomatic the generated Go code is. Would it be useful for generating code in a Go library?
catlover76 2y ago
[dead]
fsndz 2y ago
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)
- Too 2y ago
  Higher level easily end up more domain specific. Think SQL or other query languages. Future ones will likely be designed around AI somehow.
  - pjmlp 2y ago
    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.
written-beyond 2y ago
Did someone finally fix/complete go?
waveywaves 2y ago
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 ?
xbar 2y ago
That curve is generous in the amount of type safety it distributes.
codr7 2y ago
Well done, looks almost enjoyable, a huge step up from Go.
yearolinuxdsktp 2y ago
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?
yearolinuxdsktp 2y ago
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.
rkerno 2y ago
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.
- jitl 2y ago
  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 ..."
  - rkerno 2y ago
    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.
    - never_inline 2y ago
      > true rust developers true rust developers will program with magnetic needle
  - hnlmorg 2y ago
    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.
sxhivs 2y ago
the syntax is clean ngl
SomeHacker44 2y ago
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.
Fire-Dragon-DoL 2y ago
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
andriesm 2y ago
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?

361 points by MrBuddyCasino 2y ago

brudgers 2y ago

The original ShowHN https://news.ycombinator.com/item?id=36847594 https://news.ycombinator.com/item?id=36847594

Philpax 2y ago
See also https://news.ycombinator.com/item?id=40211891 https://news.ycombinator.com/item?id=40211891, which has the bulk of HN discussion about Borgo
- dang 2y ago
  Thanks! Macroexpanded: Borgo is a statically typed language that compiles to Go - https://news.ycombinator.com/item?id=40211891 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 https://news.ycombinator.com/item?id=36847594 - July 2023 (8 comments)

blixt 2y ago

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.

howenterprisey 2y ago
I think it would be cool if we had something like this except as a superset.
- bmacho 2y ago
  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?
miohtama 2y ago
Is this TypeScript of Go?
- Supermancho 2y ago
  The graph and syntax, individually, inform the answer succinctly. No.
nine_k 2y ago
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.
- Thorrez 2y ago
  >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.

Y_Y 2y ago

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.

anthomtb 2y ago
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.

taosx 2y ago

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.

Someone 2y ago
> 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)
nulld3v 2y ago
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.

kjksf 2y ago

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.

Philpax 2y ago
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.
- nine_k 2y ago
  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?
  - autarch 2y ago
    > 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.

cies 2y ago

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.

mrhonza 2y ago

Note that the compiler is not open source. https://github.com/borgo-lang/borgo/issues/11 https://github.com/borgo-lang/borgo/issues/11

graemep 2y ago
Even worse than that, it has no license at all. It cannot legally be used.
- diggan 2y ago
  > 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-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-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#choosing-the-right-license https://docs.github.com/en/repositories/managing-your-reposi...
  - Someone 2y ago
    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.
    - diggan 2y ago

laurentlb 2y ago

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.

jjallen 2y ago
There’s no license which makes a copyrighted work. This is just a performance without a license that permits usage of the language.

mindaslab 2y ago

[flagged]

erokar 2y ago
The nerve, creating a new language when you have already discovered Clojure!
- mindaslab 2y ago
  Ya kind of, the nerve of creating a non lisp dialect :D
cosmic_quanta 2y ago
Let's be substantive : What makes Borgo junk? Can you seriously see nothing interesting here compared to Clojure?
- mindaslab 2y ago
  For example, having the equal to (=), to assign variable is junk. I am sorry if people can't understand what I say.

bmacho 2y ago

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.

diggan 2y ago
> 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.
- mkl 2y ago
  Webkit.
- joatmon-snoo 2y ago
  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.
- rererereferred 2y ago
  They've bought and kept running many projects. YouTube, Writely (now google docs), Android to name a few.
mst 2y ago
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.

vfclists 2y ago

How come on HN the comments which are tangential to the main topic always get voted to the top?

darkest_ruby 2y ago

this is basically what Go should have been!

sixthDot 2y ago

The first thing I do when I hear of a new PL is to look at its bug tracker.

jjallen 2y ago

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.

snthpy 2y ago
+1 on the license. What would be the point of compiling to Rust? Just use Rust in that case.

arvidj 2y ago

How does it compare to OCaml?

darthrupert 2y ago

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.

kbd 2y ago

Go deserves to get TypeScripted. Another effort in this vein is Go+ https://github.com/goplus/gop https://github.com/goplus/gop

onionisafruit 2y ago
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.
- Too 2y ago
  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.

renox 2y ago

While it looks interesting but what is the story for debugging?

Insanity 2y ago

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 :)

3a2d29 2y ago

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.

dvdkon 2y ago

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.

nmilo 2y ago

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.

atombender 2y ago
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.
- jitl 2y ago
  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.

skybrian 2y ago

I’m wondering how idiomatic the generated Go code is. Would it be useful for generating code in a Go library?

catlover76 2y ago

[dead]

fsndz 2y ago

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)

Too 2y ago
Higher level easily end up more domain specific. Think SQL or other query languages. Future ones will likely be designed around AI somehow.
- pjmlp 2y ago
  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.

written-beyond 2y ago

Did someone finally fix/complete go?

waveywaves 2y ago

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 ?

xbar 2y ago

That curve is generous in the amount of type safety it distributes.

codr7 2y ago

Well done, looks almost enjoyable, a huge step up from Go.

yearolinuxdsktp 2y ago

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?

yearolinuxdsktp 2y ago

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.

rkerno 2y ago

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.

jitl 2y ago
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 ..."
- rkerno 2y ago
  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.
  - never_inline 2y ago
    > true rust developers true rust developers will program with magnetic needle
- hnlmorg 2y ago
  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.

sxhivs 2y ago

the syntax is clean ngl

SomeHacker44 2y ago

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.

Fire-Dragon-DoL 2y ago

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

andriesm 2y ago

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?