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

Borgo is a statically typed language that compiles to Go

github.com

Post reply on HN
Print view View original

491–500 of 559 posts

Re: Borgo is a statically typed language that compiles to Go

#491

Post by yencabulator »

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}

Re: Borgo is a statically typed language that compiles to Go

#492

Post by OJFord »

Mawr wrote: post #198
OJFord wrote: post #146

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

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.

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.

Re: Borgo is a statically typed language that compiles to Go

#493

Post by foolfoolz »

62951413 wrote: post #220
foolfoolz wrote: post #212

Earlier quoted context omitted.

it looks a lot like java 21+

Java Golang < Borgo < Rust

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.

Re: Borgo is a statically typed language that compiles to Go

#494

Post by paddim8 »

mdaniel wrote: post #453
4star3star wrote: post #415

Earlier quoted context omitted.

What does Java offer that dotnet does not?

libraries, and I thank God I don't have to work on Windows and thus don't know how smart Visual Studio Enterprise is, but IJ is world class in the number of bugs it'll catch

What? You don't have to work on Windows with .net either and there is an IntelliJ IDE for C#.

Re: Borgo is a statically typed language that compiles to Go

#495

Post by throwaway894345 »

4star3star wrote: post #435
throwaway894345 wrote: post #332

Earlier quoted context omitted.

In Go, no one really blindly returns nil, err. People very clearly think about errors—if an error may need to be actioned on up the stack, people will either create a named error value (e.g., `ErrInvalidInput = errors.New(“invalid input”)` or a named error type that downstream users can check against. Moreover, even when propagating errors many programmers will attach error context: `return nil, fmt.Errorf(“searching…

Coming from dotnet, I rather like the Go pattern as you've described it. I would normally catch and error and then write out a custom message with relevant information, anyway, and I hate the ergonomics of the try{}catch(Exception ex){} syntax. And yes, it is tempting to let the try block encompass more code than it really should.

Yeah, I was pretty skeptical when they added the error wrapping stuff to the standard library, and it still feels a little too squishy, but in practice it works very well. I prefer Go’s error handling even to Rust’s much more explicit error handling.

Re: Borgo is a statically typed language that compiles to Go

#496

Post by demi56 »

randomdata wrote: post #484
demi56 wrote: post #465

Earlier quoted context omitted.

You’re just complaining because the compiler isn’t complaining

And you're panicking because the other commenters haven't helped recover for you. Try as you might, sadly they are not here to catch you. No need to throw a fit over it. You are not as exceptional as you think you are.

Dude you tried, there’s no need for 50000 word essay against a sentence

Re: Borgo is a statically typed language that compiles to Go

#497

Post by demi56 »

littlestymaar wrote: post #489
demi56 wrote: post #464

Earlier quoted context omitted.

> I have nothing against Go, it's a tool that does its job fairly well and has very interesting qualities (fast compile time, self-contained binaries, decent performance out of the box), but the religious worship of “simplicity” is really annoying. Typical Gate keeping the gate keepers of simplicity and pretty sure you code 23.5 hours a day on Haskell

> Typical Gate keeping the gate keepers of simplicity and pretty sure you code 23.5 hours a day on Haskell I've no idea what you mean, you should keep your argumentation simpler ;)

Damn that’s a comeback that’s not complicated

Re: Borgo is a statically typed language that compiles to Go

#498

Post by willhslade »

saghm wrote: post #441
tbrockman wrote: post #218

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

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

Is this .Net?

Re: Borgo is a statically typed language that compiles to Go

#499

Post by [deleted] »

demi56 wrote: post #496
randomdata wrote: post #484

Earlier quoted context omitted.

And you're panicking because the other commenters haven't helped recover for you. Try as you might, sadly they are not here to catch you. No need to throw a fit over it. You are not as exceptional as you think you are.

Dude you tried, there’s no need for 50000 word essay against a sentence

[deleted]

Re: Borgo is a statically typed language that compiles to Go

#500

Post by throwaway2037 »

Mawr wrote: post #258
tadfisher wrote: post #229

Earlier quoted context omitted.

Yes, it's the ability to unwind the stack to an exception handler without having to propagate errors manually. Go programs end up doing the exact same thing as "try/catch around multiple lines" with functions that can return an error from any point, and every caller blindly propagating the error up the stack. The practice is so common that it's like semicolons in Java or C, it just becomes noise that you gloss over.

The difference is that all code paths are explicitly spelled out and crucially that the programmer had to consider each path at the time of writing the code. The resulting code is much more reliable than what you end up with exceptions.

I understand your sentiment. The debate of error codes vs exceptions will be debated until the year 3000, and further. One point to consider with exceptions: It is "impossible" to ignore an exception. The function implementation is telling (nay: dictating[!] to) the caller: You cannot ignore this error code. At the very least, you must catch, then discard. Another point this is overlooked in these discussions: Exceptions and error codes can, and do, peacefully co-exist. Look at Python, C#, and Java. In the standard library for all three, there are cases where error codes are used and cases where exceptions are thrown. Another thing about exceptions, especially in enterprise programming, you can add a human readable error message. That is not possible when only returning error codes.

EDIT

Inspired by this comment: https://news.ycombinator.com/item?id=40220147

I forgot about exception stack traces, including "chained" exceptions. These are incredibly powerful when writing enterprise software that commonly has a stack 50+ levels deep.

Post reply on HN