polymathist

Hey everyone, author here. Let me know if you have any thoughts or questions!

Thanks for sharing and I'm excited to see what comes next!

Yes, I've already been thinking about constraining type parameters to an interface. Internally, the type-checker considers type parameters to have underlying type interface {}. A constraint on a type parameter should be as straightforward as changing it's underlying type to a specific named interface instead of an empty one. The only tricky bit I can see is thinking about how this would work with generic interfaces or whether we should allow other kinds of type constraints (e.g., union types).

Definitely something I'm thinking about. It's one of a handful of features that I have in my head but haven't created an issue for.

Parameterized packages are interesting but they come with their own problems. It can get tedious if I want to use, e.g., a stack with multiple different types. They also lose some of the flexibility that comes with scoping type parameters to any function/method/data structure.

Ply looks really cool! I can certainly understand the appeal of that kind of approach in terms of simplicity, stability, and better interop.

Local types are an edge case I'll need to spend more time working on. The type-checker won't have any problems; the real question is how to generate the appropriate Go code. One solution might be to move the local type into a higher scope during code-generation. Another might be inlining the relevant generic types in the same scope as the local type. Finally, the best solution might just be to say this sort of thing isn't allowed and the compiler will return an error.

Imports aren't supported right now, but it's one of the most important things I need to work on next. It'll be pretty tricky, but I'm confident I can find a solution.

The fortunate thing about the approach I'm using with Fo is that I have complete control over the parser, type-checker, and code-generator. At the cost of having significantly more complexity, I have the flexibility to tackle these sorts of edge cases without relying solely on existing tooling.

Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.

In a non-NN world, nothing will stop Comcast or ATT&T from also offering an "email only" plan. Except in their version of the plan, it costs $0/month if you use their own hosted email service. And when the grandkids come over they can watch Netflix for free because Netflix is paying the ISP to subsidize bandwidth.

Eliminating NN will make competition even worse for smaller and medium sized ISPs because the big ISPs have disproportional leverage to extract subsidies from media companies and make all sorts of deals. In some cases, the ISPs even own the media companies (for example, Comcast owns NBC). How can you possibly expect to compete with that?

What about the way Go handles errors today makes them not "strongly typed"?