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

191–200 of 559 posts

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

#191

Post by gergo_barany »

lolinder wrote: post #159
Matheus28 wrote: post #156

Earlier quoted context omitted.

In that statement, it doesn't really add anything. In the statement "XYZ is a compiler/transpiler", it does. It doesn't hurt to have a word that is more specific than others. Otherwise we should just refer to compilers as an "app" :)

I don't think anyone here is saying we shouldn't have the word "transpiler" at all, just that "transpiler" is a subcategory of "compiler" and there's no reason for OP to try to correct the title of this story. It reminds me of how my 5-year-old son always corrects me when I tell him to get in the car—"you mean the van!". I have tried to explain to him that a minivan is a kind of car, and he's just about getting it, b…

We shouldn't have the word "transpiler" at all.

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

#192

Post by eximius »

jimbokun wrote: post #158
eximius wrote: post #105

Earlier quoted context omitted.

I've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, str…

The autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.

code generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice.

But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc

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

#193

Post by pdimitar »

jurschreuder wrote: post #174
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've never needed either. Try/catch is super confusing because the catch is often far away from the try. And in Python I just put try/catch around big chunks of code just in case for production. I think Go is more stable and readable because they force you not to use the lazy unreadable way of error handling. Enums I honestly never used in Go also not the not-type-safe ones. But I'm also someone who used interfaces i…

Your comment could have been a nice opinion that proves to a drive-by reader that needs can differ drastically between programmers.

But you ruined it with "fancy things" which shows offhand disregard and disrespect.

A question like "what do you need these features for?" would have been a better contribution to the forum.

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

#195

Post by eximius »

zer00eyz wrote: post #80
eximius wrote: post #42

Earlier quoted context omitted.

> As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the avera…

Wow, that's a pretty good take. There is a line here though. I think a lot of people have seen what happens when you set a bunch of JR devs loose in a node/ruby code base with all that tooling. It goes about as well as giving a lead footed suburbanite an F1 car. If you work in an agency (new every week) or in a place where you have a high number of jr devs then a framework makes a fair bit of sense. But at that point…

My experience is that there is a great, big in-between where folks are just chugging along and aren't thinking about project/codebase level architectural decisions. Without that active thought and foresight, you end up shooting yourselves in the foot, a bit. With DI frameworks, the _default_ ends up typically being the right thing to do so it unburdens people from a particular slice of cognitive load.

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

#196

Post by philwelch »

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.

Actually, I can understand assembly.

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

#197

Post by andyferris »

blueberry87 wrote: post #190
randomdata wrote: post #182

Earlier quoted context omitted.

> my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake Then what you are really looking for is sum types (what Rust calls enums, but unusually so), not enums. Go does not have sum types, but you can use interfaces to archive a rough facsimile and most certainly to satisfy your specific expectation: type…

annoyingly go can't have proper sum types, as the requirement for a default value for everything doesn't make any sense for sum types

You can just default to the first variant, no?

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

#198

Post by Mawr »

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.

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

#199

Post by pornel »

littlestymaar wrote: post #81

Many people on HN “Rust syntax is so ugly” rustaceans “I love the Rust syntax so much I want it in Go too”

There’s no contradiction here.

Rust’s syntax looks alien to people who are not familiar with it, but the syntax itself is fine.

Some users also blame Rust’s syntax for being complicated when they actually struggle with Rust’s semantics, e.g. borrow checking wouldn’t be any less strict if Rust chose a less weird sigil for lifetime labels.

Post reply on HN