I liked certain aspects of Go, but lack of generics was a deal-breaker for me. You approached it a way better than I (and many others) did. Instead of arguing on forums you started writing code.
Isn't interface{} a generic?
Show HN: Fo: An experimental language which adds generics on top of Go
31–40 of 125 posts
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#32Re: Show HN: Fo: An experimental language which adds generics on top of Go
#33I liked certain aspects of Go, but lack of generics was a deal-breaker for me. You approached it a way better than I (and many others) did. Instead of arguing on forums you started writing code.
Isn't interface{} a generic?
That's reflection not generics. It's mostly the same denotational semantics, but much less efficient performance.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#34Interesting, 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 erro…
On HN, you can quote code by prepending each line with four spaces, but there is no syntax highlighting.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#35Re: Show HN: Fo: An experimental language which adds generics on top of Go
#36I liked certain aspects of Go, but lack of generics was a deal-breaker for me. You approached it a way better than I (and many others) did. Instead of arguing on forums you started writing code.
Isn't interface{} a generic?
No, you have to use reflection to determine the type at runtime. Generics use the compiler to prove the type at compile time so that the runtime can forego the much-slower reflective code paths.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#37Earlier quoted context omitted.
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 )
When discussing whether go has generics, "plain go" is a reasonable thing to say.
Besides it's a compiler. It's going to take an input in format X and translate it to an output in format Y. That's just what they do. Syntactic sugar debates aside there's still no generics in there.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#38I liked certain aspects of Go, but lack of generics was a deal-breaker for me. You approached it a way better than I (and many others) did. Instead of arguing on forums you started writing code.
Isn't interface{} a generic?
Noooooo! interface{} is a raw type. It’s like “Object” in java land. It has no meaning in its own right, and needs to be carefully checked whenever you want to actually use it. The proliferation of interface{} across the go ecosystem is really unfortunate, and will be hard to correct once generics are finally supported.
I haven’t dug too far into the Fo code yet, but I’d guess that it’s doing something akin to type erasure in Java, and adding conversions and type checks transparently when compiling down to a go binary. Sort of like how if you ever pop open a class file and dig into it, you’ll never see any references to generics. Everything compiles down to objects in the end with generated type checks.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#39This 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.
Didn't know that the compiler itself isn't using the same packages after going in a bootstrapped fashion.
Using the existing packages is a great approach as I think that Go standard library has one of the best packages supported for AST/lexing/parsing family, in comparison to Python and Ruby. Haven't worked with Rust.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#40Earlier quoted context omitted.
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 erro…
On HN, you can quote code by prepending each line with four spaces, but there is no syntax highlighting.
Thanks for the tip, but I avoid that because it ruins readability on mobile IMO.