but go already has generics https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
Go actually has generics.
Just not for user-defined methods and types.
Show HN: Fo: An experimental language which adds generics on top of Go
21–30 of 125 posts
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#22Shouldn't it have been called Ho ?
And then we can take this, but put it on the JVM, and we end up with Jo!
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#23Interesting, now all you need to do is add exceptions :)
Golang already has an exceptions-equivalent construct in the shape of panic() and recover(): https://blog.golang.org/defer-panic-and-recover You’re free to write exception-full code using those constructs, although the community tends to use error return values for the most part.
This is how I understood the use for panics:
https://stackoverflow.com/questions/44504354/should-i-use-pa...
> You should assume that a panic will be immediately fatal, for
> the entire program, or at the very least for the current
> goroutine. Ask yourself "when this happens, should
> the application immediately crash?" If yes, use a panic;
> otherwise, use an error.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#24You really missed the opportunity here to call your language Foo
Or, "Go" but pronounced "Jo" for Generics.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#25but go already has generics https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
Go actually has generics. Just not for user-defined methods and types.
If you're referring to the map type, that is implemented in plain Go. (Though it does import "unsafe") . There are no generics like you would see in other languages.
https://golang.org/src/runtime/hashmap.go
https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#26Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.
Hi there! I worked on something similar a while ago: a compile-to-Go superset that adds some generic functions/methods. You may have come across it: https://github.com/lukechampine/ply
My perspective was that when I find myself wishing for generics in Go, what I really want is not full-blown generic types and functions, but rather a few helper functions like map/filter/reduce, or converting a map to a slice, etc.
Having "true" generics is undoubtedly useful when you really need them, but the Go ecosystem has shown that they aren't strictly required in order to write large, maintainable programs. And you pay for them in the form of misuse. In that sense, I view generics much the same as operator overloading.
Anyway, I ran into some tricky edge cases when working on Ply and I'm curious how you address them. First, Go lets you define local types, i.e. with a function scope instead of top-level scope. You can't define methods on these, nor can you reference them in top-level functions. How does Fo handle the case where I want to call a generic function/method on a locally-scoped type?
The second issue I ran into was imports. I didn't devote a ton of time to this, but it seemed like it could be tricky to properly fetch both Go and Ply packages and pre-compile the Ply packages to Go. How does Fo handle this?
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#27Earlier quoted context omitted.
Go actually has generics. Just not for user-defined methods and types.
If you're referring to the map type, that is implemented in plain Go. (Though it does import "unsafe") . There are no generics like you would see in other languages. https://golang.org/src/runtime/hashmap.go https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
Well, it's not quite fair to say it's "plain Go." The compiler converts expressions like x, ok := m["foo"] into function calls. User-level code can't define syntax sugar like that. Also, the hashmap implementation imports some internal packages, so you can't just copy and paste it. (I would know, because I mostly did copy and paste it for one of my own projects: https://github.com/lukechampine/randmap)
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#28Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.
Did you consider incrementing the first letter instead of decrementing when choosing a name?
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#29This is suuuper cool. I've thought of doing something similar for a while, but I tried approaching it from the "generate Go" angle. I also found the Go syntax too tedious to write a parser for (because I've never written a parser before, nor any kind of compiler, so the learning curve was too steep). So I was just going to try to build a simple, expression-based language that compiled to (and interoped with) Go. Unfo…
One approach would be to use the existing Go parser packages and modify them to suit your needs. Unfortunately (last time I checked) the standard library packages for this (go/ast, go/types, etc.) differ from the actual packages used by the Go compiler. But they might be close enough to suit your needs.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#30Interesting, now all you need to do is add exceptions :)
Perhaps. But if Go itself adds exceptions they're going to have to catch a MassDeveloperExodusException.
The standard reason I see for people wanting exceptions in Go is because they're sick of writing the following:
```go
thing, err := things.New()
if err != nil {
log.Fatalln(err.Error()) // Or `return err`
```
But I would argue that it means they're not writing idiomatic go. A good reference for the value of error values is this go blogpost[0]. The HN discussion[1] of that post was also interesting, I like this comment in particular:
> In Go I not infrequently make use of a non-nil value AND a non-nil error. A canonical example of this is the io.Reader interface in Go's standard library [1]. I think it is a very useful idiom particularly when dealing with things where failure is more normal - e.g. dealing with network services, disk IO, decoding partially corrupt exif data from images. Often you want a best-effort at the value even if you run into problems.
Handling every error from every function that returns an error can be verbose. But for that verbosity you get a much easier to understand failure model, and the tools (defer) to handle failures reliably no matter what comes up. Exceptions are part of the reason that RAII is so critical in the C++ world.