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

241–250 of 559 posts

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

#241

Post by mixmastamyk »

AnonymousPlanet wrote: post #216
H1Supreme wrote: post #165

Earlier quoted context omitted.

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).

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

> try/catch for more than one call that can throw an exception or including arbitrary lines

You generally need to skip all lines that the exception invalidates. That's why it's a block or conditional.

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

#243

Post by tredre3 »

dgellow wrote: post #228
AnonymousPlanet wrote: post #216

Earlier quoted context omitted.

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

> Is there any good reason for wanting try/catch other than being lazy? In a hot path it’s often beneficial to not have lots of branches for error handling. Exceptions make it cheap on success (yeah, no branches!) and pretty expensive on failure (stack unwinding). It is context specific but I think that can be seen as a good reason to have try catch. Now of course in practice people throw exceptions all the time. But…

> In a hot path it’s often beneficial to not have lots of branches for error handling.

This is true but the branch isn't taken unless there's an error in Go.

Given that the Go compiler emits the equivalent of `if (__unlikely(err != nil)) {...}` and that any modern CPUs are decently good at branch prediction (especially in a hot path that repeats), I find it hard to believe that the cost would be greater than exceptions.

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

#244

Post by __float »

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 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`.)

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

#245

Post by langnutty »

bigstrat2003 wrote: post #177
from-nibly wrote: post #167

Earlier quoted context omitted.

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

I don't really think the sarcastic tone was called for, but the previous poster is right. "I can't name variables in my native language" is objective, but whether or not that's bad is subjective.

Very true but “bad” is always subjective so at least they came up with an evaluation that is binary — either you have capitalization in your language or you don’t, either the analogy fits or it doesn’t.

(Some linguist will point out that Bongo-Bongo has half-capitalization, or half has capitalization).

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

#246

Post by danielscrubs »

samatman wrote: post #189
gr4vityWall wrote: post #186

Earlier quoted context omitted.

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

Very well then: Rust is not the only one to call a variant type / tagged union an enum. It's a nice language feature to have, whatever they decide to call it. It remains a strange choice to refer to this as the true enum, actual enum, real enum, as has started occurring since Rust became prominent. If that's a meaningful concept, it means a set of numeric values which may be referred to by name. This is the original…

Checked the definition. An enum is defined as a set of named constants. Id argue that a set by definition needs to be constrained. If it lacks the constraints/grouping id argue it no longer is a set.

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

#247

Post by tredre3 »

preommr wrote: post #60

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

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

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

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

#248

Post by randomdata »

Mawr wrote: post #240
randomdata wrote: post #232

Earlier quoted context omitted.

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…

You're absolutely technically correct, in the "spherical cow in a vacuum" sense. In reality though, essentially all Go code out there handles errors through the pattern of checking if the error in a `(value, error)` tuple returned from a function is `nil` or not. That is what the discussion here is about - the way errors are handled in a language in practice, not in theory. Therefore, pedantry. Basically, discussions…

That's a lot of pedantry you've got there for someone who claims it is not welcome. Rules for thee, not for me?

But, if you'd kindly come back to the topic at hand:

> That is what the discussion here is about - the way errors are handled in a language in practice, not in theory.

While I'm not entirely convinced that is accurate, I will accept it. Now, how does:

- "That said, suggesting adding exceptions to Go is about as reasonable as adding a GC to Zig."

Relate to that assertion? What does "suggesting adding exceptions to Go" have to do with a common pattern that has emerged?

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

#249

Post by smt88 »

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…

You have the same PL preferences as me. I haven't tried Rust yet, but Kotlin, modern C#, and F# all fit your requirements. Kotlin is closest because it uses the enormous Java ecosystem.

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

#250

Post by randomdata »

unshavedyak wrote: post #208
randomdata wrote: post #187

Earlier quoted context omitted.

Machine code is intended to be written by humans. That was the only way to program computers at one point in time. Given a machine code target, would you say it is product of transpilation or compilation?

I would stand by my original statement, as i don't consider that "intended" or common by modern day standards. Humans hand wrote binary for a while too hah. If it's not clear, these are just my opinions. Not an attempt at an objective fact or anything.

> Humans hand wrote binary for a while too hah.

Like, as in flipping toggle switches? Isn't that just an input device? They were still producing machine code from that switching.

Post reply on HN