9 ms·
As a person who was initially disappointed by Go and who has come to love it, one of the biggest things I learned from watching it grow was the following: As f
by evmar 3y ago
As a person who was initially disappointed by Go and who has come to love it, one of the biggest things I learned from watching it grow was the following:
As far as languages go, Go is relatively well-funded. You can of course imagine hypotheticals where there was more money behind it, but on the spectrum of PLs it's got more support than most. And further, I think the core developers who work on it like rsc and bradfitz are objectively great implementers. Despite that, the majority of complaints about Go are a lack of language features; you even see some in this thread.
In other words, a language with an above-average amount of effort and ability and 14 years behind it is still perceived as feature poor. But imagine how much more time it would have taken if they had taken on a larger scope, like if they had gone through all the complex design process for generics up front.
For me it is a great lesson on how important reducing scope is for shipping, and also how a reduced scope enables you to more judiciously choose what is important. If they had decided that features X, Y, Z were table stakes for their launch they would never have had the time to do the other things that I think have made Go great.
- tejinderss 3y agoHow does it compare to rust in your experience?
- VBprogrammer 3y agoI only have a small amount of Go experience but in my humble opinion I don't think the lack of features is due to lack of time or funding. In fact it would have probably been much easier to say yes to a bunch of features than to continually deflect and reject the demand for those. I'm sure anyone working with different stakeholders recognises this effect. They have very deliberately tried to minimise the feature set in order to keep the language easy to learn. C++ is probably the canonical example of a language which hasn't kept the feature set tractable but I'd even argue that Python may have fallen into this trap in recent history.
- asah 3y agoGiven AI assisted programming, I'm not sure how much any of this matters...
- sakjur 3y agoComplex language features have much more of a toll on reading code than they have on writing code. One example that I like to use is that while Go's lack of operator overloading is occasionally a nuisance, it means that you'll never have to dig deep to understand what "+" is doing on this particular line, since it'll always behave according to the core language rules. I think the total cost of debugging hours often ends up being several magnitudes higher than the cost of development hours. At least for me, the process of debugging is something that involves scanning the code to load up my brain with as much possibly relevant context as I can and then try to analyze what parts of that might explain the seen behavior. A carefully designed language should help to both minimize the size of that context and the amount of linguistical gotchas that are part of it. If I'd use an AI assistant, that lets me ask more pointed questions. Wouldn't that improve the assistance the AI can provide?
- VBprogrammer 3y ago> Go's lack of operator overloading is occasionally a nuisance, it means that you'll never have to dig deep to understand what "+" It's funny, in 10 years of writing Python professionally I can only think of one occasion when I had to dig into what a __add__ operation did (a Money library which didn't special case 0 meaning sum didn't work as you might hope). I think it's probably because python has a pretty comprehensive standard library which gives reasonably consistent examples of where to use them.
- merb 3y agoThat is not necessarily true. Especially the error handling makes it really awkward to read go code. A lot of languages with an expressive type system do look aweful when looking at methods. But the same thing can be done with go methods. Writing hard to understand go code is just as easy as say with scala or rust
- mseepgood 3y ago> They have very deliberately tried to minimise the feature set I thought this was common knowledge. They made whole conference talks about it.
- teodorlu 3y agoMight I ask for a link? I searched around, but didn't find anything. Perhaps the title is something different than "go minimal feature set".
- Gys 3y agoFor example https://www.youtube.com/watch?v=rFejpH_tAHM https://www.youtube.com/watch?v=rFejpH_tAHM
- vram22 3y agoYes, and Rob Pike has a post about it on his blog, command-central.com, IIRC.
- raverbashing 3y agoYeah true For me the issue of Go is that it has a focus on backend services and doesn't try going much further than that. (And also it's probably a bit too plan9'ish) At the same time it's good that it has a focus, because that's what made it get where it got
- pansa2 3y ago> on the spectrum of PLs it's got more support than most Go definitely has much more funding and developer hours put into it than open-development languages like Python - that’s got to be a good thing for the language. On the other hand, would you choose to build a long-term business on top of Go, given that all that support comes from one company? What if Google decide that maintaining Go is no longer in their best interest?
- demi56 3y agoWhat makes you think that Google has active authority over Go development?,
- vitorsr 3y agoAs I understand it, Go is funded by Google in the sense that core language development is largely undertaken by Google employees, not in the sense that an independent language foundation organization that receives funding from external backers invests in core language development.
- patmorgan23 3y agoWell the language was created by Google employees and Google funds the majority of development work on GO.
- usrbinbash 3y ago> On the other hand, would you choose to build a long-term business on top of Go a) Absolutely and b) already done. Go is stable. The language is battle tested. It works as advertised. It is open source. Even if google pulled all funding (unlikely, since alot of their architecture seems to use it), the language is maintainable. And btw. Languages don't have to continuously evolve to remain viable. Modern languages seem to indicate otherwise, but that behavior is what Go actively avoids; adding everything and the kitchen sink into the language as soon as some other language has it. If Go showed one thing, it is that PLs don't need to add as many features as possible. And just to prove that point: C is still a top rated language in terms of usage. When was it last updated? C17 came out in 2017, and did not add new features. It superseded C11, which came out 6 years before that, also mainly standardising things that were already de-factos in most compilers. Before that was C99 in 1999, and before that is only ANSI-C and K&R.
- HumblyTossed 3y agoI like Go because it does have so few features. There are plenty of other languages out there that are feature rich, not all languages have to have everything.
- chubot 3y agoYeah definitely, starting the project in 2007 to releasing publicly in November 2009 is very fast. Then reaching a very stable 1.0 in 2012 is also fast. That's only possibly by reducing scope. I don't think more people help, because you can't really divide and conquer language design. (As far as I understand, the early project was something like "take Ken Thompson's C compilers and add goroutines, garbage collection, slices, and interfaces") I don't use Go regularly, but I've also had some very good experiences with it lately. They have kept the tools simple and predictable. Getting started is a breeze. The MIPS support worked surprisingly well, e.g. on a machine with 64 MB of RAM. I've had and still have a lot of gripes about (mainly being a sort of closed ecosystem), but you can't deny that it works well, and is a big achievement.
- lolinder 3y agoI don't think the lack of features is due to time or funding constraints: all the large languages that originated after Go have more elaborate features, and many of them have less funding than I assume Google puts towards Go. Rust, Kotlin, Swift, and Dart are the main ones I'm looking at. Rust and Dart had an official package manager long before Go did. All four have had some form of generics, at least the first three have sum types, null safety, and many other features that are missing in Go. These languages might have as much funding as Go (I don't know), but they've had less time to implement these things. Rather than funding constraints, it seems to me that Go has avoided adding features because that's not the kind of language they want to design. It may have led to more polish than some of the languages listed above (I personally prefer programming in any of the first three to programming in Go), but it's not a given that Go would have taken longer to build if they'd made the scope bigger.
- pif 3y ago[flagged]
- betaby 3y agoAs the opposite to what language?
- ADSSDA 3y agoOdd take, golang was designed by Google for their needs. It has very little uptake amongst hobbyist devs and is nearly entirely used by professional devs. In my experience hobbyist devs focus primarily on javascript/python.
- 62951413 3y agoJust think about golang as the next generation's Java. The same strong points (concurrency, GC, "simplicity" for junior developers), the same egregious mistakes (generics alone prove it for me), the same BigCo backing, the same undeserved early popularity.
- kaba0 3y agoJava was novel back then and managed to live up to its hype. Go isn’t novel, and doesn’t provide anything new compared to even Java 1.1.