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

151–160 of 559 posts

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

#151

Post by akira2501 »

preommr wrote: post #141
akira2501 wrote: post #116

Earlier quoted context omitted.

You can read and grok the entire gospec in a week.

The golang language spec is very sparse on implementation details in comparison to something like the java spec. I don't think the length of the lang spec is a great metric for language simplicity.

The Java specification is bigger because it has to define the entire Virtual Machine where a compiler can target already defined architectures. I'm also not seeing much in the way of "implementation details" in their specification. Can you point out what you mean?

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

#152

Post by aatd86 »

akira2501 wrote: post #113
odc wrote: post #90

Earlier quoted context omitted.

I love Go's letter casing. It's such a neat way to remove cruft.

> It's such a neat way to remove cruft. I don't disagree, the problem I have with it is, I have to pay for that up front and have to factor it into my design immediately. This also combines with the fact that the namespace is very flat with no heirarchy, so, choosing good public names is something I feel like I spend way too much time on. Go is the only language that causes me to pull out a thesaurus when trying to n…

>I just wish I could refactor my way into that state, rather than having to try to nail it up front.

Procrastination looms. :o

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

#153

Post by nrr »

mdaniel wrote: post #149
neonsunset wrote: post #143

Earlier quoted context omitted.

That's what C# offers (except true * Rust-style enums). The latter will be there in one of the future versions and is in an active design phase, which luckily focuses on tagged-union implementation strategy. With that said, you can already easily use one of the Option/Result libraries or write your own structure - switching on either is trivial (though you have to sometimes choose between zero-cost-ness and convenien…

As someone who is "C# curious," but haven't been able to keep up with all the horrific number of rebrands of the "new, open, .net, core, framework", what is the C# equivalent of $(for GOOS in linux darwin; do for GOARCH in amd64 arm64; do dotnet build -o thing_${GOOS}-${GOARCH}; done; done)?

That's spelled `dotnet publish -r ${GOOS}-${GOARCH}` with the new ahead-of-time (branded Native AOT) compilation features installed and enabled.

It isn't without a whole list of caveats if you're used to Go's way of doing things though. See https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...> for details.

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

#154

Post by sushisource »

eximius wrote: post #135
DerSaidin wrote: post #119

I like the graph at the top of the readme as a summary. The rest of the readme focuses on the delta between Go and Borgo. It doesn't say much about the delta between Borgo and Rust. I think the delta there is mainly no lifetimes/ownership?

No traits, const generics, probably no turbofish equivalent for when inference struggles.

Most importantly: Null pointers still exist (yes I know they technically exist in unsafe Rust, to head off any pedants)

Also: No `?` operator

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

#155

Post by norir »

jerf wrote: post #126
jerf wrote: post #63

Earlier quoted context omitted.

There is a phenomenon I have observed many times where you can get a bunch of people in a room and make some statement, in this case, "Compilers are different than transpilers", and everyone around the table will nod sagely. Yup. We all agree with this statement. But if you dig in, it will turn out that every single one of them has a different interpretation, quite often fatally so to whatever the task at hand is. I…

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 tool. The common colloquial definition of a compiler is a text to machine code (for some definition of machine code) translation whose output is an executable program on a host platform. You can make an argument that every compiler is a transpiler or every transpiler is a compiler, 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. This discussion wouldn't even be happening if transpiler were a completely meaningless term.

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

#156

Post by Matheus28 »

randomdata wrote: post #111
Matheus28 wrote: post #64

Earlier quoted context omitted.

1. Transpilers output to another programming language that is typically written by hand by others (so not assembly). 2. Transpilers don’t typically optimize code, leaving those transformations to the compiler of the target language. 3. Compilers will typically have an internal representation (SSA) which they operate on to optimize. Transpilers typically operate on the AST (because they don’t need to do any but the mo…

> the majority of the reasons on why people make the distinction. You have provided some defining properties that might allow for distinction, but you have not given any reasons for why people make a distinction. But perhaps we can suss it out. Given the statement "Borgo compiles to Go", what important information is lost that would be saved if "Borgo transpiles to Go" was used instead?

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" :)

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

#157

Post by neonsunset »

mdaniel wrote: post #149
neonsunset wrote: post #143

Earlier quoted context omitted.

That's what C# offers (except true * Rust-style enums). The latter will be there in one of the future versions and is in an active design phase, which luckily focuses on tagged-union implementation strategy. With that said, you can already easily use one of the Option/Result libraries or write your own structure - switching on either is trivial (though you have to sometimes choose between zero-cost-ness and convenien…

As someone who is "C# curious," but haven't been able to keep up with all the horrific number of rebrands of the "new, open, .net, core, framework", what is the C# equivalent of $(for GOOS in linux darwin; do for GOARCH in amd64 arm64; do dotnet build -o thing_${GOOS}-${GOARCH}; done; done)?

The sibling comment pretty much sums it up. But if you want more detail, read on:

Generally, there are three publishing options that each make sense depending on scenario:

JIT + host runtime: by definition portable, includes slim launcher executable for convenience, the platform for which can be specified with e.g. -r osx-arm64[0].

JIT + self-contained runtime: this includes IL assemblies and runtime together, either within a single file or otherwise (so it looks like AOT, just one bin/exe). This requires specifying RID, like in the previous option, for cross-compilation.

AOT: statically linked native binary, cross-OS compilation is not supported officially[1] because macOS is painful in general, and WindowsLinux/FreeBSD is a configuration nightmare - IL AOT Compiler depends on Clang or MSVC and a native linker so it is subject to restrictions of those as a start. But it can be done and there are alternate, more focused toolchains, that offer it, like Bflat[1].

If you just want a hello world AOT application, then the shortest path to that is `dotnet new console --aot && dotnet publish -o {folder}`. Otherwise, the options above are selected based on the needs either via build properties or CLI arguments. I don't know which use case you have - let me know if you have something specific in mind ("Just like in Go" may or may not be optimal choice depending on scenario).

[0] https://learn.microsoft.com/en-us/dotnet/core/rid-catalog

[1] https://github.com/bflattened/bflat (can also build UEFI binaries, lol)

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

#158

Post by jimbokun »

eximius wrote: post #105
jimbokun wrote: post #75

Earlier quoted context omitted.

DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code. I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics a…

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.

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

#159

Post by lolinder »

Matheus28 wrote: post #156
randomdata wrote: post #111

Earlier quoted context omitted.

> the majority of the reasons on why people make the distinction. You have provided some defining properties that might allow for distinction, but you have not given any reasons for why people make a distinction. But perhaps we can suss it out. Given the statement "Borgo compiles to Go", what important information is lost that would be saved if "Borgo transpiles to Go" was used instead?

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, but it's been a challenge for him to grasp.

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

#160

Post by mdaniel »

nrr wrote: post #153
mdaniel wrote: post #149

Earlier quoted context omitted.

As someone who is "C# curious," but haven't been able to keep up with all the horrific number of rebrands of the "new, open, .net, core, framework", what is the C# equivalent of $(for GOOS in linux darwin; do for GOARCH in amd64 arm64; do dotnet build -o thing_${GOOS}-${GOARCH}; done; done)?

That's spelled `dotnet publish -r ${GOOS}-${GOARCH}` with the new ahead-of-time (branded Native AOT) compilation features installed and enabled. It isn't without a whole list of caveats if you're used to Go's way of doing things though. See https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... > for details.

You're very kind, thank you

For others wanting to play along at home:

  $ docker run --name net8 --rm -it mcr.microsoft.com/dotnet/sdk:8.0-jammy-arm64v8 bash -c '
  cd /root
  dotnet new -d -o console0 console
  cd console0
  dotnet publish --nologo --self-contained -v d -r osx-arm64 -o console0-darwin-arm64
  sleep 600
  '
although it didn't shake out

  $ docker cp net8:/root/console0/console0-darwin-arm64/console0 ./console0
  $ ./console0
  Killed: 9
I tried with and without --self-contained and the biggest difference was that self-contained emitted a bazillion .dll files and without just emitted the binary. I case the context isn't obvious, $(dotnet new console) is a skeleton for the infamous WriteLine("Hello, World") without doing crazy whacko stuff
Post reply on HN