35 ms·

Borgo is a statically typed language that compiles to Go

666 points by manx 2y ago

tail_exchange 2y 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.
metadat 2y 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/codegen.rs https://github.com/borgo-lang/borgo/blob/main/compiler/src/c...
- PurpleRamen 2y ago
  Readme says transpile: "Borgo is a new language that transpiles to Go." And it's written in rust. Kinda unholy.
  - metadat 2y 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/ https://haxe.org/
    - Alifatisk 2y ago
      I’ve totally forgotten about Haxe!
  - pjmlp 2y ago
    Nothing like adding dependencies to the build toolchain.
  - speed_spread 2y 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 2y ago
  Transpiler is a kind of compiler
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- michaelsbradley 2y ago
  “transpiler”, “compiler”, either terminology is valid: https://en.wikipedia.org/wiki/Source-to-source_compiler https://en.wikipedia.org/wiki/Source-to-source_compiler
  - metadat 2y 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.
    - randomdata 2y ago
      > but it makes sense it's really a subset of general compiler functionality, sans binary output. Tell us more about this compiler subset that does not produce binary output. What do they produce? Ternary? Qubits? Nothing?
      - lolinder 2y ago
        They produce text, such as Golang source code.
        randomdata 2y ago
        Thanks for your response, but the Go spec asserts that Go source is represented as UTF-8. UTF-8 is a binary encoding. We're talking about compilers that produce something other than binary output.
        lolinder 2y ago
        Ah, my mistake, I thought you were making an earnest inquiry and not a joke. Carry on.
- jerf 2y 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 2y 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.
    - eklavya 2y ago
      I see what you mean but how is it academically useful to identify transpilers something of their own? It's still compiling (lowering) from one notation to another.
    - randomdata 2y ago
      All compiler outputs are understandable. I suppose you mean with the intent of it being a one-time translation? As in, like when the Go project converted the original C codebase into Go source with the intent of having developers work in the Go output afterwards and the C code to be never touched again? What is meaningful about such a distinction?
    - 2y ago
rowanG077 2y ago
Why would you target Go?
- toolz 2y 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.
  - aorona 2y ago
    subpar semantics?
  - wesselbindt 2y 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.
    - wrs 2y ago
      To name a few things: Excellent and very stable stdlib (if you’re making a networked thing), fast GC optimized for latency, async I/O without any fuss, easy CSP-like concurrency, fast compile time, statically linked binaries, large user community.
    - zer00eyz 2y ago
      GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ----------------------- Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism. As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....
dexwiz 2y ago
Can you use Go modules?
- tbrockman 2y ago
  With a little bit of effort: https://borgo-lang.github.io/#package-definitions https://borgo-lang.github.io/#package-definitions
eklavya 2y ago
Congratulations and best wishes for your project. I have hoped for a Go+Rust lang for a long time now.
Qerub 2y ago
Reminds me of this previous effort to build upon Go but add a more flexible type system: https://github.com/oden-lang/oden https://github.com/oden-lang/oden
HippoBaro 2y 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 2y ago
They made a coffeescript for go
- christophilus 2y ago
  They made a Typescript for go. Coffeescript was dynamic.
  - recursive 2y 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)
philosopher1234 2y 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 2y ago
  Elixir compiles to Erlang, I think.
  - toolz 2y 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.
  - giancarlostoro 2y ago
    Correct Elixir runs on the BEAN.
- ARandomerDude 2y ago
  CoffeeScript was pretty popular about 10 years ago and did this.
- tylerhou 2y ago
  C++ used to compile to C.
- furyofantares 2y 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.
- michaelsbradley 2y ago
  Nim compiles to C by default, and it seems most Nim devs stick with that default. Nim hasn’t gained mainstream adoption, though.
eximius 2y 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.
lordofgibbons 2y 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 2y 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 2y 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.
    - drdaeman 2y ago
      > but the main reason why people want them is to fix the error handling Why do you think so? Maybe I'm an odd case, but my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake. Or for state machines. Error handling is manageable without enums (but I love Option/Result types more than Go's error approach, especially with the ? operator).
      - randomdata 2y ago
        > my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake Then what you are really looking for is sum types (what Rust calls enums, but unusually so), not enums. Go does not have sum types, but you can use interfaces to archive a rough facsimile and most certainly to satisfy your specific expectation: type Hot struct{} func (Hot) temp() {} type Cold struct{} func (Cold) temp() {} type Temperature interface { temp() } func SetThermostat(temperature Temperature) { switch temperature.(type) { case Hot: fmt.Println("Hot") case Cold: fmt.Println("Cold") } }
ketralnis 2y 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 2y ago
  I think they are calling Rust complex, not complicated. Rust is way more complicated than Go, when we are talking about language features.
- itishappy 2y ago
  Compared to GCed languages like Go and Borgo? Ownership is non-trivial...
- akira2501 2y ago
  It's also not as type safe as the graphic implies.
- leecommamichael 2y ago
  There are no labels on the graph's axes :^)
ralegh 2y 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 2y 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.
  - ralegh 2y 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).
  - zem 2y ago
    perhaps rescript [https://rescript-lang.org/ https://rescript-lang.org/] even more than typescript
- anonzzzies 2y 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.
sevkih 2y ago
So swift?
- foolfoolz 2y ago
  it looks a lot like java 21+
  - 62951413 2y ago
    Java < Kotlin < Scala Golang < Borgo < Rust
    - foolfoolz 2y ago
      i (nearly) wrote only scala for 10 years. if i was starting a project today i would not use scala. its still a great language.
preommr 2y ago
This and pub/private modifiers for structs instead of letter casing is all I've ever wanted.
- odc 2y ago
  I love Go's letter casing. It's such a neat way to remove cruft.
  - metaltyphoon 2y 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.
    - Groxx 2y ago
      In that case, maybe try: `_ACRNYM`
      - metaltyphoon 2y ago
        Function names with _ ? That’s not for me :)
  - phplovesong 2y ago
    It also adds cruft. Public struct members JSON usually needs to be converted to lowercase. Hence the stuct tags.
    - eadmund 2y ago
      JSON is just one tiny part of most programs, sitting on the edge where the program interacts with other programs; it doesn’t permeate the entire codebase. Structure privacy, OTOH, does. Count me in as someone who really enjoys the case-based approach. It’s not the only one which could work, but it does work.
      - 2y ago
a3w 2y ago
Go is less complex than rust? Really? I thought that was disputed.
- unshavedyak 2y 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.
- akira2501 2y ago
  You can read and grok the entire gospec in a week.
  - preommr 2y 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.
    - akira2501 2y ago
      The Java specification is bigger because it has to define the entire Virtual Machine where a compiler can target already defined architectures. I'm also not seeing much in the way of "implementation details" in their specification. Can you point out what you mean?
- leecommamichael 2y ago
ThouYS 2y ago
wow. this is it!
littlestymaar 2y ago
Many people on HN “Rust syntax is so ugly” rustaceans “I love the Rust syntax so much I want it in Go too”
- Scramblejams 2y 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 https://news.ycombinator.com/item?id=36847594
  - speed_spread 2y 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_smaller_rust/ https://www.reddit.com/r/rust/comments/j2l9v9/revisiting_a_s...
    - Scramblejams 2y ago
      Yeah, it'd be great to see something come of it. Been a while, though.
- pornel 2y 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 2y ago
Would it be possible to make a Python (without C extensions) that compiles to Go?
- funny_falcon 2y ago
  There was one: https://github.com/grumpyhome/grumpy https://github.com/grumpyhome/grumpy Looks like abandoned though.
- cardanome 2y 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 https://github.com/zanellia/prometeo You could of course write a bytecode VM in Golang but I guess that defeats the purpose.
rdevsrex 2y 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 2y 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/ https://gleam.run/
- ffsm8 2y 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&section=data-r22 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.
  - lolinder 2y 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 2y 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 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.
    - ffsm8 2y ago
DerSaidin 2y 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?
- eximius 2y ago
  No traits, const generics, probably no turbofish equivalent for when inference struggles.
  - sushisource 2y ago
    Most importantly: Null pointers still exist (yes I know they technically exist in unsafe Rust, to head off any pedants) Also: No `?` operator
    - jdknezek 2y ago
      There is a `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error-handling-with--operator https://github.com/borgo-lang/borgo?tab=readme-ov-file#error...
      - sushisource 2y ago
        Oh! Cool somehow I missed that
    - skitter 2y ago
      Pedants would say that null pointers exist in safe Rust too.
shepherdjerred 2y ago
I would kill for these languages features in Go
- neonsunset 2y 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.
  - mdaniel 2y 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)?
    - nrr 2y ago
      That's spelled `dotnet publish -r ${GOOS}-${GOARCH}` with the new ahead-of-time (branded Native AOT) compilation features installed and enabled. It isn't without a whole list of caveats if you're used to Go's way of doing things though. See <https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...> for details.
jjnoakes 2y ago
What's the license?
fl0ki 2y 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?
- OJFord 2y 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'.
OJFord 2y 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?
- Mawr 2y 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.
  - OJFord 2y 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.
- leecommamichael 2y 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 2y 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
pdimitar 2y ago
Does Borgo have a Treesitter grammar? An LSP? I'd use it in a heartbeat if so.
- himujjal 2y ago
  Neovim user detected!
tbrockman 2y 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 https://borgo-lang.github.io/#methods), the new syntax for channels and goroutines (https://borgo-lang.github.io/#channels https://borgo-lang.github.io/#channels), and the `zeroValue()` built-in (https://borgo-lang.github.io/#zero-values-and-nil 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 2y 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.
  - fl0ki 2y 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.
Hasnep 2y 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 https://github.com/joshsharp/braid - have: https://github.com/vrok/have https://github.com/vrok/have - oden: https://oden-lang.github.io/ https://oden-lang.github.io/
- sharno 2y ago
  There was also purescript: https://github.com/andyarvanitis/purescript-native https://github.com/andyarvanitis/purescript-native
owenpalmer 2y 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_boy 2y 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.
  - Mawr 2y 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 https://github.com/golang/go/issues/57644 - The community proposal with some comments from the Go team: https://github.com/golang/go/issues/19412 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 https://go.dev/blog/survey2024-h1-results
    - noisy_boy 2y ago
      I guess I should have been more clear that I mean actions that have resulted from the feedback. Sure, the survey brings out the concerns in a structured form, but to anyone who has seen more than a few discussions about Go, the feedback regarding error handling or enum or sum types etc would not have been news. I can't imagine Go team at Google is stunned by developer demand for these things. Question is why there hasn't been a concerted effort to prioritize these top concerns (I will stand corrected if there is already something underway that I'm not aware of). One of the proposals you linked has been raised in 2017 and it is still open with "No one assigned"; same fate for the other item. That doesn't inspire confidence in terms of Go team treating these things as top priority. I think stuff developers are moaning about the most should be top priority but I guess that is just my simpleton thinking. > 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. They have made many changes to the language, some significant ones like Generics (which I would assume was also not an easy problem to solve) while they have largely left the elephant in the room unaddressed i.e. error handling - and the developers deal with that one on a daily basis and I would wager a lot more frequently compared to Generics. If I had to gauge their priority, I would go by where they they are putting their money instead of surveys and proposals. And their priorities seem to be different from what the populace is asking. And that is my point.
peterkos 2y ago
This looks a lot like Swift. To me, that's a good thing :)
lf-non 2y ago
In the same vein, Go+ is also interesting, and its being actively developed. https://goplus.org/ https://goplus.org/
- samuell 2y ago
  Where's the list of "Awesome Go-derived languages"? :)
throwaway17_17 2y 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.
- sevagh 2y ago
  [flagged]
  - Defletter 2y ago
    Nor yours.
    - sevagh 2y ago
      This kind of pandering horseshit from throwaway accounts add no value and should be downvoted on sight. Especially if you bake self-deprecation into it, "uwu I'm... I'm not sure if a-anybody is going to like my comment..." Just let the good conversation unfold without patronizing meta-commentary. This isn't Reddit.
      - throwaway17_17 2y ago
        Just an aside, this is my only account which I humorously thought I would name throwaway when I made it 5 years ago. I have repeatedly regretted the choice, even if using a better handle I still probably would have posted this. Also, it is not in my typical wheelhouse of comments, but I was on my 3rd scotch and soda, so it’s came out relatively coherent.
      - abdusco 2y ago
        I observed the same thing happen for YouTube videos in the last couple of years and it drives me crazy. I don't need 20 different comments fishing for likes that try hard to compliment something, and point out how this creator does something that others don't. They're everywhere!
vbezhenar 2y ago
No exceptions - no love.
cellularmitosis 2y ago
Has anyone written a language which targets golang assembler yet? I’m surprised I don’t see that.
ackseq 2y 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 2y ago
if this produced SIMD optimised code, better inlining, and just more LLVM features, I would use this!
mongonews 2y ago
[flagged]
syngrog66 2y 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 2y 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 2y 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 2y 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?

666 points by manx 2y 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.

metadat 2y 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/codegen.rs https://github.com/borgo-lang/borgo/blob/main/compiler/src/c...

PurpleRamen 2y ago
Readme says transpile: "Borgo is a new language that transpiles to Go." And it's written in rust. Kinda unholy.
- metadat 2y 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/ https://haxe.org/
  - Alifatisk 2y ago
    I’ve totally forgotten about Haxe!
- pjmlp 2y ago
  Nothing like adding dependencies to the build toolchain.
- speed_spread 2y 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 2y ago
Transpiler is a kind of compiler
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
michaelsbradley 2y ago
“transpiler”, “compiler”, either terminology is valid: https://en.wikipedia.org/wiki/Source-to-source_compiler https://en.wikipedia.org/wiki/Source-to-source_compiler
- metadat 2y 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.
  - randomdata 2y ago
    > but it makes sense it's really a subset of general compiler functionality, sans binary output. Tell us more about this compiler subset that does not produce binary output. What do they produce? Ternary? Qubits? Nothing?
    - lolinder 2y ago
      They produce text, such as Golang source code.
      - randomdata 2y ago
        Thanks for your response, but the Go spec asserts that Go source is represented as UTF-8. UTF-8 is a binary encoding. We're talking about compilers that produce something other than binary output.
        lolinder 2y ago
        Ah, my mistake, I thought you were making an earnest inquiry and not a joke. Carry on.
jerf 2y 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 2y 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.
  - eklavya 2y ago
    I see what you mean but how is it academically useful to identify transpilers something of their own? It's still compiling (lowering) from one notation to another.
  - randomdata 2y ago
    All compiler outputs are understandable. I suppose you mean with the intent of it being a one-time translation? As in, like when the Go project converted the original C codebase into Go source with the intent of having developers work in the Go output afterwards and the C code to be never touched again? What is meaningful about such a distinction?
  - 2y ago

rowanG077 2y ago

Why would you target Go?

toolz 2y 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.
- aorona 2y ago
  subpar semantics?
- wesselbindt 2y 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.
  - wrs 2y ago
    To name a few things: Excellent and very stable stdlib (if you’re making a networked thing), fast GC optimized for latency, async I/O without any fuss, easy CSP-like concurrency, fast compile time, statically linked binaries, large user community.
  - zer00eyz 2y ago
    GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ----------------------- Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism. As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....

dexwiz 2y ago

Can you use Go modules?

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

eklavya 2y ago

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

Qerub 2y ago

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

HippoBaro 2y 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 2y ago

They made a coffeescript for go

christophilus 2y ago
They made a Typescript for go. Coffeescript was dynamic.
- recursive 2y 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)

philosopher1234 2y 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 2y ago
Elixir compiles to Erlang, I think.
- toolz 2y 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.
- giancarlostoro 2y ago
  Correct Elixir runs on the BEAN.
ARandomerDude 2y ago
CoffeeScript was pretty popular about 10 years ago and did this.
tylerhou 2y ago
C++ used to compile to C.
furyofantares 2y 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.
michaelsbradley 2y ago
Nim compiles to C by default, and it seems most Nim devs stick with that default. Nim hasn’t gained mainstream adoption, though.

eximius 2y 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.

lordofgibbons 2y 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 2y 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 2y 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.
  - drdaeman 2y ago
    > but the main reason why people want them is to fix the error handling Why do you think so? Maybe I'm an odd case, but my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake. Or for state machines. Error handling is manageable without enums (but I love Option/Result types more than Go's error approach, especially with the ? operator).
    - randomdata 2y ago
      > my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake Then what you are really looking for is sum types (what Rust calls enums, but unusually so), not enums. Go does not have sum types, but you can use interfaces to archive a rough facsimile and most certainly to satisfy your specific expectation: type Hot struct{} func (Hot) temp() {} type Cold struct{} func (Cold) temp() {} type Temperature interface { temp() } func SetThermostat(temperature Temperature) { switch temperature.(type) { case Hot: fmt.Println("Hot") case Cold: fmt.Println("Cold") } }

ketralnis 2y 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 2y ago
I think they are calling Rust complex, not complicated. Rust is way more complicated than Go, when we are talking about language features.
itishappy 2y ago
Compared to GCed languages like Go and Borgo? Ownership is non-trivial...
akira2501 2y ago
It's also not as type safe as the graphic implies.
leecommamichael 2y ago
There are no labels on the graph's axes :^)

ralegh 2y 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 2y 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.
- ralegh 2y 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).
- zem 2y ago
  perhaps rescript [https://rescript-lang.org/ https://rescript-lang.org/] even more than typescript
anonzzzies 2y 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.

sevkih 2y ago

So swift?

foolfoolz 2y ago
it looks a lot like java 21+
- 62951413 2y ago
  Java < Kotlin < Scala Golang < Borgo < Rust
  - foolfoolz 2y ago
    i (nearly) wrote only scala for 10 years. if i was starting a project today i would not use scala. its still a great language.

preommr 2y ago

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

odc 2y ago
I love Go's letter casing. It's such a neat way to remove cruft.
- metaltyphoon 2y 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.
  - Groxx 2y ago
    In that case, maybe try: `_ACRNYM`
    - metaltyphoon 2y ago
      Function names with _ ? That’s not for me :)
- phplovesong 2y ago
  It also adds cruft. Public struct members JSON usually needs to be converted to lowercase. Hence the stuct tags.
  - eadmund 2y ago
    JSON is just one tiny part of most programs, sitting on the edge where the program interacts with other programs; it doesn’t permeate the entire codebase. Structure privacy, OTOH, does. Count me in as someone who really enjoys the case-based approach. It’s not the only one which could work, but it does work.
    - 2y ago

a3w 2y ago

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

unshavedyak 2y 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.
akira2501 2y ago
You can read and grok the entire gospec in a week.
- preommr 2y 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.
  - akira2501 2y ago
    The Java specification is bigger because it has to define the entire Virtual Machine where a compiler can target already defined architectures. I'm also not seeing much in the way of "implementation details" in their specification. Can you point out what you mean?
leecommamichael 2y ago

ThouYS 2y ago

wow. this is it!

littlestymaar 2y ago

Many people on HN “Rust syntax is so ugly” rustaceans “I love the Rust syntax so much I want it in Go too”

Scramblejams 2y 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 https://news.ycombinator.com/item?id=36847594
- speed_spread 2y 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_smaller_rust/ https://www.reddit.com/r/rust/comments/j2l9v9/revisiting_a_s...
  - Scramblejams 2y ago
    Yeah, it'd be great to see something come of it. Been a while, though.
pornel 2y 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 2y ago

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

funny_falcon 2y ago
There was one: https://github.com/grumpyhome/grumpy https://github.com/grumpyhome/grumpy Looks like abandoned though.
cardanome 2y 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 https://github.com/zanellia/prometeo You could of course write a bytecode VM in Golang but I guess that defeats the purpose.

rdevsrex 2y 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 2y 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/ https://gleam.run/

ffsm8 2y 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&section=data-r22 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.
- lolinder 2y 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 2y 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 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.
  - ffsm8 2y ago

DerSaidin 2y 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?

eximius 2y ago
No traits, const generics, probably no turbofish equivalent for when inference struggles.
- sushisource 2y ago
  Most importantly: Null pointers still exist (yes I know they technically exist in unsafe Rust, to head off any pedants) Also: No `?` operator
  - jdknezek 2y ago
    There is a `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error-handling-with--operator https://github.com/borgo-lang/borgo?tab=readme-ov-file#error...
    - sushisource 2y ago
      Oh! Cool somehow I missed that
  - skitter 2y ago
    Pedants would say that null pointers exist in safe Rust too.

shepherdjerred 2y ago

I would kill for these languages features in Go

neonsunset 2y 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.
- mdaniel 2y 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)?
  - nrr 2y ago
    That's spelled `dotnet publish -r ${GOOS}-${GOARCH}` with the new ahead-of-time (branded Native AOT) compilation features installed and enabled. It isn't without a whole list of caveats if you're used to Go's way of doing things though. See <https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...> for details.

jjnoakes 2y ago

What's the license?

fl0ki 2y 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?

OJFord 2y 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'.

OJFord 2y 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?

Mawr 2y 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.
- OJFord 2y 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.
leecommamichael 2y 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 2y 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

pdimitar 2y ago

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

himujjal 2y ago
Neovim user detected!

tbrockman 2y 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 https://borgo-lang.github.io/#methods), the new syntax for channels and goroutines (https://borgo-lang.github.io/#channels https://borgo-lang.github.io/#channels), and the `zeroValue()` built-in (https://borgo-lang.github.io/#zero-values-and-nil 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 2y 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.
- fl0ki 2y 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.

Hasnep 2y 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 https://github.com/joshsharp/braid - have: https://github.com/vrok/have https://github.com/vrok/have - oden: https://oden-lang.github.io/ https://oden-lang.github.io/

sharno 2y ago
There was also purescript: https://github.com/andyarvanitis/purescript-native https://github.com/andyarvanitis/purescript-native

owenpalmer 2y 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_boy 2y 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.
- Mawr 2y 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 https://github.com/golang/go/issues/57644 - The community proposal with some comments from the Go team: https://github.com/golang/go/issues/19412 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 https://go.dev/blog/survey2024-h1-results
  - noisy_boy 2y ago
    I guess I should have been more clear that I mean actions that have resulted from the feedback. Sure, the survey brings out the concerns in a structured form, but to anyone who has seen more than a few discussions about Go, the feedback regarding error handling or enum or sum types etc would not have been news. I can't imagine Go team at Google is stunned by developer demand for these things. Question is why there hasn't been a concerted effort to prioritize these top concerns (I will stand corrected if there is already something underway that I'm not aware of). One of the proposals you linked has been raised in 2017 and it is still open with "No one assigned"; same fate for the other item. That doesn't inspire confidence in terms of Go team treating these things as top priority. I think stuff developers are moaning about the most should be top priority but I guess that is just my simpleton thinking. > 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. They have made many changes to the language, some significant ones like Generics (which I would assume was also not an easy problem to solve) while they have largely left the elephant in the room unaddressed i.e. error handling - and the developers deal with that one on a daily basis and I would wager a lot more frequently compared to Generics. If I had to gauge their priority, I would go by where they they are putting their money instead of surveys and proposals. And their priorities seem to be different from what the populace is asking. And that is my point.

peterkos 2y ago

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

lf-non 2y ago

In the same vein, Go+ is also interesting, and its being actively developed. https://goplus.org/ https://goplus.org/

samuell 2y ago
Where's the list of "Awesome Go-derived languages"? :)

throwaway17_17 2y 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.

sevagh 2y ago
[flagged]
- Defletter 2y ago
  Nor yours.
  - sevagh 2y ago
    This kind of pandering horseshit from throwaway accounts add no value and should be downvoted on sight. Especially if you bake self-deprecation into it, "uwu I'm... I'm not sure if a-anybody is going to like my comment..." Just let the good conversation unfold without patronizing meta-commentary. This isn't Reddit.
    - throwaway17_17 2y ago
      Just an aside, this is my only account which I humorously thought I would name throwaway when I made it 5 years ago. I have repeatedly regretted the choice, even if using a better handle I still probably would have posted this. Also, it is not in my typical wheelhouse of comments, but I was on my 3rd scotch and soda, so it’s came out relatively coherent.
    - abdusco 2y ago
      I observed the same thing happen for YouTube videos in the last couple of years and it drives me crazy. I don't need 20 different comments fishing for likes that try hard to compliment something, and point out how this creator does something that others don't. They're everywhere!

vbezhenar 2y ago

No exceptions - no love.

cellularmitosis 2y ago

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

ackseq 2y 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 2y ago

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

mongonews 2y ago

[flagged]

syngrog66 2y 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 2y 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 2y 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 2y 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?