If I had one recommendation to increase your projects chance of success it would be to make sure a snippet of code is shown right away. On your homepage, on your github page, where ever you think someone will encounter the project for the very first time.<p>This seems to be a common problem with programming language projects, at least initially, so I'm not trying to berate or shame you just point it out.<p>Anyways it does look interesting and I'm always happy when I see python inspired syntax!
I read the name "Have" as "Haxe" [1] and thought it was a subset of their cross-platform toolkit. I cannot think of many use cases <i>(a transpiler for a system programming language)</i> because Go in itself is very simple, which is one of the main reasons so many developers from other communities have switched, because with a short list of reserved keywords, C-like syntax, and simplicity of its standard library people can do amazing things.<p>At least it will provide Generics [2] ¯\_(ツ)_/¯<p>Would <i>you</i> use a project like this? If yes, for what?<p>[1] <a href="https://haxe.org/" rel="nofollow">https://haxe.org/</a><p>[2] <a href="http://havelang.org/post/for_gophers/#generics" rel="nofollow">http://havelang.org/post/for_gophers/#generics</a>
I'm not usually a stickler for syntax, but `interface{}` => `interface: pass`? It really seems like the indentation approach creates more problems than it solves. :(<p>EDIT: Props for writing this in Go though. Oden (the other 'compiles to Go' language) is implemented in Haskell, which means that I can't hack on it.
Might be worth using just for generics. Template out small bits you need, compile them to go and use them as libraries for generic-heavy tasks like sorts and what not.
So, let me phrase my criticism as questions :)<p>How do you declare methods on non-struct types? Or are you disallowing defining your own non-struct types? It seems to me that the method-syntax you introduced will either be a step back, because it disallows non-struct types, or it will be a step back because it makes method declaration inconsistent.<p>How are the generics implemented? The general tone seems to suggest that you do naive template expansion, but the section about when makes it seem that you are using interface{} and type-assertions in the generated code.<p>How is the overloading of make handled (assuming it's actually just implemented with the existing generic mechanisms)? It can take between 1 and 3 arguments and does vastly different things to them depending on the type parameter. The latter part might be handled by your specialization mechanism (with considerable runtime overhead for a very central part of the language), but the former is not described.<p>Overall, I admire implementing a language as a hobby project (I always wanted to do that myself). But I don't see anything that would compel a significant share of people to migrate over either from python or from go. It doesn't come close to python's expressiveness and it also lacks go's simple and orthogonal design.<p>It seems to me, that you added a few things that are better addressed (and will be addressed) in an eventual go2 and then more or less arbitrarily changed a bunch of things for personal taste. The result feels a bit patchworky; your generics have even more overlap with interfaces than people have feared about a go addition (which is one of the major reasons it doesn't have them) due to the type-switchy-when and the syntax changes create a bunch of inconsistencies.<p>Still. Plow forwards :) There can only come good of more stuff in the world :)
Interesting! But I would love a clojure-like (or even clojure) that compiles into go-code and then built into native code (or another solution). I don't really want to ship .jar files, and I love golang for building CLIs but I really want to get away from that kind of syntax.
The author claims one of the goals is to write zero cost data structures. i don't see how thats possible if it compiles to Go, as most data structures in go have implicit cost associated with it because there is a language runtime and GC.<p>Unless he means zero-cost ON TOP of Go, which is an odd definition.
reposted from r/golang:<p>> <i>Have is an indentation based language</i><p>Nooope.<p>That kills half the benefit of gofmt - fixing indentation.<p><pre><code> if foo:
bar()
</code></pre>
Did I forget a "pass" or did I forget to indent bar? You can't tell, so you just have to punt.<p>It also prevents fixing up copy and paste:<p><pre><code> if foo:
--paste start--
if tooMuchIndentation():
something()
--paste end--
previouslyInsideIf()
</code></pre>
What would your formatter do here? Did I mean for the last line to be inside the new if, or outside of it? You can't tell, so you have to make an assumption, and it'll be wrong half the time.<p>And that's not to mention all the other benefits of braces, like easy visual indication where blocks start and stop, having anonymous blocks (without if true), etc.<p>Also, requiring methods to be placed inside of structs (or, presumably other named types like type foo int) means that for large files, it won't be immediately clear what type a method is for.<p>Halfway down the 1000 line file network.go you have<p><pre><code> func *String() string: return self.Name()
</code></pre>
What type is this declared on? There's no way to know without scrolling up to the beginning of the type declaration. Also it means that almost all your code is uselessly indented once for no reason.
The real link: <a href="http://havelang.org/post/for_gophers/" rel="nofollow">http://havelang.org/post/for_gophers/</a><p>So it's just Go with Python syntax: <i>"Have syntax is inspired by Go and Python, but semantics is usually the same as in Go."</i>