They made a coffeescript for go
Borgo is a statically typed language that compiles to Go
21–30 of 559 posts
Re: Borgo is a statically typed language that compiles to Go
#22Reminds me of this previous effort to build upon Go but add a more flexible type system: https://github.com/oden-lang/oden
Re: Borgo is a statically typed language that compiles to Go
#23Earlier quoted context omitted.
It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.
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'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.
Re: Borgo is a statically typed language that compiles to Go
#24Earlier quoted context omitted.
It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.
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.
Re: Borgo is a statically typed language that compiles to Go
#25Earlier quoted context omitted.
It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.
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).
Re: Borgo is a statically typed language that compiles to Go
#26The 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?
Re: Borgo is a statically typed language that compiles to Go
#27The 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?
Elixir compiles to Erlang, I think.
Re: Borgo is a statically typed language that compiles to Go
#28Is it correct to say Borgo "compiles to Go", or should it say "transpiles to Go" It appears to be a transpiler (consumes a Borgo and does the work to convert and emit a Go program as text): https://github.com/borgo-lang/borgo/blob/main/compiler/src/c...
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.
Re: Borgo is a statically typed language that compiles to Go
#29Earlier 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'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]
Re: Borgo is a statically typed language that compiles to Go
#30Earlier quoted context omitted.
It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.
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.
-----------------------
Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism.
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. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....