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.
Anyways it does look interesting and I'm always happy when I see python inspired syntax!
I stopped reading when I timed out, still having no idea what the point is here, other that an exercise for the author. Make the case up front somehow, but make the sale while you still have eyeballs looking.
As for how much better you can do... Someone just (6 days ago) registered "be-lang.com" so we might get a top 2. Good news is that "the-lang.com" and the .org equivalents are available.
(Just kidding!)
At least it will provide Generics [2] ¯\_(ツ)_/¯
Would you use a project like this? If yes, for what?
That said, the idea of a transpiled language that adds generics definitely piques my interest. Ultimately, I suppose I would be worried of the language stalling or falling out of favor, like CoffeeScript.
The name choice doesn't seem that well thought out, which also makes me question the authors somewhat.
Have changes the syntax too, but it is also trying to fix things that often cause bugs in Go code, it adds generics, and there are a few other features on the way, too.
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.
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.
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.
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.
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.
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.
Still. Plow forwards :) There can only come good of more stuff in the world :)
It will be allowed, through type opening (which isn't implemented yet). It's mentioned in the intro, I called it "structure opening" but actually it will work on any non-builtin named type.
I'm not sure how the syntax will look like yet, but say that you have a struct:
struct A:
func MethodA():
pass
open A:
func MethodB():
pass
No, it's closer to template expansion, "when" is "executed" (for lack of a better word) during compilation. Inactive "when" branches are ignored by the code generator (and type checker, thus they can contain code that's invalid for given instantiation). There's no type-switch in the resulting Go code.
> How is the overloading of make handled (assuming it's actually just implemented with the existing generic mechanisms)?
Right now it's not handled at all. I don't want to add default argument values to the language, so, unless I come up with something better, I'm afraid that there will need to be more than one "make" function, each named differently.
Thanks for your feedback! I'm well aware that the chances of Have becoming popular are tiny, but I'm having lots of fun working on it anyway.
As I've now understood better what you mean, let me suggest a possible solution to your default-case conundrum: What about, if I don't want to allow the default-case, I just leave out the default case? And the compiler erroring out, if you pass in a type to a when-statement that doesn't have a valid case defined?
I'm not sure I understand. Could you point to where you do this on Github?
type foo int:
func MethodA():
pass
type foo int
func (foo) MethodA(){}
Unless he means zero-cost ON TOP of Go, which is an odd definition.
> Have is an indentation based language
Nooope.
That kills half the benefit of gofmt - fixing indentation.
if foo:
bar()
It also prevents fixing up copy and paste:
if foo:
--paste start--
if tooMuchIndentation():
something()
--paste end--
previouslyInsideIf()
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.
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.
Halfway down the 1000 line file network.go you have
func *String() string: return self.Name()
Yes, go has the benefit that you can do pathologically bad formatting and let gofmt fix it all. I love to type my Go code and rarely press RETURN, knowing gofmt will fix it. However, I also miss the Python indenting system.
It's true that gofmt-like tool would be less beneficial, but I think that most of the things you've mentioned could be helped with editor/IDE support, e.g. indent-aware paste, block navigation and so on.
And the 'halfway down the 1000 line file' one was just plain silly.
Now, if you remove the horrible feature of ignoring errors by default, I will play with it :)
Aaaarggghh!!!
:)
The only real advantage of indenting with spaces is if you use a column aligned coding style like this:
SomeFunctionName(firstArgument,
secondArgument,
AnotherFunctionHere(itsArgument,
itsOtherArgument),
lastArgument);
But this kind of column alignment has many disadvantages: excessive line lengths, spurious diffs in your source control when you change the length of a name and have to realign everything, and the fact that you'll very likely forget to realign something when you do a global replace.
I've seen each of these problems in the Servo source code which uses mandatory column alignment (examples in one of the links below).
An alternative way to format code is to use indentation only with no column alignment:
SomeFunctionName(
firstArgument,
secondArgument,
AnotherFunctionHere(
itsArgument,
itsOtherArgument
),
lastArgument
);
Here are a couple of previous comments with more examples and discussion of the advantages and disadvantages of indentation vs. column alignment:
[0] http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/
So it's just Go with Python syntax: "Have syntax is inspired by Go and Python, but semantics is usually the same as in Go."
That "mostly" in "mostly unchanged" is a problem. Have should probably be either significantly radically different from Go, so that when I use it I'm not confused, or it should be as similar to Go as possible except that it adds some features, so that it seems like a nice add on.
Rewriting syntax that ends up really just being a gloss on the existing syntax (i.e., not really allowing much new expressiveness) is just a hurdle to the language; it's a hurdle to your implementation, a hurdle to anyone picking it up and using it, and a long-term burden of trying to explain the slight differences to everybody. See, for instance, the Python 2 vs. Python 3 pain.
Since it seems to me the major feature of Have is giving Go generics, I suggest comparing with some other things already out there: https://github.com/sasha-s/go-inline , and I also reference the projects mentioned in the FAQ. I am not saying these things solve the problem, but you may want to compare notes and steal (in the "good artists borrow, great artists steal" sense) the good things if you can. You might also find it helpful to contact the authors or users of those projects and ask about pain points.