This is a fantastic proof of concept project that answers a question I've been asking: what if there was another language that was designed to fit between Go and Rust? Ideas?
Borgo is a statically typed language that compiles to Go
511–520 of 559 posts
Re: Borgo is a statically typed language that compiles to Go
#512Earlier quoted context omitted.
Aside from "not ancient" Java has everything you want! I'd consider the best tooling (Intellij), static, strongly typed, has enums now (sealed interfaces), composeable error handling, null safety with new module flags, etc. Not sure about the community, but the maintainers I've worked with seemed nice enough. I imagine the community has a lot less ego than rust/go due to the general perception of the language.
I would argue that .NET is better than Java, unless Java has gotten something like Linq since last I used it (which is entirely) possible. For those who do not know: .NET is cross platform, MS has official documentation on how to deploy it in Docker, and it is MIT licensed. And if you want to deploy a backend for your webapp the tersenes can now rival Flask - plus the compiler can cross compile it to any supported pl…
Poor F# always had the most terse web server but no one ever noticed!
Re: Borgo is a statically typed language that compiles to Go
#513Earlier 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!
F# is Elm for front end and backend
Re: Borgo is a statically typed language that compiles to Go
#514Earlier quoted context omitted.
No one wants try/catch/exception in Go.
It's 2024. We need an effective means for error propagation and the battle-tested solutions are try/catch exceptions or Optional types. Go's error handling would have been great in the 1970's, it's not so great now some 50 years later.
Option types as error handling works but it requires proper syntax. Haskell can do it with do-notation and Rust has its special ? operator. Go has boiler-plate.
Re: Borgo is a statically typed language that compiles to Go
#515Earlier quoted context omitted.
If they are really exceptional situations that should never happen, just crash the process. The moment recover was added they become just another error handling mechanism
You would crash the process. But, sometimes it's useful to do a little bookkeeping first.
That's not how recover is used in practice
Re: Borgo is a statically typed language that compiles to Go
#516Earlier quoted context omitted.
> I've said for a while that a language that focused on this sort of "developer experience" but used a GC to be a bit more flexible would probably be enough for a large portion of Rust developers Why then would Go not fit? It prioritizes developer experience (documentation, automatic formatting, etc.) with a GC
Those are only examples of things that I think would be necessary; I didn't intend for them to be treated as comprehensive. There are a decent number of things in Go that make me feel like my day-to-day experience of working in it is not a priority compared to a design goal of simplicity for its own sake. For example, when debugging code I often will comment and uncomment portions of it as I run it repeatedly to try…
Yeah, and the common/un-comment workflow isn't just for debugging but also for trying new things out to see what works.
You're right that judging on the engagement of this post and others in the past there must be a big appetite for a language somewhat like Go but with fundamental differences. It's really quite interesting how Go seems to be so polarizing, they really nailed some things and really missed on others.
Re: Borgo is a statically typed language that compiles to Go
#517Earlier quoted context omitted.
> I've said for a while that a language that focused on this sort of "developer experience" but used a GC to be a bit more flexible would probably be enough for a large portion of Rust developers Why then would Go not fit? It prioritizes developer experience (documentation, automatic formatting, etc.) with a GC
Lack of sum types and not much support for a functional programming style. I am totally uninterested in any modern programming languages (e.g. post 1980s) that only allows me to express AND (product types, e.g. records, tuples) but not OR (sum types)
Oh I agree on those but it seemed the person I was replying to was primarily interested in developer experience (tooling, documentation, etc.), not language features. So I was curious about what was missing from the Go developer experience because that's one thing that's generally regarded as a strength
Re: Borgo is a statically typed language that compiles to Go
#518Earlier quoted context omitted.
> You seem to be under the impression that having exceptions mean people can't handle errors explicitly? Not at all! It's possible , but it's very tedious, and the lazy "catch it in main" option is so easy that in practice when you look at code that uses exceptions people actually don't handle errors explicitly. > It means you can do so MORE granularly. Again, it doesn't just mean that you can ; it means that you wil…
That has nothing to do with having exceptions, Rust just has a good type system (something go doesn't have). But again, handling an error doesn't necessarily prevent bugs. Just because you handled an error doesn't mean the error won't happen in Prod. It just means when it does, you wrote a message for it or custom behavior. Which could be good, or it might be functionally as effective as returning a stack traces mess…
> That has nothing to do with having exceptions
It absolutely does. Checked exceptions sort of half get there too but they are quite rarely used (I think they are used in Android quite well). They were actually removed from C++ because literally nobody used them.
> handling an error doesn't necessarily prevent bugs.
I never made that claim.
> I've never seen people not handle errors that the user could do anything with.
We already talked about "something went wrong" messages. Surely you have seen one of those?
Re: Borgo is a statically typed language that compiles to Go
#519Earlier quoted context omitted.
> "Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error" You're totally misunderstanding what I'm saying. If I have an error the user can act on, I'll make that error message for them. If they can't act on it, I will make a generic catcher and ask them to contact…
> You seem to be under the impression that having exceptions mean people can't handle errors explicitly? Not at all! It's possible , but it's very tedious, and the lazy "catch it in main" option is so easy that in practice when you look at code that uses exceptions people actually don't handle errors explicitly. > It means you can do so MORE granularly. Again, it doesn't just mean that you can ; it means that you wil…
> In a language like Rust there are no unexpected errors
What? Of course there is. Rust added panic! exactly because unexpected errors are quite possible.
Unexpected errors, or exceptions as they are conventionally known, are a condition that arises when the programmer made a mistake. Rust does not have a complete type system. Mistakes that only show up at runtime absolutely can be made.
Re: Borgo is a statically typed language that compiles to Go
#520Earlier quoted context omitted.
I have to disagree. I'm on record here lamenting Go. I've never really enjoyed writing it. When I've had to use it, I've used it. Lately though, I've found a lot more pleasure. And much of that comes from the fact that it does NOT have all these features. The code I write, is going to look like the code written by most other on my team. There's an idiomatic way to write Go, and it doesn't involve those concepts from…
A lot of people said the same about generics, and some even still do. I could barely stand Go before generics, and still don't think they go far enough. From my experience, things I think Go could really benefit from, like I believe it has benefited from generics: * A way to implement new interfaces for existing types and type constraints for custom types, like `impl Trait for T`. This would obsolete most uses of ref…
> From my experience, things I think Go could really benefit from [...] Enums
Obviously it already benefits from enums.
type E int
const (
A E = iota
B
C
)
enum E {
A,
B,
C
}
> especially if the need for exhaustiveness checking
It is true that gc doesn't make any effort to determine how the enums are used, but if it were to it would be a warning like as is seen in many C compilers. As enums are values, not a type, it's not a fault to use them "inappropriately". While it may be all fine and dandy to add such warnings to gc, the Go team has taken a hard line stance that warnings have no place in the compiler. Of course, the external analysis tools like you speak to can still be used to provide these warnings for you. All the information you need is there.
But it seems what you really want is a more expressive type system – specifically sum types. Then you would be able to describe how you expect identifiers to be used without resorting to using generated number values as placeholders. Enums are just a hack to work around a limited type system anyway. If you are going to improve the type system in order to gain improved compilation constraint, you don't need enums anymore.
Rust doesn't have enums and nobody has ever noticed. Hell, many are even somehow convinced it has enums – but it does not. It provides tag-only unions (with, optionally, fully tagged unions) instead. Seemingly that is what you really want in Go as well. And fair enough. It is undeniably the better solution, but at the cost of being more complex to implement.