Live data from Hacker News

Borgo is a statically typed language that compiles to Go

github.com

381–390 of 559 posts

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

#381

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…

[deleted]

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

#383
post #354

Earlier quoted context omitted.

Also known as The Apple Answer. Plenty of The Go Way arguments apply to software we were writing from the dawn of computing until the 1990's, and there are plenty of reasons why, with exception of Go (pun intended), the industry has moved beyond that.

I nearly wrote "you are holding it wrong" to nod to that quote. But it is really true - most errors in long running services are individual and most applications I've worked in ignore this when (ab)using exceptions. In our Go codebases, the error reporting and subsequent debugging and bug fixing is night and day from our Python, Perl, Ruby, PHP, Javascript, and Elixir experiences. The one glaring case where this is u…

The same applies for literally any language if you care about error handling except it's way more ergonomic to do. Why do go users try to pass off the lack of language features as as if that's the reason why they care about writing quality code?

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

#384

Earlier quoted context omitted.

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.

I actually really have a disrespect for them. I'm in a constant fight against developers that want to translate code in almost the same code but "only using language features from the Advanced book". I also wanted to add that I used inheritance only ONCE in all my years of writing Python in all other millions of lines of code inheritance was not the best solution. This is my daily struggle as a CTO. People using waaa…

It's one thing to want your devs to produce readable code -- as a former CTO I also spent significant effort in teaching people that -- but it's completely another to be a curmudgeon and directly disregard valuable programming tools like the sum types.

Not sure why you are conflating both. Also inheritance was known to be the wrong tool for the job at least 15 years ago, maybe even 20. Back then people wrote Java books that said "prefer composition over inheritance" so your analogy didn't really land.

Everyone who uses sum types in production code agrees they reduce bugs.

Maybe it's time for you to retire.

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

#385
post #273
post #249

Earlier quoted context omitted.

You have the same PL preferences as me. I haven't tried Rust yet, but Kotlin, modern C#, and F# all fit your requirements. Kotlin is closest because it uses the enormous Java ecosystem.

I haven't had time to really try to write anything in it, but https://gleam.run/ looks really good too. Like Elm for backend + frontend!

"+ frontend" only if you squint really hard, I think

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

#386
post #290

Earlier quoted context omitted.

Enums and sum types seem to be related. In the code you wrote, you could alternatively express the Hot and Cold types as enum values. I would say that enums are a subset of sum types but I don't know if that's quite right. I guess maybe if you view each enum value as having its own distinct type (maybe a subtype of the enum type), then you could say the enum is the sum type of the enum value types?

Enums are exactly sums of unit types (types with only one value).

Traditionally, enums have been a single number type with many values (initialized in a counted one-by-one fashion).

Rust enums are as you describe, as they accidentally renamed what was historically known as sum types to enums. To be fair, Swift did the same thing, but later acknowledged the mistake. The Rust community doubled down on the mistake for some reason, now gaslighting anyone who tries to use enum in the traditional sense.

At the end of the day it is all just 1s and 0s. If you squint hard enough, all programming features end up looking the same. They are similar in that respect, but that's about where the similarities end.

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

#387
post #319

I am genuinely appreciative that a post like this, a GitHub link to a semi-slow moving, but clearly well considered and sincerely developed programming language, can not only remain on the front page of HN, but can generate a diverse and interesting group of discussions. It’s material like this that keeps me coming back to the site. I’m not sure if anyone needed this comment, but I’m sure my posting it isn’t going to…

[flagged]

Nor yours.

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

#388

Earlier quoted context omitted.

>I don't think anyone here is saying we shouldn't have the word "transpiler" at all This thread chain is in response to jerf's comment "transpiler shouldn't be a word" (simplifying his comment for brevity's sake)

Eh, that's one possible reading, but their actual take is more nuanced than that: > 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. In co…

Someone argues that transpiler adds nothing (no nuance) over the original word. And your takeaway is that “I don't think anyone here is saying we shouldn't have the word "transpiler" at all” and that their original post is “more [of] an observation”? Does a person have to be all boorish and say that “you shouldn’t use that word” in order to convince you that they think it’s useless? Anyway this comment (newer than your comment) seems clear enough: https://news.ycombinator.com/item?id=40214781

> 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' or an 'interpreter'?"), but the "transpiler" term is trying to draw a line where there isn't even a seam in the landscape.

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

#389

Earlier quoted context omitted.

Scala is the perfect example of why you want to limit expressivity. It's seems so cool and awesome at first, but then you have to support a code base with other engineers and you quickly come to the view that go's limited expressivity is a blessing. Hilariously I was using a gen AI (phind) and asked it to generate some scala code and it no joke suggested the code in both implematic scala and in java style, and all yo…

Well, flexibility has its price. And yeah, if you need to work in a team that uses a very different style, then you won't like it. On the other hand, if you carefully select your team or work alone, then this is not a problem at all. Btw, there isn't really "one" idiomatic scala style - therefore I tend to believe that you are not familiar with the language and the community.

> Btw, there isn't really "one" idiomatic scala style

That is their point. There's too many styles.

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

#390

Earlier quoted context omitted.

The single most productive habit I picked up int the last few years is to always use exactly the same name for the same entity across source files, configs files, database entries, protocol fields, etc.

That’s funny, I did it your way for years and ended up considering it a big mistake. Today I use idiomatic names - MyName in Go, myName in JS/JSON, my_name in SQL. There are many reasons but generally speaking, for me, it’s less effort and code is more readable. Curious what your rationale is?

I do the same way like you. My logic was that I can tell where the value is coming from. I would use the same type but different name.

Is it coming from a client via http? Then it needs to be checked and saved

The database? then it has an id field which could be null in other cases.

Or I just create a new instance?

Naming things is hard tho, sometimes I do think I should just name them the same and stop caring. I'm not sure if I gain productivity but it gives me some comfort that I can instantly tell the source of the data.

Post reply on HN