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

41–50 of 559 posts

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

#41

Post by eklavya »

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.

I see what you mean but how is it academically useful to identify transpilers something of their own? It's still compiling (lowering) from one notation to another.

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

#42

Post by eximius »

zer00eyz wrote: post #30
wesselbindt wrote: post #10

Earlier quoted context omitted.

I'm not trying to be argumentative, I'm genuinely curious: what is it about the go runtime and tooling that makes them great? I did not post your parent comment.

GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ---------------------…

> 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 average developer doesn't have to do it without framework support.

In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.

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

#43

Post by 2024throwaway »

sleepybrett wrote: post #29
2024throwaway wrote: post #23

Earlier quoted context omitted.

I'm not sure why you included php in your list of examples of things that become bloated with dependencies. I've never seen that be the case.

[flagged]

I just opened the composer.json file for a complex PHP application, it has 20 imports, total.

I just opened the package.json for a react frontend, it has 80 imports.

I just opened the Gemfile for a complex rails application, it has 150+ imports.

But sure, I'm just trolling I guess.

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

#44

Post by furyofantares »

philosopher1234 wrote: post #26

The only language I can think of that has pulled off “compiles to another totaling language” and gained mainstream adoption is typescript, and I’m sure it wouldn’t have done so if it were possible to run in the browser otherwise. Can anyone think of another example?

C++ is for sure gonna be the biggest example. I think Objective-C too.

There's other successful but not "mainstream" languages that might count or semi-count, like Clojure targeting the JVM (though not Java) and being able to use Java packages, or ClojureScript targeting JavaScript.

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

#45

Post by Thaxll »

wrs wrote: post #25
zer00eyz wrote: post #16

Earlier quoted context omitted.

This is a terrible take. It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use. Most go devs have lived through bloated java/php/python/ruby/js projects that become a pile of dependencies. Go is to coding what brutalism is to architecture. Simple, functional, efficient. Dont build a massive dependency chain, dont build magic, repeating yourself is OK. Be an…

I don’t think any of that is contradicted by what this seems to be trying to do. In fact, Go doesn’t make you deal with your errors (you’re free to ignore the returns) whereas this would (via exhaustive pattern match).

Rust does not enforce error checking either.

You can ignore errors in Rust.

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

#47

Post by eximius »

rowanG077 wrote: post #38
theamk wrote: post #7

Earlier quoted context omitted.

it's literally the 2nd sentence of README: "It's fully compatible with existing Go packages." It's a nice way to bootstrap ecosystem IMHO. No one wants to use a brand-new language without library support for common tasks.

It doesn't make sense that that is the reason. Surely C++ has way more packages. So Go would be a bad choice if package availability was a very important concern.

There is more code written in C++, but there are fewer "C++ packages" in the sense of just doing `go get` and you're ready to use it.

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

#48

Post by eklavya »

rowanG077 wrote: post #38
theamk wrote: post #7

Earlier quoted context omitted.

it's literally the 2nd sentence of README: "It's fully compatible with existing Go packages." It's a nice way to bootstrap ecosystem IMHO. No one wants to use a brand-new language without library support for common tasks.

It doesn't make sense that that is the reason. Surely C++ has way more packages. So Go would be a bad choice if package availability was a very important concern.

It doesn't make sense when you use this reasoning on established languages like C++ and Go. Makes all the difference when you are less than a year old language.

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

#49

Post by furyofantares »

rowanG077 wrote: post #38
theamk wrote: post #7

Earlier quoted context omitted.

it's literally the 2nd sentence of README: "It's fully compatible with existing Go packages." It's a nice way to bootstrap ecosystem IMHO. No one wants to use a brand-new language without library support for common tasks.

It doesn't make sense that that is the reason. Surely C++ has way more packages. So Go would be a bad choice if package availability was a very important concern.

> I want a language for writing applications that is more expressive than Go but less complex than Rust.

> Go is simple and straightforward, but I often wish it offered more type safety. Rust is very nice to work with (at least for single threaded code) but it's too broad and complex, sometimes painfully so.

It seems clear that the author really likes aspects of both Go and Rust and desires something between the two. Check out the complexity vs type-safety illustration at the top of the page, with Borgo placed between the Gopher and the Crustacean just before the complexity curve gets steep.

They're basically building their personal ideal version of Go with inspiration from Rust.

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

#50

Post by randomdata »

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.

All compiler outputs are understandable. I suppose you mean with the intent of it being a one-time translation? As in, like when the Go project converted the original C codebase into Go source with the intent of having developers work in the Go output afterwards and the C code to be never touched again?

What is meaningful about such a distinction?

Post reply on HN