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

391–400 of 559 posts

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

#391

Post by keybored »

markusde wrote: post #28
jerf wrote: post #17

Earlier quoted context omitted.

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

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.

> A transpiler emits code the user is supposed to understand, a compiler does not.

How come Godbolt is so popular? Inspecting compiler output?

Is GCC now officially a transpiler?

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

#392

Post by randomdata »

keybored wrote: post #388
lolinder wrote: post #163

Earlier quoted context omitted.

Eh, that's one possible reading, but their actual take is more nuanced than that: > 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. In co…

Someone argues that transpiler adds nothing (no nuance ) over the original word. And your takeaway is that “I don't think anyone here is saying we shouldn't have the word "transpiler" at all” and that their original post is “more [of] an observation”? Does a person have to be all boorish and say that “you shouldn’t use that word” in order to convince you that they think it’s useless? Anyway this comment (newer than y…

As no internet discussion is complete without a car analogy, car and automobile mean the same thing, but I see no reason why one of those terms needs to go away. Why can't transpiler and compiler peacefully coexist with the same meaning?

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

#393

Post by chx »

randomdata wrote: post #259
thefounder wrote: post #238

Earlier quoted context omitted.

Let’s hope Go never gets try/catch exceptions

func try(fn func()) { fn() } func catch(fn func(any)) { if v := recover(); v != nil { fn(v) } } func throw(v any) { panic(v) } func fail() { throw("Bad things have happened") } func main() { try(func() { defer catch(func(v any) { fmt.Println(v) }) fail() }) } Sorry.

There is evil in this world and then there's ... this :D

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

#394

Post by Mawr »

LinXitoW wrote: post #328
marcus_holmes wrote: post #300

Earlier quoted context omitted.

As an experienced Go dev, this is literally not a problem. Golang code has a rhythm: you do the thing, you check the error, you do the thing, you check the error. After a while it becomes automatic and easy to read, like any other syntax/formatting. You notice if the error isn't checked. Yes, at first it's jarring. But to be honest, the jarring thing is because Go code checks the error every time it does something, n…

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…

Well we are in a discussion thread about a language that does just that :)

I see two issues with the `?` operator:

1. Most Go code doesn't actually do

    return nil, err
but rather

    return nil, fmt.Errorf("opening file %s as user %s: %w", file, user, err)
that is, the error gets annotated with useful context.

What takes less effort to type, `?` or the annotated line above?

This could probably be solved by enforcing that a `?` be followed by an annotation:

  val := doAThing()?("opening file %s as user %s: %w", file, user, err)
...but I'm not sure we're gaining much at that point.

2. A question mark is a single character and therefore can be easy to miss whereas a three line if statement can't.

Moreover, because in practice Go code has enforced formatting, you can reliably find every return path from a function by visually scanning the beginning of each line for the return statement. A `?` may very well be hiding 70 columns to the right.

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

#395

Post by sethammons »

beeboobaa3 wrote: post #383
sethammons wrote: post #365

Earlier quoted context omitted.

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

The same applies for literally any language if you care about error handling except it's way more ergonomic to do. Why do go users try to pass off the lack of language features as as if that's the reason why they care about writing quality code?

to do the same as Go in Python is way more verbose and less ergonomic because you would wrap each line in a try catch.

I can't speak for all Go users, but what I have seen is that the feature set in Go lends itself to code that handles errors, and exceptions simply don't -- I can say this because I've worked in a dozen different production systems for each of perl, python, js, elixir, and php -- I'm left believing that those languages _encourage_ bad error handling. Elixir is way cool with pattern matching and I still find myself wishing for more Go-like behavior (largely due to the lacking type system, which I hear they are working to improve).

I've not used Rust which apparently is the golden standard in the HN sphere

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

#396

Post by keybored »

norir wrote: post #155
jerf wrote: post #126

Earlier quoted context omitted.

2 hours later, I think it's safe to say there are multiple definitions in play that are, if not outright contradictory, certainly not identical. It seems the term is not terribly useful even on its own terms... it is not as well defined as everyone thinks. Ultimately, "compiler" isn't a bright shining line either... I can take anything and shade it down to the point where you might not be sure ("is that a 'compiler'…

> the "transpiler" term is trying to draw a line where there isn't even a seam in the landscape. I don't think you have proven that it is a seamless landscape. In fact, I think that people's definitions have been remarkably consistent in spite of their fuzziness. The heart of what I have read is that most people understand a transpiler to be an intermediate text to text translation whose output is input to another to…

> , but I think it requires a level of willful obtuseness or excessive pedantry to deny that there is something behind the concept of a transpiler.

Transpiler means something. Fuzzily. And it defines and denotes nothing of practical utility.

> This discussion wouldn't even be happening if transpiler were a completely meaningless term

This discussion wouldn’t even be happening if (people like) JS programmers didn’t insist on using terminology that implied some archaic view of technology, like “compilers emit machine code”—the distinction between high- or low-level target languages aren’t interesting anymore, even if it might have been novel to normie programmers in the 90’s or something.

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

#397

Post by keybored »

randomdata wrote: post #392
keybored wrote: post #388

Earlier quoted context omitted.

Someone argues that transpiler adds nothing (no nuance ) over the original word. And your takeaway is that “I don't think anyone here is saying we shouldn't have the word "transpiler" at all” and that their original post is “more [of] an observation”? Does a person have to be all boorish and say that “you shouldn’t use that word” in order to convince you that they think it’s useless? Anyway this comment (newer than y…

As no internet discussion is complete without a car analogy, car and automobile mean the same thing, but I see no reason why one of those terms needs to go away. Why can't transpiler and compiler peacefully coexist with the same meaning?

Automobile should be scrapped before we get to self-driving cars. What’s a self-driving automobile? An autoautomobile? Get outta here!

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

#398

Post by Capricorn2481 »

IshKebab wrote: post #280
FuckButtons wrote: post #268

Earlier quoted context omitted.

The ability to quickly parse, understand and reason about code is not superficial, it is essential to the job. And that is essentially what those verbose blocks of text get in the way of.

The idea that error handling is "not part of the code" is silly though. My impression of people that hate Go's explicit error handling is that they don't want to deal with errors properly at all. "Just catch exceptions in main and print a stack trace, it's fine." Rust's error handling is clearly better than Go's, but Go's is better than exceptions and the complaints about verbosity are largely complaints about having…

> The idea that error handling is "not part of the code" is silly though. My impression of people that hate Go's explicit error handling is that they don't want to deal with errors properly at all. "Just catch exceptions in main and print a stack trace, it's fine."

I'm honestly asking as someone neutral in this, what is the difference? What is the difference between building out a stack trace yourself by handling errors manually, and just using exceptions?

I have not seen anyone provide a practical reason that you get any more information from Golangs error handling than you do from an exception. It seems like exceptions provide the best of both worlds, where you can be as specific or as general as you want, whereas Golang forces you to be specific every time.

I don't see the point of being forced to deal with an "invalid sql" error. I want the route to error out in that case because it shouldn't even make it to prod. Then I fix the SQL and will never have that error in that route again.

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

#399

Post by Capricorn2481 »

Mawr wrote: post #379
bootsmann wrote: post #310

Earlier quoted context omitted.

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.

I don't see how it's possible to do it blindly unless the code gets autogenerated. If you're typing the `if err != nil` then you've clearly understood that an error path is there. There's no requirement for the calling function to handle each possible type of error of the callee. It can, as long as the callee properly wrapped the error, but it's relatively rare for that to be required. Usually the exact error is not…

Their point was writing `if err != nil return nil, err` is the same thing that stack traces from exceptions do, but with even less information. And if that's most of a Golang codebases error handling, it's not a compelling argument against exceptions.

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

#400

Post by randomdata »

keybored wrote: post #397
randomdata wrote: post #392

Earlier quoted context omitted.

As no internet discussion is complete without a car analogy, car and automobile mean the same thing, but I see no reason why one of those terms needs to go away. Why can't transpiler and compiler peacefully coexist with the same meaning?

Automobile should be scrapped before we get to self-driving cars. What’s a self-driving automobile? An autoautomobile? Get outta here!

Humanless carraige.
Post reply on HN