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

301–310 of 559 posts

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

#301

Post by [deleted] »

callc wrote: post #213
Thaxll wrote: post #202

Earlier quoted context omitted.

No one wants try/catch/exception in Go.

Comments like this are what drives me away from Go; comments that enforce a particular belief about how or what features you should or should not use/introduce in your PL. Talking in absolutes is so far removed from a logical arguments and from good engineering. I would appreciate if anyone could recommend a language like Go (static, strong typed, not ancient, good tooling) with a friendly community, that won’t ostra…

[deleted]

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

#302

Post by gpderetta »

__float wrote: post #244
doctor_eval wrote: post #173

Earlier quoted context omitted.

That’s funny, I did it your way for years and ended up considering it a big mistake. Today I use idiomatic names - MyName in Go, myName in JS/JSON, my_name in SQL. There are many reasons but generally speaking, for me, it’s less effort and code is more readable. Curious what your rationale is?

I just ran into this earlier today - it makes navigating code with grep more difficult. I had a YAML file using `some_property_name`, which was turned into `SomePropertyName`, and it's a small annoyance. It's not a huge deal, but it adds friction where some languages have none. (Or alternately, getting reordered in a separate system like `property_name_some`.)

Ease of grepping is one benefit, but for me the main benefit is the cognitive overhead when reading code.

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

#303

Post by marcus_holmes »

nyssos wrote: post #292
BillyTheKing wrote: post #287

Earlier quoted context omitted.

I agree, I don't really understand everyone's issue with err != nil.. it's explicit, and linters catch uncaught errors. Yes the ? operator in Rust is neat, but you end up with a similar issue of just matching errors throughout your code-base instead of doing err != nil..

The problem is that you're forced to have four possible states 1. err != nil, nondefault return value 2. err != nil, default return value 3. err == nil, nondefault return value 4. err == nil, default return value when often what you want to express only has two: either you return an error and there's no meaningful output, or there's output and no error. A type system with tuples but no sum types can only express "and…

this is true, but not a problem. Go's pattern of checking the error on every return means that if an error is returned, that is the return. Allowing routines to return a result as well as an error is occasionally useful.

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

#304

Post by gpderetta »

doctor_eval wrote: post #173
gpderetta wrote: post #112

Earlier quoted context omitted.

The single most productive habit I picked up int the last few years is to always use exactly the same name for the same entity across source files, configs files, database entries, protocol fields, etc.

That’s funny, I did it your way for years and ended up considering it a big mistake. Today I use idiomatic names - MyName in Go, myName in JS/JSON, my_name in SQL. There are many reasons but generally speaking, for me, it’s less effort and code is more readable. Curious what your rationale is?

I have the benefit of writing mostly C++ where there is really no globally agreed idiomatic naming. At $JOB we use snake_case naming for C++ functions and objects (as opposed to types), which also matches the python naming convention we use.

Snake case is not idiomatic for xml, but we still happen to use it for leaf config options.

The main benefit is reducing ambiguity to what maps to what across files. Ease of grepability is also an advantage.

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

#307

Post by AnonymousPlanet »

littlestymaar wrote: post #295
AnonymousPlanet wrote: post #219

Earlier quoted context omitted.

Go is a very opinionated language from it's inception. We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. Maybe it's part of good engineering to keep things simple and not allow hundreds of ways to do something. Maybe the people who use Go are the ones who just want to write and read simple and maintainable code and don't want it to be cluttered with whateve…

> Go is a very opinionated language from it's inception. True. > We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. This is part of the story that Rob Pikes uses to justify how opinionated Go is, but it's a bit stupid given that most language do fine and I've never seen any debates about the code formatting after the very beginning of a project (where it's a…

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 language. It might enlighten you in many other ways. It won't be the last language you learn, but it might be the most fruitful experience.

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

#309

Post by vbezhenar »

randomdata wrote: post #232
Mawr wrote: post #231

Earlier quoted context omitted.

Go doesn't use exceptions as a primary way of handling errors, which is what we're talking about here. Pedantry is not welcome.

It doesn't not use exception handlers as a primary way of handling errors either, though. Go doesn't specify any error handling mechanism. Using exception handlers is just as valid as any other, and even the standard library does it, as noted earlier. The only error-related concept the Go language has is the error type, but it comes with no handling semantics. Which stands to reason as there is nothing special about…

I would be happy if they would add in compiler some thing that'll allow to ignore error return values and in this case compiler would just throw exception^Wpanic from that point. I think it even makes sense for go purists, like you need to handle errors or get panicked. And I'd just mostly ignore errors and will have my sweet exceptions.

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

#310

Post by bootsmann »

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.

Do you really do that in practice, or do you just blindly go 'if err != nil return nil, err'?

Because fundamentally the function you called can return different errors at any point so if you just propagate the error the code paths are in fact not spelled out at all because the function one above in the hierarchy has to deal with all the possible errors two calls down which are not transparent at all.

Post reply on HN