Developer Proposes New (and Compatible) 'Extended Flavor' of Go (medium.com) 55
While listening to a podcast about the Go programming language, backend architect Aviv Carmi heard some loose talk about forking the language to keep its original design while also allowing the evolution of an "extended flavor."
If such a fork takes place, Carmi writes on Medium, he hopes the two languages could interact and share the same runtime environment, libraries, and ecosystem — citing lessons learned from the popularity of other language forks: There are well-known, hugely successful precedents for such a move. Unarguably, the JVM ecosystem will last longer and keep on gaining popularity thanks to Scala and Kotlin (a decrease in Java's popularity is overtaken by an increase in Scala's, during the previous decade, and in Kotlin's, during this one). All three languages contribute to a stronger, single community and gain stronger libraries and integrations. JavaScript has undoubtedly become stronger thanks to Typescript, which quickly became one of the world's most popular languages itself. I also believe this is the right move for us Gophers...
Carmi applauds Go's readability-over-writability culture, its consistent concurrency model (with lightweight threading), and its broad ecosystem of tools. But in a second essay Carmi lists his complaints — about Go's lack of keyword-based visibility modifiers (like "public" and "private"), how any symbol declared in a file "is automatically visible to the entire package," and Go's abundance of global built-in symbols (which complicate the choice of possible variable names, but which can still be overriden, since they aren't actually keywords). After a longer wishlist — including null-pointer safety features and improvements to error handling — Carmi introduces a third article with "A Proposition for a Better Future." I would have loved to see a compile time environment that mostly looks like Go, but allows developers to be a bit more expressive to gain maintainability and runtime safety. But at the same time, allow the Go language itself to largely remain the same and not evolve into something new, as a lot of us Gophers fear. As Gophers, why not have two tools in our tool set?
The essay proposes a new extended flavor of Go called Goat — a "new compile-time environment that will produce standard, compatible, and performant Go files that are fully compatible with any other Go project. This means they can import regular Go files but also be safely imported from any other Go file."
"Goat implementation will most likely be delivered as a code generation tool or as a transpiler producing regular go files," explains a page created for the project on GitHub. "However, full implementation details should be designed once the specification provided in this document is finalized."
Carmi's essay concludes, "I want to ignite a thorough discussion around the design and specification of Goat.... This project will allow Go to remain simple and efficient while allowing the community to experiment with an extended flavor. Goat spec should be driven by the community and so it needs the opinion and contribution of any Gopher and non-Gopher out there."
"Come join the discussion, we need your input."
Related link: Go principal engineer Russ Cox gave a talk at GopherCon 2022 that was all about compatibility and "the strategies Go uses to continue to evolve without breaking your programs."
If such a fork takes place, Carmi writes on Medium, he hopes the two languages could interact and share the same runtime environment, libraries, and ecosystem — citing lessons learned from the popularity of other language forks: There are well-known, hugely successful precedents for such a move. Unarguably, the JVM ecosystem will last longer and keep on gaining popularity thanks to Scala and Kotlin (a decrease in Java's popularity is overtaken by an increase in Scala's, during the previous decade, and in Kotlin's, during this one). All three languages contribute to a stronger, single community and gain stronger libraries and integrations. JavaScript has undoubtedly become stronger thanks to Typescript, which quickly became one of the world's most popular languages itself. I also believe this is the right move for us Gophers...
Carmi applauds Go's readability-over-writability culture, its consistent concurrency model (with lightweight threading), and its broad ecosystem of tools. But in a second essay Carmi lists his complaints — about Go's lack of keyword-based visibility modifiers (like "public" and "private"), how any symbol declared in a file "is automatically visible to the entire package," and Go's abundance of global built-in symbols (which complicate the choice of possible variable names, but which can still be overriden, since they aren't actually keywords). After a longer wishlist — including null-pointer safety features and improvements to error handling — Carmi introduces a third article with "A Proposition for a Better Future." I would have loved to see a compile time environment that mostly looks like Go, but allows developers to be a bit more expressive to gain maintainability and runtime safety. But at the same time, allow the Go language itself to largely remain the same and not evolve into something new, as a lot of us Gophers fear. As Gophers, why not have two tools in our tool set?
The essay proposes a new extended flavor of Go called Goat — a "new compile-time environment that will produce standard, compatible, and performant Go files that are fully compatible with any other Go project. This means they can import regular Go files but also be safely imported from any other Go file."
"Goat implementation will most likely be delivered as a code generation tool or as a transpiler producing regular go files," explains a page created for the project on GitHub. "However, full implementation details should be designed once the specification provided in this document is finalized."
Carmi's essay concludes, "I want to ignite a thorough discussion around the design and specification of Goat.... This project will allow Go to remain simple and efficient while allowing the community to experiment with an extended flavor. Goat spec should be driven by the community and so it needs the opinion and contribution of any Gopher and non-Gopher out there."
"Come join the discussion, we need your input."
Related link: Go principal engineer Russ Cox gave a talk at GopherCon 2022 that was all about compatibility and "the strategies Go uses to continue to evolve without breaking your programs."
Some people cannot let stuff alone (Score:2, Insightful)
Once something works, they absolutely have to break it by extending it. That basically never works, except for really small changes (like K&R C to ANSI C). If you do not like Go, then find something you like instead, but do not try to break Go.
But I see learning from history is just as unpopular in information technology as it is in politics. Unless that changes, IT will never be a proper engineering discipline.
Re: (Score:2, Informative)
Re: (Score:2)
Yeah -- or the gripe about lower-case variables and fields being accessible to their entire package. If you are that fussed about it, make smaller packages. The goal of Thompson, Pike and Griesemer was never to write C++ or Java in Go.
Likewise for the wish to have initial values in a struct. Did he miss the entire point of Go's simple definition of zero values? Or requiring people to explicitly say variables are variable, rather than only having to say what names identify constant values. What's the po
Re: (Score:2)
Well, some people do not get that "use the right tool for the job" is the only sane way. And if these are people with just one tool available to them, they often want to make it do everything, making it not really suitable for anything as a result.
Re: Some people cannot let stuff alone (Score:2)
It could be they just want a better version of the same tool. Strict no nil for example would go a long way towards fixing what is easily the most annoying and broken thing about go.
Also there's a very good reason to have private fields: prevent library users from inadvertently creating bugs.
Re: (Score:2)
Go has private fields, they're just private to the package that they come from rather than methods on the struct that contains them. Library users can't see them, much less use them to create bugs.
Comment removed (Score:5, Insightful)
Re: (Score:1)
Part of why go exists, is what it does NOT have. I think they are missing the point.
Sounds like it.
Re: (Score:2)
Go argues against many features exactly like Java 1.0 (or even pre Go 1.18) argued about not having C++ features like generics or like Python argued about type signatures - you don't really need them. Or like how Steve Jobs told iPhone 1.0 apps devs they don't need an SDK. It's really a feature, believe us (until we manage to add it later).
Re: (Score:2)
I don't know. I rather liked Mortran, before Fortrarn added structured programming constructs. Once it did, of course, I quickly abandoned Mortran, but in the interim it was a great improvement despite the hackery of preprocessing everything.
Re: (Score:2)
Typescript seems to add huge value over basic javascript, so Im not sure about your “basically never works” comment
And, just as Typescript doesnt stop you from writing basic javascript, this will not stop you from writing basic Go - so wheres the negative here? People who like Go will stick with Go, people who want to extend Go will move to Goat - in fact thats a positive, as those people will no longer be wanting to extend Go, surely?
Re: (Score:2)
TypeScript is a different language!! than JavaScript.
Re: Some people cannot let stuff alone (Score:2)
Given it transpiles to regular js, it's probably best described as a compete replacement. And GP makes a perfectly good point: Simple languages like go don't abstract away complexity, they merely move it and then add to it. Js is much more simple than typescript, so if being simple like go is such a novel concept, then why do we have a more complex language like typescript to replace a more simple language like js?
Same reason this fork exists.
Re: (Score:3)
TypeScript is not more complex than JS.
It only adds static typing, otherwise it is nearly exactly the same as JS (removing JS's odd coercion rules, though).
Re: Some people cannot let stuff alone (Score:2)
Re: (Score:2)
Nope ...
See: https://stackify.com/typescrip... [stackify.com]
Re: Some people cannot let stuff alone (Score:2)
Re: (Score:2)
The syntax does not make a script run. ... it is obviously only a vague subset :P
If the script does not "compile"
So stop nitpicking.
Re: (Score:2)
> That basically never works, except for really small changes
If only there were some "well-known, hugely successful precedents for such a move" listed in the headline.
Re: (Score:3)
K&R C to ANSI C is a massive change. For example:
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Perhaps you should at least read the summary?
They are not changing anything in Go ...
Re: (Score:2)
Once something works, they absolutely have to break it by extending it. That basically never works, except for really small changes (like K&R C to ANSI C).
What about C to C++? That worked.
Not everything is Python or PHP.
Re: (Score:2)
These are different things. And it is highly debatable whether the C++ monstrosity was a good idea.
Re: (Score:2)
> Once something works, they absolutely have to break it by extending it. That basically never works, except for really small changes (like K&R C to ANSI C).
You have quite the opposite of hacker ethos.
> If you do not like Go, then find something you like instead, but do not try to break Go.
I don't like Go, the language. But I like the Go ecosystem. Same with Java or C. For the Java ecosystem, there is Scala 3. For C, I prefer Nim transpiled to C. I am looking for something other than Go for using
Debating the name (Score:5, Funny)
Since they're adding surface features to an existing underlying structure, maybe they should just call it... Goatee?
Re: (Score:2)
Maybe they should call it GoFish.
Compatible ?! Awww. (Score:4, Funny)
Re: (Score:3)
Actually, that one was not so bad. In fact, I think Python 2 -> Python 3 was handled about the best way it could have been handled. That is not to say this was great. Not at all. But what are you to do when the old thing is not really fixable but also not so bad that you should throw it away completely? The only option you have is a strategic upgrade and they did that.
Of course, there are some significant problems with Python. One is that is ist used to tech people to code. That is basically insane. Pyth
Re:Compatible ?! Awww. (Score:4, Insightful)
I disagree. There are several objectives that did pretty much demand some incompatibility (e.g. the except Exception, e: being confusing), but they made things needlessly painful. Notably, they made it much more complicated to try to support both 2 and 3 which was utterly critical during the transition (in fact, during a recent move to drop python 2 support, it took about a week before a client came in and complained that they *still* weren't ready for that and demanded we keep doing python2 for new releases).
The unicode situation was particularly frustrating. They mitigated it by eventually allowing explicit u'' and b'' in both python2 and python3, however they never allowed 'unicode' to exist as a name, for example. In python2, 'bytes' and 'str' both existed as alias for the same type, but in python3 they refused to do that. Also python3 has been odd and inconsistent about which core libraries deal in bytes versus strings.
Also having no common names for a lot of things, like xrange and much of the core libraries, because the core libraries happened to be capitalized wrong in python2 or they just decided urllib should be split into pieces...
Further frustrating is that python *keeps* doing this between 3.x releases. When they added asyncio, a whole lot of the functions required passing loop as a parameter. Then they made it forbidden to pass a loop parameter. There are several core functions where you can't even invoke it in a compatible way across 3.x in a single syntax.
Python has some decent ideas, but it's maddening that every major release threatens to torpedo your code and your dependency code with some little thing or another. Versus, say, glibc, where even one minor little almost never used facility being removed was considered a huge controversy and backed out. They are never satisfied that the current state is 'pythonic' enough, and thus a cost of developing a python project is that you always have to be ready to deal with a new release requiring you to go through your code, and, sometimes, third party code if the developer has not tried to process that version yet.
I think python's use as beginning to code makes sense, it has minimal boilerplate and you can teach the concepts before having students contend with nitpicking that has value once you get used to it, but constitutes a distraction from some of the concepts early on.
Re: (Score:2)
Python is not suitable for beginners at all.
Most people disagree.
If you think like that, then there is no language at all in mainstream use that is suitable to teach beginners.
Re: (Score:2)
Nope. I have actual teaching experience. Unlike "most people".
Re: (Score:2)
Then explain :D why you think so, would be interesting.
And explain which language you would teach first and why.
Re: (Score:2)
So you can come up with more invalid and clueless arguments? No.
Re: (Score:2)
Why would I come up with clueless arguments?
So, you have no favourite teaching language :P or do not dare to admit it is Pascal?
Re: (Score:2)
Fuck off (Score:2, Troll)
Stop creating new languages you doofuses. Use an existing one! No wonder shit doesn't work anymore. Software is a mess. Worse, it's not good for the planet and economy. Kids don't know what to specialize in and learn. Back in the mid 90s I felt bad for all the people who specialized in OS/2, which was the superior OS compared to the cluster fuck that was Windows NT. Nowadays, there are so many languages and frameworks ... how are software engineers to keep up? Maintaining code becomes a bitch too. And a few
Welcome to the new music (Score:2)
The oldest programming languages still in common use (Lisp variants) only date to the late 50s. Compare and contrast this with the world of music, where the basic "notes on a staff" and other annotations like key signatures are quite standardized for most instruments (although every once in a while something like turntable scratching notation comes along). We've been playing somewhat modern music in the Western world for 100s of years though. There were probably some variations in notation early on there
Re:Fuck off (Score:5, Funny)
Stop creating new languages you doofuses.
Yeah! Put your time and energy into creating a new Linux distro instead!
Re: (Score:2)
Stop creating new languages you doofuses. Use an existing one!
By this logic, we would all be better off if we stuck to lisp, COBOL, and Fortran.
null-pointer safety, better error handling (Score:2)
Two things Go needs. Error handling with minimum 3 lines of conditional following every fail-able statement is a burden and destroys readability; a functional Result type with a small amount of syntactic sugar can fix this and make reading and writing Go vastly better. Runtime panics due to null pointer dereferences shouldn't be possible; we know how to employ types to eliminate that at compile time.
Go for it. There is a lot of low hanging fruit with golang and you might make a big splash with this, or
Re: (Score:2)
Better error handling [github.com] has been long recognized as a need. Maybe you should propose your magic bullet on the mailing list or as a prototype.
As for non-nullable pointers, you could read the Go issue [github.com] that was linked from the guy's post (or Go issue #30177, linked from that, which is probably more like you were thinking). The ideas have been considered but so far are not compelling.
Re: (Score:2)
I'm aware of both of these. It's also obvious that this is not a priority for golang; they're dragging their feet because the shot callers don't care. A fork/superset language could help move these along.
Fork? Nope, evolution. (Score:2)
If you have a fork in the road, you gave to take one or the other. If, on the other hand, you have something that can change, you can start down one path, find it isn't viable, and change direction.
Multics (and Solaris, and Linux glibc) understood API mutation[1] [acm.org]. Go and Sun OPCOM understood rewriting source code to support mutation in formal grammars.
What we have to do is put these and Mr Carmi's proposal together, and create a path from Go 1.0 to a next-generation language. Call it go 2, and the nex
Re:Fork? Nope, evolution. (Score:4, Funny)
A lot of people seem to think "Go 2 considered harmful".
Re: (Score:2)
JVM was engine not language (Score:1)
Scala and Kotlin use the JVM, yes, but they are also quite different languages to Java.
A "different flavor of Go" would seem to possibly fracture the Go programming community, into people that use the different flavors. To me it feels pretty fundamentally deferent than different languages keeping a virtual machine in widespread use.
It also seems like maybe it would harm evolution of the original Go because possibly people there would not add features, just because they didn't like GOAT and were so mad abou
Many of his complaints are not valid (Score:2)
This guy is complaining about the language syntax and semantics. What it sounds like he wants to do is build Go++ and make it more like Python.
Hey dude, go for it. If it's actually good, people will use it.
My personal opinion, though, is that you'll be wasting your time. Mostly because all of your complaints are (imo) purposeful decisions that make Go nicer to work with than Python. But it's your life, so best of luck!
Re: (Score:2)
Indeed, there is already a project doing it's own go, "V"...Why? Who knows?
"V is very similar to Go. If you know Go, you already know 80% of V. Things V improves on Go:"
https://vlang.io/ [vlang.io]
It had to happen... (Score:2)
Food Channel (Score:1)
Is tech the new food service industry?