You really missed the opportunity here to call your language Foo
Or, "Go" but pronounced "Jo" for Generics.
Or Ge?
Show HN: Fo: An experimental language which adds generics on top of Go
51–60 of 125 posts
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#52Earlier quoted context omitted.
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. In Java, say, exceptions are the standard for rai…
If want (and if it makes sense) you can use panics as a control flow mechanism to quickly bubble up errors inside your implementations.
See an example in the standard library itself: https://golang.org/src/encoding/json/encode.go, line 295
What's frowned upon is leaking this out of your package's interface/contract.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#53Earlier quoted context omitted.
No, interface {} is more like void pointers in C and C++ or Object in C# and Java. It can hold values of any type. One of the major selling points of actual generics is that they provide type safety, but interface {} doesn't provide that.
Go type assertions are quite safe on the other hand, unlike C type casts. The only thing generics will do is to avoid that extra assertion step and the bit of overhead that's involved in that. You could argue wether it will actually increase readability of your code.
Generics (when used/implemented correctly) provide way more than just elimination of type assertions. It provides compile-time type safety, rather than runtime safety. It also provides elimination of the overhead (which isn't trivial, reflection is not inconsequential) and boilerplate code. It also allows you to use the same function/method for many different types without having to resort to boxing everything to an interface/object.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#54You really missed the opportunity here to call your language Foo
Or Goo.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#55Nice work. But, serious question - When going with parameterized types I know from Haskell how you always end up needing one more language extension and always end up banging your head against the wall that separates types and values a little more. At least if you're not a math genius, but probably even then.
And from Java I know that there's a pretty trivial example that showcases how its Generics implementation is unsound when mixed with inheritance.
And I know that the Go maintainers have been hesitant for a long time because they didn't know a good version of Generics to add.
So, is there any version that just works, and never leads the user down any rabbit holes? And that doesn't lead to ever increasing type boilerplate?
Because I've been super happy ever since I decided that worrying about occasional usage of void pointers in C is just not worth my time. And where configurability is really needed, function pointers are totally fine - I don't think there is any need for static polymorphic dispatch (function pointers are probably even preferable, to avoid bloated machine code).
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#56Earlier quoted context omitted.
Isn't interface{} a generic?
That's reflection not generics. It's mostly the same denotational semantics, but much less efficient performance.
I think it's more than that. You wouldn't commit code that doesn't compile. Your entire organization, however, will troubleshoot the code that fails on runtime in production.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#57Earlier quoted context omitted.
Go type assertions are quite safe on the other hand, unlike C type casts. The only thing generics will do is to avoid that extra assertion step and the bit of overhead that's involved in that. You could argue wether it will actually increase readability of your code.
Generics (when used/implemented correctly) provide way more than just elimination of type assertions. It provides compile-time type safety, rather than runtime safety. It also provides elimination of the overhead (which isn't trivial, reflection is not inconsequential) and boilerplate code. It also allows you to use the same function/method for many different types without having to resort to boxing everything to an…
Depending on the implementation, too, generics can be more friendly in other ways. C# emits code for both value types and reference types when appropriate and uses the correct paths as needed.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#58Nice work. But, serious question - When going with parameterized types I know from Haskell how you always end up needing one more language extension and always end up banging your head against the wall that separates types and values a little more. At least if you're not a math genius, but probably even then. And from Java I know that there's a pretty trivial example that showcases how its Generics implementation is…
CLU was the first language to implement generics in 1975.
There are many levels of generic capabilities, across multiple languages in about 45 years of research, we don't need the full shop, CLU generics would already be quite usefull versus interface{} everywhere.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#59Earlier quoted context omitted.
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.
panic() and recover() are not meant to be used like Java or C++ exceptions.
The phrase "are able to be" is more effectual than the phrase "are not meant to be" when it comes to how people use programming languages in the real world. If it's possible to build a Go system using only panic/recover and defer, just as it is using only interface{}, then there's some people who will use them that way.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#60You really missed the opportunity here to call your language Foo
A dynamically-typed addon for the language "Fo" could be called "Foo" (to rhyme with "Groo").