Shouldn't it have been called Ho ?
And then we can take this, but put it on the JVM, and we end up with Jo!
Yo?
Show HN: Fo: An experimental language which adds generics on top of Go
71–80 of 125 posts
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#72The only time I find I need generics is when I'm prototyping things and making lots of changes. Node, Ruby, & Python are great for this. In fact, PHP's associative array is really powerful/sloppy since it can be used as a list, hash/dictionary, iterable, or object. That aside, I don't think I've ever really been bothered by the lack of generics for actual work code.
I've been working full time in Go since 2012. I've never had a use for generics.
And I've read about many people using Go and wishing for generics from day one.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#73The only time I find I need generics is when I'm prototyping things and making lots of changes. Node, Ruby, & Python are great for this. In fact, PHP's associative array is really powerful/sloppy since it can be used as a list, hash/dictionary, iterable, or object. That aside, I don't think I've ever really been bothered by the lack of generics for actual work code.
I've been working full time in Go since 2012. I've never had a use for generics.
How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me.
I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#74The only time I find I need generics is when I'm prototyping things and making lots of changes. Node, Ruby, & Python are great for this. In fact, PHP's associative array is really powerful/sloppy since it can be used as a list, hash/dictionary, iterable, or object. That aside, I don't think I've ever really been bothered by the lack of generics for actual work code.
I've been working full time in Go since 2012. I've never had a use for generics.
One of my first Go programs was based on this image resizer: https://github.com/nfnt/resize/blob/master/resize.go#L109
Do you have any recommendations for how to write this code without generics, without sacrificing performance, and without hundreds of lines of duplicated code?
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#75The only time I find I need generics is when I'm prototyping things and making lots of changes. Node, Ruby, & Python are great for this. In fact, PHP's associative array is really powerful/sloppy since it can be used as a list, hash/dictionary, iterable, or object. That aside, I don't think I've ever really been bothered by the lack of generics for actual work code.
I've been working full time in Go since 2012. I've never had a use for generics.
Try implementing a shared map type where access is protected by a mutex and otherwise works just like Go's builtin map type (which is a generic map type).
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#76Earlier quoted context omitted.
I've been working full time in Go since 2012. I've never had a use for generics.
How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me. I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.
Umm don't? Why are you iterating over unknown types?
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#77Earlier quoted context omitted.
I've been working full time in Go since 2012. I've never had a use for generics.
How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me. I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.
Go can statically type check hash maps, arrays, and channels. If you want some other container type it must be written with a concrete element type in mind.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#78Earlier quoted context omitted.
I've been working full time in Go since 2012. I've never had a use for generics.
How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me. I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.
What do you mean?
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#79Nice 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…
Haskell is a proving ground, so it's picked up a number of ideas that never quite panned out.
I think you can identify a core set of features that are pretty reasonable. I think that'd be type classes, constraints, and functional dependencies.
If they made a handful of extensions standard (GADTs, etc.) it would mostly Do What You Want without a lot of prodding.
> And from Java I know that there's a pretty trivial example that showcases how its Generics implementation is unsound when mixed with inheritance.
I'd be curious to see that. There's a well known limitation that mutable containers (and they're all mutable in Java) need to be invariant, but that doesn't make them unsound.
The type system was also already unsound due to covariant arrays and nulls being a member of all classes, but if you don't break those rules or disable checks, Java generics work as far as I can tell. By "work", I mean I've yet to get a ClassCastException in a fair amount of work with some gnarly Java generics.
And, really, 99% of the boilerplate in Java's typing is that you can't declare aliases for types; that seems to be more due to engrained hostility to syntactic sugar than any technical difficulty.
> So, is there any version that just works, and never leads the user down any rabbit holes?
Most of the "gradual typing" projects for languages like Javascript, Python, Ruby all seem to accomplish what you're looking for, by virtue of the fact that you can just ignore it when you don't want it.
Re: Show HN: Fo: An experimental language which adds generics on top of Go
#80Earlier 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…
Exceptions are part of the reason that RAII is so critical in the C++ world. I don’t think that’s quite true. You definitely want RAII with exceptions, yes, but RAII is extremely useful even without exceptions. I believe it’s common to disable C++ exceptions but still use RAII. If you have multiple returns from a function (which can very easily happen with manual error checking) RAII is a big win.
> You definitely want RAII with exceptions, yes, but RAII is extremely useful even without exceptions.
Which is another way of saying exceptions are part of the reason for RAII.