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

361–370 of 559 posts

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

#361

Post by valenterry »

anthonyskipper wrote: post #355
valenterry wrote: post #346

Earlier quoted context omitted.

I'd say Scala. It has its flaws, but the latest version (Scala 3) is really really good. The community is open to different styles of programming - from using it as a "better Java" to "pure functional programming like in Haskell".

Scala is the perfect example of why you want to limit expressivity. It's seems so cool and awesome at first, but then you have to support a code base with other engineers and you quickly come to the view that go's limited expressivity is a blessing. Hilariously I was using a gen AI (phind) and asked it to generate some scala code and it no joke suggested the code in both implematic scala and in java style, and all yo…

Well, flexibility has its price. And yeah, if you need to work in a team that uses a very different style, then you won't like it.

On the other hand, if you carefully select your team or work alone, then this is not a problem at all.

Btw, there isn't really "one" idiomatic scala style - therefore I tend to believe that you are not familiar with the language and the community.

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

#362

Post by anonzzzies »

ralegh wrote: post #92
anonzzzies wrote: post #77

Earlier quoted context omitted.

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

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

We don’t necessarily do good lisp things; we use Common Lisp because macros and easy DSLs allows us to use CL for everything we do while using, for us, the best dev and debugging env in the world. So we want to do the exploration, building, debugging all in CL and after that compile, possibly, to something better depending. We trade for that a little bit of inconvenience (as in; leaky abstraction), but it’s worth it the past 30+ years.

For learning cl, the reddit lisp subreddit is good and has the current best ones on it. Lately there is a guy making a gui (clog) who is doing good work for spreading general lisp love by making it modern. Including tutorials. And there are others too.

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

#363

Post by AnonymousPlanet »

SomeoneFromCA wrote: post #356
AnonymousPlanet wrote: post #307

Earlier quoted context omitted.

Seriously, if you feel patronised by how someone designs a programming language, it might be best to move on. It's obviously not for you. Especially when you feel compelled to bad faith assumptions and ageism over it. For those who want to feel the wind of coding freedom blow through their hair, I can recommend to spend some time learning Lisp. It offers the most freedom you can possibly have in a programming languag…

Most of people who tend to brag about Lisp's (Common Lisp) superiority, never actually used it. It is not as impressive as many legends claim.

Can you name a language that provides more freedoms? I used Lisp as an example for that side of the spectrum because I'm familiar with it, having used it for many years in the past. But maybe there are better examples.

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

#364

Post by melodyogonna »

littlestymaar wrote: post #344
melodyogonna wrote: post #333

Earlier quoted context omitted.

Rob Pike... and Ken Thompson, and Robert Grisemer. Firstly, Ken Thompson is a master at filtering out unnecessary complexities and I highly rate his opinion of the important and unimportant things. Secondly, the Go team were never against generics, the three early designers agreed the language needed generics but they couldn't figure out a way to add it orthogonally. Go has gone on to be very successful in cloud and…

> Secondly, the Go team were never against generics, the three early designers agreed the language needed generics but they couldn't figure out a way to add it orthogonally. This is a PR statement that has been introduced only after Go generics landed, for years generics were dubbed “unnecessary complexity” in user code (Go has had generics from the beginning but only for internal use of the standard library). > Go h…

70% of cloud tools on CNF are built with Go; Kubernetes is just one of many. Also, since Kubernetes was originally started as a Java project you should consider whether the team was trying to code more with Java idioms than with Go ones.

Nodejs has been more successful than Go in cloud?

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

#365

Post by sethammons »

pjmlp wrote: post #354
sethammons wrote: post #341

Earlier quoted context omitted.

I would have to go through my comment history for exact numbers. In analyzing a real, production service written in Go where multiple dozens of contributors over hundreds of thousands of lines over several years, "naked" if-err-return-err made up less than 5% of error handling cases and less than 1% of total lines. Nearly every error handling case either wrapped specific context, emitted a log, and/or emitted a metri…

Also known as The Apple Answer. Plenty of The Go Way arguments apply to software we were writing from the dawn of computing until the 1990's, and there are plenty of reasons why, with exception of Go (pun intended), the industry has moved beyond that.

I nearly wrote "you are holding it wrong" to nod to that quote. But it is really true - most errors in long running services are individual and most applications I've worked in ignore this when (ab)using exceptions.

In our Go codebases, the error reporting and subsequent debugging and bug fixing is night and day from our Python, Perl, Ruby, PHP, Javascript, and Elixir experiences.

The one glaring case where this is untrue is in our usage of Helm which, having been written in Go, I would expect better error handling. Instead we get, "you have an error on line 1; good luck" - and, inspired, I looked at their code just now. Littered with empty if-err-return-err blocks - tossing out all that beautiful context, much like an exception would, but worse.

https://github.com/search?q=repo%3Ahelm%2Fhelm%20%20if%20err...

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

#366

Post by skitter »

sushisource wrote: post #154
eximius wrote: post #135

Earlier quoted context omitted.

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

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

Pedants would say that null pointers exist in safe Rust too.

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

#367

Post by gwd »

foldr wrote: post #339
LinXitoW wrote: post #328

Earlier quoted context omitted.

Just because you can adapt to verbosity does not make it a good idea. I've gotten used to Javas getter/setter spam, does that make it a good idea? Moreover, don't you think that something like Rusts ? operator wouldn't be a perfect solution for handling the MOST common type of error handling, aka not handling it, just returning it up the stack? val, err := doAThing() if err != nil { return nil, err } VERSUS val := do…

I personally have mixed feelings about this. I think a shortcut would be nice, but I also think that having a shortcut nudges people towards using short-circuit error handling logic simply because it is quicker to write, rather than really thinking case-by-case about what should happen when an error is returned. In production code it’s often more appropriate to log and then continue, or accumulate a list of errors, o…

This. Golang's error handling forces you to think about what to do if there's an error Every Single Time. Sometimes `return err` is the right thing to do; but the fact that "return err" is just as "cluttered" as doing something else means there's no real reason to favor `return err` instead of something slightly more useful (such as wrapping the err; e.g., `return fmt.Errorf("Attempting to fob trondle %v: %w", trondle.id, err)`).

I'd be very surprised if, in Rust codebases, there's not an implicit bias against wrapping and towards using `?`, just to help keep things "clean"; which has implications not only for debugging, but also for situations where doing something more is required for correctness.

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

#368

Post by randomdata »

lelanthran wrote: post #276
randomdata wrote: post #239

Earlier quoted context omitted.

> Enums and sum types seem to be related. They can certainly help solve some of the same problems. Does that make them related? I don't know. By definition, an enumeration is something that counts one-by-one. In other words, as is used in programming languages, a construct that numbers a set of named constants. Indeed you can solve the problem using that: type Temperature int const ( Hot Temperature = iota Cold ) fun…

Unfortunately, this: const ( Hot Temperature = 0 Cold Temperature = 1 ) Isn't really a good workaround when lacking an enumeration type. The compiler can't complain when you use a value that isn't in the list of enumerations. The compiler can't warn you when your switch statement doesn't handle one of the cases. Refactoring is harder - when you add a new value to the enum, you can't easily find all those places that…

> Isn't really a good workaround when lacking an enumeration type.

Enumeration isn't a type, it's a numbering construct. Literally, by dictionary definition. Granted, if you use the Rust definition of enum then it is a type, but that's because it refers to what we in this thread call sum types. Rust doesn't support "true" enums at all.

> The compiler can't complain when you use a value that isn't in the list of enumerations.

Well, of course. But that's not a property of enums. That's a property of value constraints. If Go supported value constraints, then it could. Consider:

    type Temperature 0..1

    const (
        Hot  Temperature = 0
        Cold Temperature = 1 
    )
Then the compiler would complain. Go lacks this in general. You also cannot define, say, an Email type:

    type Email "{string}@{string}"
Which, indeed, is a nice feature in other languages, but outside of what enums are for. These are separate concepts, even if they can be utilized together.

> Enums are a big thing I miss when writing Go, compared to when writing C.

Go has enums. They are demonstrated in the earlier comment. The compiler doesn't attempt to perform any static analysis on the use of the use of the enumerated values because, due to not having value constraints, "improper" use is not a fatal state[1] and Go doesn't subscribe to warnings, but all the information you need to perform such analysis is there. You are probably already using other static analysis tools to assist your development. Go has a great set of tools in that space. Why not add an enum checker to your toolbox?

[1] Just like it isn't in C. You will notice this compiles just fine:

    typedef enum {
        Hot,
        Cold
    } Temperature;

    void setThermostat(Temperature temperature) {
        switch (temperature) {
        case Hot:
            printf("Hot\n");
        }
    }

    int main() {
        setThermostat(10);
    }

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

#369

Post by brainzap »

sethammons wrote: post #342
mark38848 wrote: post #324

Earlier quoted context omitted.

How the fuck do you release a language without enums?

Can someone help me understand why enums are needed? They only seem like sugar for reducing a few lines while writing. What cannot be achieved without them or what is really a pain point they solve? Maybe it is hard to have a constant with type information?

The original enum are just enumerated integer constants.

What people want "the ability to express enums with an associated value", I think we should invent a new term.

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

#370

Post by Keats »

groestl wrote: post #211
from-nibly wrote: post #167

Earlier quoted context omitted.

How is "i cant name variables in my native language" subjective?

True, as a non-native speaker: naming variables in a native language (that's not English) is objectively bad.

So if you have a concept that doesn't have an equivalent in English you just kinda translate it and add a comment for other people of your language to understand what it is?
Post reply on HN