Live data from Hacker News

Show HN: Fo: An experimental language which adds generics on top of Go

github.com

61–70 of 125 posts

Re: Show HN: Fo: An experimental language which adds generics on top of Go

#62
post #17

This 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.

I recall experimenting with that, but I had a hard time making them work correctly (although I don't recall the details--might've been something to do with their parser DSL or something). The compiler doesn't use the stdlib because the compiler was originally implemented in C, and then they did a mechanical C -> Go translation.

Re: Show HN: Fo: An experimental language which adds generics on top of Go

#63
Has anyone worked on Lisp-like macros in Go? Executing code at compile time to emit AST and compile it.. That is what I feel is really missing. Even with strictly a compile-time phase (no run-time macro evaluation) it could be quite useful.

Starting with generics seem to lead down the dark path of C++ template metaprogramming..

I would rather do something like

type StrBox = MakeBoxType!(string)

...and have clean hygienic macros to generate my "generic". Syntax candy can be added to that to get generics...but starting with generics and only supporting that went really really badly for the C++ ecosystem.

Re: Show HN: Fo: An experimental language which adds generics on top of Go

#67
The 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.

Re: Show HN: Fo: An experimental language which adds generics on top of Go

#68

Interesting, 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…

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.

Re: Show HN: Fo: An experimental language which adds generics on top of Go

#69
post #67

The 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.

Re: Show HN: Fo: An experimental language which adds generics on top of Go

#70
post #63

Has anyone worked on Lisp-like macros in Go? Executing code at compile time to emit AST and compile it.. That is what I feel is really missing. Even with strictly a compile-time phase (no run-time macro evaluation) it could be quite useful. Starting with generics seem to lead down the dark path of C++ template metaprogramming.. I would rather do something like type StrBox = MakeBoxType!(string) ...and have clean hygi…

Completely agree. Go has parsing and type checking and what not as part of its stdlib. However they choose a code generation approach which is a separate step and often relies on code comments. Even if security fears of compile time execution were allayed, the Go stewards are very unlikely to support altering the very strict-yet-simple grammar for multiple reasons. Macros would be very welcome, but they can't help improve the language if the language is intentionally inflexible.
Post reply on HN