eobrain

Update: The new 0.4.0 release of Funcgo supports limited operator overloading: https://github.com/eobrain/funcgo/blob/master/doc/reference....

Thanks all. I created a new FAQ page for Funcgo, seeded with the questions and answers from this forum. https://github.com/eobrain/funcgo/blob/master/doc/FAQ.md

I like Glojure. I am not sure if it is worth the hassle of changing the name, but I registered glojure.org just in case I decide to do so.

Glad to hear someone else has been thinking about this.

Interesting idea to use macros to implement the mapping from the Go syntax tree. Presumably, these macros would implement the same kind of logic that my codegen module implements (mapping from the Go syntax tree to Clojure text). https://github.com/eobrain/funcgo/blob/master/src/funcgo/cod...

I have plans to implement source maps https://github.com/eobrain/funcgo/issues/19 when targeting JavaScript

I have not yet figured out the best way to do something equivalent when targeting the JVM.

This is one of several toolchain issues. In addition to stabilizing the language itself, getting a smooth toolchain is the biggest thing left to do before a 1.0 release of Funcgo.

(Though it is worth noting that Coffeescript, an analogous language, got widespread adoption before tackling the source location issue.)

"Jo" seems it is hard to search for. "Gojure" is already taken by another Github project.

I also considered "Clogure", but someone already had that too.

Keep the suggestions coming!

I cannot say enough good things about Instaparse, which is a flex/bison/jison for Clojure. It's amazingly feature-full and very fast. I could not have built Funcgo without it. Big kudos to Mark Engelberg.

I do not plan to add to Funcgo the ability to easily create macros. Inspired by Go's philosophy, I want to limit the scope of the language to keep it somewhat simple. Funcgo however can use macros, so a sufficiently motivated programmer can write macros in Clojure and use them in Funcgo.

Thanks for the feedback on the impression the name and branding gave. I'll try to change the main pages to make clear that Funcgo is not full Go, and is a fairly thin layer on top of Clojure.

Funcgo can readily call Java code, so it supports numerical programming or linking in C++ code to the same extent that Java does.

I've no immediate plans for another target for now – there is a lot of work still to do just targeting Clojure and making sure the toolchain is easy for programmers, both server-side and client side. As regards typing, Funcgo has type inference using Clojure's type-hinting and it can use all of Clojures immutable collections as well as the standard Java mutable collections. As for operator overloading, it's not there yet, but I just I added a user story (https://github.com/eobrain/funcgo/issues/18) to my backlog to allow function names to be operators (like in Scala). However it won't really be operator overloading because the underlying Clojure only allows overloading by arity, not by type.

Yep, fundamentally Funcgo is just Lisp without parentheses. Or put it another way, it is Lisp with more syntax. The fact that Lisp has so little syntax is beautifully elegant from a mathematical point of view, but that is I believe at the expense of readability, at least for programmers coming from other programming traditions. Of course readability is somewhat subjective and I understand that for long-time Lisp programmers, Lisp is perfectly readable.

Funcgo author here. Thanks for all the interest and comments. I'll respond individually to the comments.