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

51–60 of 559 posts

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

#51

Post by ralegh »

Great! Something I've always wanted.

I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly.

Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to refactor loads of stuff.

Like building out of clay and firing the parts you are happy with.

Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.

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

#52

Post by logdahl »

ketralnis wrote: post #46

Rust is not as complicated as the opening graphic indicates. I usually see this meme from less experienced people but I'm frankly surprised to see it from somebody that's capable of writing a compiler in rust .

I think they are calling Rust complex, not complicated. Rust is way more complicated than Go, when we are talking about language features.

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

#53

Post by zer00eyz »

pjmlp wrote: post #24
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…

If Rust was already matured by the time Docker was rewriten from Python, and Kubernetes from Java, I bet that Go wouldn't have been the lucky candidate.

I like rust, I write go.

There was a thread here the other day where a rust dev pointed out that "Rust is the language tokio ate"... https://nullderef.com/blog/rust-async-sync/

Rust is a lot of overhead when go is "good enough" for 99% of what needs to get done. That doesn't mean go is good for everything. I would still rather write Rust than C or C++ or bunch of other languages. Look at a project like Pingora, from cloud flair. Perfect Rust project, bad Go project. Rust is in the kernel, rust is what im looking at for a USB driver. I would not shove go in either of these places.

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

#54

Post by Jtsummers »

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.

No, a transpiler emits code that another system is meant to understand (often another compiler or interpreter). Whether a human can understand it or not is immaterial to the objective of transpiling.

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

#56

Post by rowanG077 »

eximius wrote: post #47
rowanG077 wrote: post #38

Earlier quoted context omitted.

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.

I doubt that's true. In all the years I have never not found a library that can the things I want in C or C++. It doesn't have a package manager but that doesn't mean it doesn't have packages.

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

#57

Post by rowanG077 »

furyofantares wrote: post #49
rowanG077 wrote: post #38

Earlier quoted context omitted.

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

Sure. I'm not knocking the design goal. The same thing could be achieved by having C++ as a target. So why choose go.

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

#58

Post by rowanG077 »

Jtsummers wrote: post #54
markusde wrote: post #28

Earlier quoted context omitted.

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. No, a transpiler emits code that another system is meant to understand (often another compiler or interpreter). Whether a human can understand it or not is immaterial to the objective of transpiling.

But then compilation is the same thing as transpilation as noted.

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

#59

Post by randomdata »

Jtsummers wrote: post #54
markusde wrote: post #28

Earlier quoted context omitted.

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. No, a transpiler emits code that another system is meant to understand (often another compiler or interpreter). Whether a human can understand it or not is immaterial to the objective of transpiling.

Does that imply that a compiler emits code that nothing can understand? Or are you saying that 'transpile' is just another word for 'compile'?
Post reply on HN