Borgo is a statically typed language that compiles to Go

https://github.com/borgo-lang/borgo

by manx • 2 years ago

666 540 2 years ago

github.com

metadat3• 2 years ago

Is it correct to say Borgo "compiles to Go", or should it say "transpiles to Go"

It appears to be a transpiler (consumes a Borgo and does the work to convert and emit a Go program as text):

https://github.com/borgo-lang/borgo/blob/main/compiler/src/c...

PurpleRamen• 2 years ago

Readme says transpile: "Borgo is a new language that transpiles to Go."

And it's written in rust. Kinda unholy.

metadat3• 2 years ago

Yeah, the top of the project says "compiles", then the readme says "transpiles". Perhaps the author was just trying to get all the SEO terms in there.

And it's written in rust. Kinda unholy.

Agreed, it's like, do you really hate writing Go so much that you'll really write all that Rust to get out of it? Haha. Reminds me of the web frameworks which generated the JS so you didn't have to touch it, like GWT of old.

I'm sure it was a fun exercise to create Borgo, though.

My favorite transpiler is Haxe. It targets so many other languages, the surface area is impressive.

https://haxe.org/

pjmlp16• 2 years ago

Nothing like adding dependencies to the build toolchain.

speed_spread2• 2 years ago

Nothing unholy there. It's easier to transpile to a less constrained language. Transpiling to Rust would require using one of the GC crates or refcount everything. Then you'd have to also satisfy the mutability and send/sync constraints. Go needs none of these things, so all the transpiler needs to care about is it's own added constraints.

frozenport• 2 years ago

Transpiler is a kind of compiler

michaelsbradley2• 2 years ago

“transpiler”, “compiler”, either terminology is valid:

https://en.wikipedia.org/wiki/Source-to-source_compiler

metadat3• 2 years ago

Thanks, I'd always thought targeted transformations -> transpiler, but it makes sense it's really a subset of general compiler functionality, sans binary output.

jerf4• 2 years ago

The word "transpiler" propagates the misunderstanding that there is something special about a compiler that emits machine code, that requires some special "compiler" techniques for special "compiler" purposes that are not necessary for "transpiler" purposes because "transpiling" requires a completely different set of techniques.

There aren't any such techniques. If one were to create an academic discipline to study "transpilers" and one to study "compilers", all you'd end up with is an identical bunch of techniques and analyses with different names on them. (A thing that sometimes happens when diverse disciplines study what turns out to be the same thing; see machine learning versus statistics for a well-known example.)

Even "compiling" to machine code isn't special anymore, because CPUs don't actually execute assembly anymore. They themselves compile assembly into internal micro-ops, which is what they actually execute. So compilers don't even compile "machine language" anymore; it's just another target. This also dodges "is it a 'compiler' or a 'transpiler' if it targets WASM?", which is good, because there is no value in that question on any level.

markusde• 2 years ago

It doesn't matter but I fully disagree with this. A transpiler emits code the user is supposed to understand, a compiler does not. At least that's the general way I've seen the term used, and it seems quite consistent.

Matheus283• 2 years ago

1. Transpilers output to another programming language that is typically written by hand by others (so not assembly).

2. Transpilers don’t typically optimize code, leaving those transformations to the compiler of the target language.

3. Compilers will typically have an internal representation (SSA) which they operate on to optimize. Transpilers typically operate on the AST (because they don’t need to do any but the most trivial optimizations).

There are exceptions to the rules but these cover the majority of the reasons on why people make the distinction.

Joker_vD• 2 years ago

I'm fairly certain that source-to-source transpilers rarely use anything like BURS or any other sufficiently smart "instruction selection" (or insturction scheduling, for that matter) algorithms because why would they, the compilers for the targeted language already incorporate such algorithms, maybe even of the higher quality than the transpiler's author are capable to write themselves.

keybored5• 2 years ago

This was very nicely put. Thanks. I don’t think we need different terms just because the target languages are different (higher level or whatever).

rowanG0775• 2 years ago

Why would you target Go?

toolz2• 2 years ago

It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.

wesselbindt• 2 years ago

I'm not trying to be argumentative, I'm genuinely curious: what is it about the go runtime and tooling that makes them great?

I did not post your parent comment.

aorona• 2 years ago

subpar semantics?

zer00eyz8• 2 years ago

This is a terrible take.

It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use.

Most go devs have lived through bloated java/php/python/ruby/js projects that become a pile of dependencies.

Go is to coding what brutalism is to architecture. Simple, functional, efficient. Dont build a massive dependency chain, dont build magic, repeating yourself is OK. Be an adult and deal with your errors (it's a feature)... That minimalist no bullshit language semantics that force you not to be lazy is a feature not a bug.

ReflectedImage• 2 years ago

Ahh the failure to recognize that the great runtime and tooling is due to the language semantics.

theamk• 2 years ago

it's literally the 2nd sentence of README: "It's fully compatible with existing Go packages."

It's a nice way to bootstrap ecosystem IMHO. No one wants to use a brand-new language without library support for common tasks.

rowanG0775• 2 years ago

It doesn't make sense that that is the reason. Surely C++ has way more packages. So Go would be a bad choice if package availability was a very important concern.

akira25015• 2 years ago

Because a plethora of languages, some of which you don't personally like using, being part of a large and healthy ecosystem, benefits all languages and programmers.

There is no "one true" answer, and time spent bullying people over it, is entirely wasted.

dexwiz• 2 years ago

Can you use Go modules?

tbrockman3• 2 years ago

With a little bit of effort: https://borgo-lang.github.io/#package-definitions

HippoBaro• 2 years ago

Go has an amazing runtime and tool ecosystem, but I’ve always missed a little bit more type safety (especially rust enums). Neat!

templaedhel• 2 years ago

They made a coffeescript for go

christophilus• 2 years ago

They made a Typescript for go. Coffeescript was dynamic.

recursive• 2 years ago

Coffeescript added semantics and behavior. Typescript for better or worse is almost only types on top of existing behavior. (with the primary exception being the `enum` concept)

Qerub• 2 years ago

Reminds me of this previous effort to build upon Go but add a more flexible type system: https://github.com/oden-lang/oden

philosopher1234• 2 years ago

The only language I can think of that has pulled off “compiles to another totaling language” and gained mainstream adoption is typescript, and I’m sure it wouldn’t have done so if it were possible to run in the browser otherwise.

Can anyone think of another example?

elliotlarson• 2 years ago

Elixir compiles to Erlang, I think.

giancarlostoro• 2 years ago

Correct Elixir runs on the BEAN.

toolz2• 2 years ago

Not exactly correct, it does have "core erlang" as a compilation step, but they both have that as a compilation step ultimately compiling to beam bytecode.

tylerhou• 2 years ago

C++ used to compile to C.

ARandomerDude• 2 years ago

CoffeeScript was pretty popular about 10 years ago and did this.

furyofantares3• 2 years ago

C++ is for sure gonna be the biggest example. I think Objective-C too.

There's other successful but not "mainstream" languages that might count or semi-count, like Clojure targeting the JVM (though not Java) and being able to use Java packages, or ClojureScript targeting JavaScript.

michaelsbradley2• 2 years ago

Nim compiles to C by default, and it seems most Nim devs stick with that default. Nim hasn’t gained mainstream adoption, though.

hiccuphippo• 2 years ago

Not exactly the same but a few languages compile to llir which then is compiled by llvm to machine code.

dhosek• 2 years ago

There’s web2c which transpiles Pascal-Web to C code. And in the 90s, Eberhard Mattes, to enable his port of TeX and friends to OS/2 and DOS wrote a Pascal to C compiler (I remember when it was first released, there was speculation that it might have been a pirated commercial implementation because how could one guy manage this, but that was short-lived as people realized it was faster than any of the commercial versions.)

zem4• 2 years ago

haxe is not quite "mainstream adoption" level but it has a decent amount of stuff done in it

clojurescript is fairly popular too.

doctor_eval4• 2 years ago

I like your take but - not that this was important to TypeScript - JavaScript was literally the assembly language of the web (asm.js) until WASM came along. There was no other target that TypeScript could compile to. I guess that’s why TypeScript simply added types to JS, rather than being a wholly new language, which in turn made it compatible and familiar to potential adopters. It also solved a big problem caused by the growing size of client code bases.

All of that said - this train of thought lead me to discover AssemblyScript! https://www.assemblyscript.org/

eximius7• 2 years ago

Be still my heart. I would use this so fast at work where we currently use Go.

But introducing a new language is a scary thing.

eklavya3• 2 years ago

Congratulations and best wishes for your project. I have hoped for a Go+Rust lang for a long time now.

lordofgibbons• 2 years ago

Wow, this is everything I want from a new Go!

Having worked on multiple very large Go codebases with many engineers, the lack of actual enums and a built-in optional type instead of nil drive me crazy.

I think I'm in love.

Edit: Looks like last commit was 7 months ago. Was this abandoned, or considered feature complete? I hope it's not abandoned!

H1Supreme• 2 years ago

An Enum type has to be on the core Go team's radar by now. It's got to be tied with a try/catch block in terms of requested features at this point (now that we have generics).

TwentyPosts• 2 years ago

The issue is that it's more or less impossible to graft onto the language now. You could add enums, but the main reason why people want them is to fix the error handling. You can't do this without fracturing the ecosystem.

jurschreuder5• 2 years ago

I've never needed either.

Try/catch is super confusing because the catch is often far away from the try. And in Python I just put try/catch around big chunks of code just in case for production.

I think Go is more stable and readable because they force you not to use the lazy unreadable way of error handling.

Enums I honestly never used in Go also not the not-type-safe ones.

But I'm also someone who used interfaces in Go maybe I think 4 times only in years and years of development.

I just never really need all those fancy things.

Thaxll2• 2 years ago

No one wants try/catch/exception in Go.

AnonymousPlanet4• 2 years ago

I am so tired of reading Java/C++/Python code that just slaps try/catch around several lines. To some it might seem annoying to actually think about errors and error handling line by line, but for whoever tries to debug or refactor it's a godsend. Where I work, try/catch for more than one call that can throw an exception or including arbitrary lines that don't throw the caught exception, is a code smell.

So when I looked at Go for the first time, the error handling was one of the many positive features.

Is there any good reason for wanting try/catch other than being lazy?

mark38848• 2 years ago

How the fuck do you release a language without enums?

samatman3• 2 years ago

While I have no particular beef with Rust deciding to call its sum types "enum", to refer to this as the actual enum is a bit much.

Enumerated types are simply named integers in most languages, exactly the sort you get with const / iota in Go: https://en.wikipedia.org/wiki/Enumerated_type

Rather than the tagged union which the word represents in Rust, and only Rust. Java's enums are close, since they're classes and one can add arbitrary behaviors and extra data associated with the enum.

gr4vityWall• 2 years ago

Haxe also has Enums which are Generalized Algebraic Data Types, and they are called "enums" there as well: https://haxe.org/manual/types-enum-using.html

turdprincess• 2 years ago

Swift enums support union types as well, and are also very useful.

lelanthran8• 2 years ago

While I have no particular beef with Rust deciding to call its sum types "enum", to refer to this as the actual enum is a bit much.

I didn't read GP as saying "Actual enums are what Rust has", I read it more as "Go doesn't have actual enums", where "enum" is a type that is constrained to a specified set of values, which is what all mainstream non-Rust languages with enums call "Enums".

I mean, even if Rust never existed, the assertion "Go doesn't have actual enums" is still true, no?

ketralnis• 2 years ago

Rust is not as complicated as the opening graphic indicates. I usually see this meme from less experienced people but I'm frankly surprised to see it from somebody that's capable of writing a compiler in rust.

logdahl• 2 years ago

I think they are calling Rust complex, not complicated. Rust is way more complicated than Go, when we are talking about language features.

itishappy2• 2 years ago

Compared to GCed languages like Go and Borgo? Ownership is non-trivial...

akira25015• 2 years ago

It's also not as type safe as the graphic implies.

leecommamichael3• 2 years ago

There are no labels on the graph's axes :^)

ralegh4• 2 years ago

Great! Something I've always wanted.

I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly.

Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to refactor loads of stuff.

Like building out of clay and firing the parts you are happy with.

Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.

mattlondon• 2 years ago

Sounds like JavaScript and typescript would be a good fit for you. Highly expressive, dynamic and strongly typed, and highly performant both on server side and within the browser.

ralegh4• 2 years ago

I do like JavaScript but it strikes a weird balance for me where it's a bit too easy to write and a bit too verbose so I tend to end up with hard to maintain code. Feels good at the start of a project but rarely a few weeks in. Also not a fan of the node ecosystem, I try to use deno where I can (maybe that would be bun these days).

zem4• 2 years ago

perhaps rescript [https://rescript-lang.org/] even more than typescript

anonzzzies2• 2 years ago

Like building out of clay and firing the parts you are happy with. Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.

We do exactly that with Common Lisp. It compiles to different languages/frameworks depending on what we require (usually sbcl is more than enough, but for instance for embedded or ML we need another step. All dev (with smaller data etc) is in sbcl so with all the advantages.

ralegh4• 2 years ago

Is there somewhere I could read more about this? I've always wanted to learn Lisp but lacked a specific need for it.

VBprogrammer• 2 years ago

I like the idea but in all honesty I have difficulty imagining it working in practice. Once your python code is stable (i.e. You've worked out 99% of the bugs you might have caught earlier with strict type checking) would there be any incentive to go back and make the types more rigid or rigorous? Would there be a non-negligible chance of introducing bugs in that process?

ralegh4• 2 years ago

I agree it's a bit of a pipe dream. I'm more thinking of performance here, e.g. web services using Django. You could start off in dynamic/interpreted land and have a seamless transition to performant compiled land. Also lets you avoid premature optimisation since you can only optimise the hot paths.

Also types are self documenting to an extent. Could be helpful for a shared codebase. Again Python just now getting round to adding type definitions.

At the end of the day good tooling/ecosystem and sheer developer hours is more important than what I'm suggesting but it would be nice anyway. I dream about cool programming languages but I stick to boring for work.

zem4• 2 years ago

by the time you have your code in its final state (i.e. you're done experimenting) and shaken out the bugs, your types are mostly static; they're just implicitly so. adding annotations and a typechecker helps you maintain that state and catch the few places where type errors might still have slipped through despite all your tests (e.g. lesser-used code paths that need some rare combination of conditions to hit them all but will pass an unexpected type through the call chain when you do). it is very unlikely that you will introduce bugs at this point.

claudionaoto• 2 years ago

Dart? Version 1 was a lot like Javascript/Typescript in one spec (a dynamic language with optional unsound typing). Version 2 uses sound typing, but you can still let variables unannoted (and the compiler will infer type "dynamic") for scripts.

adsharma• 2 years ago

py2many does python-esque to both Go and Rust.

The larger problem is building an ecosystem and a stdlib that's written in python, not C. Use ffi or similar instead of C-API.

sevkih• 2 years ago

So swift?

foolfoolz2• 2 years ago

it looks a lot like java 21+

62951413• 2 years ago

Java < Kotlin < Scala

Golang < Borgo < Rust

preommr2• 2 years ago

This and pub/private modifiers for structs instead of letter casing is all I've ever wanted.

odc• 2 years ago

I love Go's letter casing. It's such a neat way to remove cruft.

metaltyphoon2• 2 years ago

Dislike it very much specially with codebases which have lots of acronyms, aka aviation. Having to change an acronym from upper to lowercase just suck.

phplovesong• 2 years ago

It also adds cruft. Public struct members JSON usually needs to be converted to lowercase. Hence the stuct tags.

jjallen3• 2 years ago

I spent quite a few hours tracking down bugs due to miscased struct fields unfortunately. Strongly prefer explicitness over implicitness

akira25015• 2 years ago

It's such a neat way to remove cruft.

I don't disagree, the problem I have with it is, I have to pay for that up front and have to factor it into my design immediately. This also combines with the fact that the namespace is very flat with no heirarchy, so, choosing good public names is something I feel like I spend way too much time on.

Go is the only language that causes me to pull out a thesaurus when trying to name methods and struct members. It's kinda maddening. Although, after going through this exercise, I end up with code that reads like English. I just wish I could refactor my way into that state, rather than having to try to nail it up front.

hgs32• 2 years ago

Go's semantic use of case is objectively bad because most of the worlds scripts do not have the concept of it. For example ideographs, as used in eastern countries, do not have capitalization. This means programmers in many parts of the world cannot express identifiers in their native tongue.

doctor_eval4• 2 years ago

I like the terseness of it but having to refactor just because I change visibility is a bit stupid.

I never wrote ObjC but didn’t they use + and - (and nothing) as visibility modifiers?

tredre32• 2 years ago

Same. It's ugly, it breaks acronyms, it doesn't work in all (spoken) languages, it doesn't work well with serialization, etc.

Frankly if they insisted on visibility being part of the name, I would have preferred they go with the age-old C++/ancientPHP tradition of using a _ prefix for private members.

ThouYS• 2 years ago

wow. this is it!

a3w• 2 years ago

Go is less complex than rust? Really? I thought that was disputed.

unshavedyak4• 2 years ago

Go is less complex than Rust, imo. As someone who has used Go and Rust for about the same time (5-6 years), it's not as less complex than it seems, though. Namely i found a odd type of complexity emerge in Go where by every individual unit was simple, but the whole was so spread out and poorly abstracted that it it spread out the complexity. So if you squinted, everything was simple. If you zoomed out, it felt convoluted.

Rust on the other hand drastically simplifies a lot of the complexity i dealt with in Go. However depending on the type of work, it's of course got plenty of complexity to dig into should you need it.

The challenge with Rust imo is to know where to use that complexity. Lots of rope to hang yourself with. On average i find myself with code that to me is simpler in Rust, because it's easier to reason about larger blocks of logic. However i still wouldn't ignore the extra rope of the whole language and call it "simpler" than Go.

akira25015• 2 years ago

You can read and grok the entire gospec in a week.

preommr2• 2 years ago

The golang language spec is very sparse on implementation details in comparison to something like the java spec. I don't think the length of the lang spec is a great metric for language simplicity.

leecommamichael3• 2 years ago

Rust has macros and a novel memory model. How would you measure complexity? For me it's that simple.

littlestymaar6• 2 years ago

Many people on HN “Rust syntax is so ugly”

rustaceans “I love the Rust syntax so much I want it in Go too”

Scramblejams2• 2 years ago

The author notes[0] that it keeps the Rust syntax to avoid having to write a parser.

I have no issue with the syntax but I think the chance of uptake would be considerably improved if the syntax were as close to Go's as reasonably possible. That's because I estimate Go programmers to be a better target for this than Rust programmers, but maybe I'm wrong.

[0] https://news.ycombinator.com/item?id=36847594

speed_spread2• 2 years ago

Having a soft-Rust alternative is a recurring topic in the Rust community and is acknowledged as being of interest by core members:

https://www.reddit.com/r/rust/comments/j2l9v9/revisiting_a_s...

pornel• 2 years ago

There’s no contradiction here.

Rust’s syntax looks alien to people who are not familiar with it, but the syntax itself is fine.

Some users also blame Rust’s syntax for being complicated when they actually struggle with Rust’s semantics, e.g. borrow checking wouldn’t be any less strict if Rust chose a less weird sigil for lifetime labels.

rthnbgrredf• 2 years ago

Would it be possible to make a Python (without C extensions) that compiles to Go?

funny_falcon• 2 years ago

There was one: https://github.com/grumpyhome/grumpy

Looks like abandoned though.

cardanome• 2 years ago

I am not sure you can easily directly transpile to Golang from Python. Python is very, very dynamic and can have extremely complex types that are not representable with the Golang type system. Not impossible but I guess you might end up with an extra runtime layer and some more dynamic operations will not be very fast. Or you restrict it to a subset of Python like this project does: https://github.com/zanellia/prometeo

You could of course write a bytecode VM in Golang but I guess that defeats the purpose.

rdevsrex• 2 years ago

It looks pretty interesting! Definitely something to play around with, but honestly, I'd rather just use Rust (or Gleam if GC is ok).

giovannibonetti• 2 years ago

This seems to achieve a similar type safety<->complexity tradeoff as Gleam [1] does. However, Gleam compiles to Erlang or JavaScript, which require a runtime and are not as performant as Go.

I wonder if Borgo's compiler messages are as nice as Rust's/Gleam's, though.

[1] https://gleam.run/

ffsm82• 2 years ago

are not as performant as Go.

Ymmv, you might be surprised if you actually bothered to benchmark. Depending on the workload, either JS or erlang can ultimately turn out on top.

They're all optimized to a degree that each has a niche it excells at and leaves the others in the dust.

even with heavily scewed benchmark like techempower fortunes (https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...) you end up with JS getting ahead of Go with raw requests. And not just slightly, but by 1.5 times the throughput.

In other benchmarks, Golang does indeed win out with similar or even bigger advantages... so the only thing you can ultimately say is ... that it depends. Its a different story if you chose other languages though. But JS, Golang and Erlang are all extremely optimized for their ideal usecase.

lolinder6• 2 years ago

I'd add Java to that list as well. JIT compilers have come a long way, and OpenJDK was on par with Rust for performance on the last project I tried porting.

hombre_fatal• 2 years ago

Well hold on a second. The JS impl that you're talking about uses a minimal custom runtime (https://github.com/just-js/just) that you would never use—it barely implements JS. It's basically only used for this benchmark. It doesn't make sense to compare that to Go when we're talking about Javascript vs. Go performance.

Scroll down to the "nodejs" entry for a more realistic comparison.

DerSaidin• 2 years ago

I like the graph at the top of the readme as a summary.

The rest of the readme focuses on the delta between Go and Borgo. It doesn't say much about the delta between Borgo and Rust.

I think the delta there is mainly no lifetimes/ownership?

eximius7• 2 years ago

No traits, const generics, probably no turbofish equivalent for when inference struggles.

sushisource2• 2 years ago

Most importantly: Null pointers still exist (yes I know they technically exist in unsafe Rust, to head off any pedants)

Also: No `?` operator

shepherdjerred2• 2 years ago

I would kill for these languages features in Go

neonsunset5• 2 years ago

That's what C# offers (except true* Rust-style enums).

The latter will be there in one of the future versions and is in an active design phase, which luckily focuses on tagged-union implementation strategy.

With that said, you can already easily use one of the Option/Result libraries or write your own structure - switching on either is trivial (though you have to sometimes choose between zero-cost-ness and convenience).

It already has struct generics, iterator expressions (LINQ), switch pattern matching, good C interop and easy concurrency primitives (no WaitGroup nonsense, also has Channel<T>). Oh, and also portable SIMD, C pointers and very strong performance in general.

* True as in proper tagged unions with either a tag or another type of discriminant and aliased layout, instead of tag + flattening all constituent parts into a one jumbo struct. Or making it an opaque pointer to a box (like Java does, or C# if you go inheritance/interface route). These don't count. I'm curious about Borgo's lowering strategy for enums, but given Go doesn't have those, I'm not holding my breath and expecting something like F# struct unions at best.

mdaniel5• 2 years ago

As someone who is "C# curious," but haven't been able to keep up with all the horrific number of rebrands of the "new, open, .net, core, framework", what is the C# equivalent of $(for GOOS in linux darwin; do for GOARCH in amd64 arm64; do dotnet build -o thing_${GOOS}-${GOARCH}; done; done)?

orthoxerox• 2 years ago

It's not the best solution, but an analyzer like [0] covers most of the cases for reference types. For enums and struct DUs in general we'll have to wait for language (or even runtime) support.

[0] https://github.com/shuebner/ClosedTypeHierarchyDiagnosticSup...

shepherdjerred2• 2 years ago

To clarify, my team uses Go and prefers to stick with "idiomatic" Go. So, while we could implement our own types, there would be pushback. As an example I liked lo [0] but my team was resistant because it's not considered idomatic.

If were up to me we'd be using a language with a better type system :)

[0] https://github.com/samber/lo

jjnoakes• 2 years ago

What's the license?

fl0ki2• 2 years ago

It's a little suspicious the example uses math/rand.Seed() which has been deprecated for over a year. That's when I noticed the repo itself hasn't had a single commit in 7 months.

Why is this suddenly news, when by all appearances it's abandonware?

OJFord3• 2 years ago

Why is this suddenly news, when by all appearances it's abandonware?

Because the submitter suddenly found it, and it was new to many others too? It's not a 'Show HN'.

OJFord3• 2 years ago

Why compile to Go rather than less-than-ideal (or even slightly-unsafe) Rust?

I find it conceptually compelling, I'm just surprised the target would then be in the GC'd, larger-binary'd direction. Like 'Java expressiveness with C simplicity, transpiles to Java'.

Perhaps 'just' because it's a lot simpler to just expand the target language slightly and then you only have to deal with mapping the new bits into implementation, it's less like writing a compiler for a whole new language?

Mawr18• 2 years ago

Good question. It's probably to be able to continue using the Go ecosystem. You could not incrementally switch a Go codebase to a Rust-based Borgo, but you can when it's Go-based.

OJFord3• 2 years ago

Why not? You can have a language B that's a superset of language G but which compiles to language R.

It's even typical in a sense: C++ is a superset of C, that doesn't mean it has to compile to C, it compiles to LLVM IR or whatever.

leecommamichael3• 2 years ago

I suspect emitting safe Rust would necessitate your very own implementation of a borrow-checker, or a weak flavor of it, in the language frontend. From there you place yourself in the author's shoes and consider the tradeoffs that come with emitting unsafe Rust. My interpretation of _that_ tradeoff is emitting "something like C++" or "something like Java," to use your analogy. There appears to be less to get wrong.

outside1234• 2 years ago

Nice - it uses Rust Try syntax to solve error conditions and Rust style enums!

Which of course begs another question but I won't be that Rust fanboy

pdimitar3• 2 years ago

Does Borgo have a Treesitter grammar? An LSP? I'd use it in a heartbeat if so.

himujjal• 2 years ago

Neovim user detected!

tbrockman3• 2 years ago

This addresses pretty much all of my least favorite things with writing Go code at work, and I hope--at the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias!) of the responses inspires Go maintainers to consider/prioritize some of these features, or renews the authors interest in working on the project (as some have commented, it seems to have gone without activity for a little bit over half a year).

Some of the design decisions seem to me to be a bit more driven by being Rust-like than addressing Go's thorns though. In particular, using `impl` to define methods on types (https://borgo-lang.github.io/#methods), the new syntax for channels and goroutines (https://borgo-lang.github.io/#channels), and the `zeroValue()` built-in (https://borgo-lang.github.io/#zero-values-and-nil) seem a bit out of place. Overall though, if I had a choice, I would still rather write Borgo by the looks of it.

nobleach• 2 years ago

I have to disagree. I'm on record here lamenting Go. I've never really enjoyed writing it. When I've had to use it, I've used it. Lately though, I've found a lot more pleasure. And much of that comes from the fact that it does NOT have all these features. The code I write, is going to look like the code written by most other on my team. There's an idiomatic way to write Go, and it doesn't involve those concepts from other languages. (For better or for worse) So I'm super hyped that we'd have a "compiles TO Go" language, but I'm not as excited as using it as a catalyst to get new (and perhaps wrong for the language) features into Go.

fl0ki2• 2 years ago

A lot of people said the same about generics, and some even still do. I could barely stand Go before generics, and still don't think they go far enough.

From my experience, things I think Go could really benefit from, like I believe it has benefited from generics:

* A way to implement new interfaces for existing types and type constraints for custom types, like `impl Trait for T`. This would obsolete most uses of reflection in the wild, in a way generics alone haven't. This isn't about syntax, it's about an entirely different way to associate methods to types, and with both Go and Rust being "data-oriented" languages, it's weird that Go is so limited in this particular regard. It has many other consequences when combined with generics, such as ...

* Ability to attach receiverless methods to types. Go concrete types may not need associated methods like "constructors", but generic types do, and there's no solution yet. You can provide factory functions everywhere and they infect the whole call graph (though this seems to be "idiomatic"), or make a special method that ignores its receiver and call that on a zero instance of the type, which is more hacky but closer to how free functions can be resolved by type. There's no reason this should be limited to constructors, that's just the easiest example to explain, in Rust associated methods are used for all kinds of things. Speaking of which...

* `cmp.Ordered` for custom types. Come on people. We shouldn't still have this much boilerplate to sort/min/max custom types, especially two full years after generics. The new `slices.SortFunc()` is the closest we've ever come, and it's still not associated with the type. We would basically get this for free if both of the above points were solved, but it's also possible we get something else entirely that solves only ordering and not e.g. construction or serialization.

* Enums, especially if the need for exhaustiveness checking could be balanced with Go's values of making code easy to evolve later. When I need them, I use the `interface Foo { isFoo() }` idiom and accept heap boxing overhead, but even the official `deadcode` analysis tool still to this day does not recognize this idiom or support enough configuration to force it to understand. The Go toolchain could at the very least recognize idioms people are using to work around Go's own limitations.

If we had solutions to these problems, I think most Go folks would find enough value in them that they would still be "Go". In fact, I think people would have an easier time consolidating on a new standard way to do things rather than each come up with their own separate workarounds for it.

This is where I feel "The code I write, is going to look like the code written by most other on my team" the least, because that's only true when a Go idiom has some official status, it's not nearly as true for workarounds that the Go team has not yet chosen to either endorse or obsolete.

tbrockman3• 2 years ago

I'm open to alternatives, but I haven't experienced any language constructs that strike as good of a balance between forcing you to handle errors/options when a function indicates it returns them, and allowing you to do so without too much ceremony. I don't think match is enough on it's own, but when combined with if-let/let-else/?-operator I don't feel like I'm sacrificing significant time and effort in dealing with Results/Options, so I'm not encouraged to cut corners and write worse code to avoid returning them in the first place.

The idiomatic way to write Go discourages you from robust error handling; return an opaque error, which callers will probably deal with as a string (or bubble-up as much as possible) because knowing its potential concrete types requires either reading source code or having documentation available (as the idiomatic function return type won't tell you anything about it). The path of least resistance only goes as far as forcing you to acknowledge there might be an error, it doesn't help you make good decisions about how to deal with it.

I think without also having to learn about lifetimes and dealing with async that this still presents an attractive trade-off for people who want to be quickly productive and don't care as much about garbage collection.

everforward• 2 years ago

I agree with you. I’m not the biggest fan of Go and would personally love these features, but they’re very counter to Go’s purpose. These feel Rust-y to me.

Go was designed to be simple enough that developers can’t write code too complicated for others to read, with a particular eye towards junior devs (and ops/infra people, I think).

This usage of sigils for error handling and union return types is very cool and very expressive, but also going to confuse the shit out of your new devs or infra people. It’s just not a good fit for what Go wants to be.

I’m even sympathetic to the idea that generics are similar, though personally I think the alternative to generics is code generators, which are worse.

Anecdotally, I recently wrote some Go code at work (infra team) that used generics, and I had to look outside my team to even find someone that felt comfortable reviewing generic Go code. I see a fair bit of code using interface{} or any that would be much simpler and better with generics.

saghm3• 2 years ago

the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias

As someone who has the "Rust bias", I feel like it's a bit of an open secret that a _lot_ of Rust developers don't actually need the extreme low-level performance that it offers and use it more because of the quality of life things (including some of the features in Borgo, but also tooling like cargo, rustdoc, etc.). I've said for a while that a language that focused on this sort of "developer experience" but used a GC to be a bit more flexible would probably be enough for a large portion of Rust developers, and pretty much everyone Rust developer I've talked to agrees with this (even if they aren't in the portion that would use this).

It's also pretty common for me to see people asking why someone would use a low-level, C++ language for something like web development, and I think the explanation is pretty similar; people like a lot of what Rust has to offer besides the low-level C++-like semantics, but there isn't something higher-level that offers enough of those features yet. Probably the language that would come closest to this is OCaml, but stuff like the documentation and "multiple preludes" are exactly the kind of thing that add friction to getting up and running, which is something Rust has invested a lot of time into reducing.

tubthumper83• 2 years ago

I've said for a while that a language that focused on this sort of "developer experience" but used a GC to be a bit more flexible would probably be enough for a large portion of Rust developers

Why then would Go not fit? It prioritizes developer experience (documentation, automatic formatting, etc.) with a GC

deergomoo• 2 years ago

but there isn't something higher-level that offers enough of those features yet

I think Swift would tick most of those boxes, it’s a shame it hasn’t really picked up outside Apple-land.

It can be a horribly complex language, but day-to-day it’s very nice to write.

willhslade• 2 years ago

Is this .Net?

derefr8• 2 years ago

I think, for any language that "targets the Golang runtime", you do need some way to express to the runtime to "use the zero-value default initializer." Otherwise, you'd have no hope of code in your language being able to be used to define e.g. protobuf-compatible types; or of using Golang-runtime reflection (due to e.g. the interface zero-value.)

Hasnep• 2 years ago

About a year ago, I tried writing a language that transpiled to Go with many of the same features, in my research I found other attempts at the same idea:

- braid: https://github.com/joshsharp/braid

- have: https://github.com/vrok/have

- oden: https://oden-lang.github.io/

sharno• 2 years ago

There was also purescript: https://github.com/andyarvanitis/purescript-native

owenpalmer2• 2 years ago

This looks like an interesting sweet spot. Rust is often praised for the borrow checker, but honestly I really only like rust for the type system and error handling. Go is praised for it's simplicity, but hated for it's error handling.

noisy_boy2• 2 years ago

Rust without borrow checker is much less feasible than Go with Result/Option types to address the nil overdose problem. Unfortunately Go team refuses to acknowledge the common themes coming out of years of user complaints. They don't have to cater to every wishlist but when nil/enum related complaints are the majority in every discussion about issues with Go, one would think to acknowledge the legitimacy of those shortcomings. Nope, not Go team and their band of simplicity zealots.

Mawr18• 2 years ago

I'm not sure what exactly you mean by acknowledgement, but here are some counterexamples:

- A proposal for sum types by a Go team member: https://github.com/golang/go/issues/57644

- The community proposal with some comments from the Go team: https://github.com/golang/go/issues/19412

Here are some excerpts from the latest Go survey [1]:

- "The top responses in the closed-form were learning how to write Go effectively (15%) and the verbosity of error handling (13%)."

- "The most common response mentioned Go’s type system, and often asked specifically for enums, option types, or sum types in Go."

I think the problem is not the lack of will on the part of the Go team, but rather that these issues are not easy to fix in a way that fits the language and doesn't cause too many issues with backwards compatibility.

[1] https://go.dev/blog/survey2024-h1-results

pjmlp16• 2 years ago

You can get Rust's type system in most ML derived languages, some of them even go beyond what Rust is capable of today.

throw-the-towel5• 2 years ago

Could you share a bit more?

owenpalmer2• 2 years ago

Can you give some examples?

peterkos• 2 years ago

This looks a lot like Swift. To me, that's a good thing :)

lf-non• 2 years ago

In the same vein, Go+ is also interesting, and its being actively developed.

https://goplus.org/

samuell• 2 years ago

Where's the list of "Awesome Go-derived languages"? :)

throwaway17_17• 2 years ago

I am genuinely appreciative that a post like this, a GitHub link to a semi-slow moving, but clearly well considered and sincerely developed programming language, can not only remain on the front page of HN, but can generate a diverse and interesting group of discussions. It’s material like this that keeps me coming back to the site. I’m not sure if anyone needed this comment, but I’m sure my posting it isn’t going to hurt.

vbezhenar2• 2 years ago

No exceptions - no love.

cellularmitosis• 2 years ago

Has anyone written a language which targets golang assembler yet? I’m surprised I don’t see that.

ackseq• 2 years ago

to me the problem is not the language per se but the emerging complexity of a project written in a language. I.e. say I'm familiar with go and a k8s user. Does that mean that I can understand the architecture of k8s project and be meaningfully productive in a short period of time? Far from it.

Sometimes I think we focus too much and formalize on the first order tooling we use, language being one of them, while we neglect the layers upon layers of abstractions built on top of them. I wonder whether a meta-language could exist that would be useful in these upper layers. Not a framework that imposes its own logic. More of a DSL that can capture both business logic and architecture.

nikolayasdf123• 2 years ago

if this produced SIMD optimised code, better inlining, and just more LLVM features, I would use this!

syngrog66• 2 years ago

I'd never let a rando project on GitHub generate my code. Become dependent on their tiny new syntax AND let it generate the Go code that will actually be built from. Asking for things like backdoor insertion trick to be introduced later, after they have enough folks dependent on them and decide reward worth the risk. GitHub is The Jungle and all that entails.

fridental• 2 years ago

I understand that you like some Rust features like Result and Option types, enums, and pattern matching.

These features provide for more safety, and at the same time, they reduce productivity by forcing the developer to statically type everything.

The question is then why do we need to transpile to Go, a language with GC and slower than Rust?

If we already agree on super-safe static typing, why not just use Rust? Are there any libraries in Go that are not available or of worse quality in Rust?

yencabulator• 2 years ago

Sum types having zero values seems to be breaking the promise that people hoped out of them.

    use fmt
    
    enum Coin {
        Penny,
        Nickel,
        Dime,
        Quarter,
    }

    fn wtf() -> Coin {
      return zeroValue()
    }
    
    fn main() {
        let coin = wtf()
        fmt.Println("zero coin:", coin)
    }

Output:

    zero coin: {0}

anonfordays• 2 years ago

This is a fantastic proof of concept project that answers a question I've been asking: what if there was another language that was designed to fit between Go and Rust? Ideas?

tail_exchange• 2 years ago

Option instead of nil is amazing. Imo, the biggest flaw in Go's design is having nils instead of optionals.

I don't have a strong opinion on Result and Pattern matching - it seems nice, but I don't know if it adds much to the language. It is nice, but it may not be worth the complexity.

The error handling with ? is a no for me. I'd rather have something more like the go-errors/errors package in the standard library instead. This has been proposed before, and it was rejected for a good reason: it makes it too easy to be lazy and just bubble up errors instead of properly handling them.

Borgo is a statically typed language that compiles to Go

Related Stories