These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps that I write currently in Java.
But where I thought he brought up really good points are
1. nil. He's right compared to more recent languages, nil is awkward. I've been bit multiple times by the 'nil checks sometimes fail.' concept. Option/Sum types are so much cleaner, and having non-nullable types make a lot of things easier to reason about.
2. error checking. My main gripe is when you are writing a process that involves calling multiple functions that could return errors. You then need more boiler plate in order to stay sane and DRY - and I've admittedly bitten myself with the 'err' shadowing that happens sometimes.
I don't think a Maybe type would have made Go more complex, and I think it would have fit in nicely with the 'Zero Value' concept.
If the language designers thought an Option/Result/Try was valuable they could add it. Just like they could add Futures/Promises and concurrent safe maps if they wanted to.
This is indeed a problem. It's the same problem with people writing a catch-all exception in Java, then forgetting to write the correct handler later. Considering the Go team's priorities, it's one they should fix!
val, err := foo()
if err != nil
return err
vee, err := bar()
if err != nil
return err
var err error
whenever err != nil
return err
val, err := foo()
vee, err := bar()
What I want? I want to
a) have an option where an unchecked return error causes the program to log and exit.
error SomeFn(int blah, int haw)
{
if(blah < 0 || haw < 0)
error(1);
return(bah*haw);
}
// program will die here
SomeFn(-20, 23);
// program will not die here
if(SomeFn(-20, 23) != 0)
{
// something
}
Example
int SomeFn(int blah, int haw, error oops)
{
if(blah < 0 || haw < 0)
oops(1);
return(bah*haw);
}
int res = SomeFn(-20, 23, crap);
printf("res =%i\n", res);
// SomeFn returns here
crap:
print("parameters can't be negative");What it is good for is software that is about moving bytes around from place to place. Network daemons, web servers, cli tools that interact with JSON/Xml in simple ways.
If there is a way to incorporate the best features of Haskell and Rust while maintaining Go's current simplicity and ease of use, then it should be incorporated. To that end, the Go core developers have expressed an intent to implement Generics, however they want to do so in a way that does not (significantly) negatively effect the language's simplicity or compile times.
Is that documented somewhere?
It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
Application of the best features and learnings to a particular problem domain. The (intended) domain is Google-scale code bases that live for decades. The ideas that are important there may not be applicable anywhere else. If they are, it's more by happenstance than design.
I am in two minds; after all, C++ existed for a long time without a workable implementation of templates, and that hasn't stopped the STL from doing quite well.
On the other hand, there were a number of fairly successful generics implementations already done when Go was created, and some of the core developers for Go seem to really have only lukewarm support for the idea (unlike C++, where Stroustrup seemed to support generics enthusiastically well before they appeared).
It does seem to be a very weird thing to bolt onto an already mature language. Some of the less felicitous bits of the C++ standard library seem like they would have been done very differently if templates had worked from Day 1 in the language.
I'm not an expert in generics by any stretch of the imagination; I timidly implement the occasional template function, happily use STL/BGL where I can, and am amazed at the sort of data structures this lets me get away with.
I do find myself puzzled that apparently no generics system in common use was deemed 'good enough' by the Go team to just clag before an entire language and its aforementioned 'rafts of code' sprang up around the absence of such features... there may be good reason.
But a language that doesn't let me do what I happily do in C++, with type safety, using language features that are over a decade old, is a total non-starter for me. The language may be all the simpler for this, but the code I would have to write would bear the cost of this instead. It's not a win for me, and vague threats that I'll get a vomitous compiler message when I bugger up "make_pair" and hints that the "princess is in another castle" aren't going to browbeat me into accepting a throwback of a language. My guess is that g++'s template error messages are going to be acceptable long before I see generics in Go, if I ever do.
The Go team wants generics. They acknowledge that generics would be a benefit to the language, and they have acknowledged that generics are by far the most-requested language feature from full-time Go developers. The only thing stopping them from implementing Generics is the inherent (purely technical) difficulty in providing it in a correct, performant, and type-safe manner.
The reason the Go team cannot look to Java, or Rust, or any other languages which provide generics and say "we will implement it exactly as they have" is because Go is as different from Java and Rust as Java is from Rust. Generics had to be individually implemented in each of those languages, and it was a fairly massive undertaking to do so, and there are a lot of folks that say that in Java's case in particular it was implemented poorly but now that it's implemented they're stuck with it.
Like yourself I'm not an expert on generics, either, but everything I've read in regards to generics in Go has lead me to the above conclusion. I trust the Go core developers to implement generics when they have a suitable plan, and I will gladly use them when they are made available, but in the meantime I intend to enjoy all of the great features of the Go language which are available today.
> The only thing stopping them from implementing Generics is the inherent (purely technical) difficulty in providing it in a correct, performant, and type-safe manner.
I initially accepted this, and found the "we don't want to build the wrong thing" explanation reasonable. Some years down the road however that's looking a bit threadbare. I've also read enough conversation threads that it's become very clear a couple of the key decision makers are simply resistant to the idea of consulting with the PLT community for a good design.
I'm happy to wait to Go 2.0 for generics, however, if they yet again recycle this "gosh, it's hard, we just don't know how" I will not be satisfied. There are people walking this planet who know how: ask them.
Doesn't seem so:
https://research.swtch.com/go2017#generics
>That is, is there too much Go code out there written without generics to ever incorporate generics after-the-fact?
You don't HAVE to rewrite all existing code to using generics, although I'm sure it will be tempting :)
All in all, my impression of Go is that it's a language designed by the same people who wrote the Google C++ coding guidelines (https://www.linkedin.com/pulse/20140503193653-3046051-why-go...).
>every language is equivalently powerful
>therefore, we should neither look to one language to improve another
We seem to have made a mistake somewhere.
Let's try again, shall we?
Some languages are trying to serve different niches than other languages. Trying to copy features from one language to another can be useful. But if you're copying from a language that's used for a different niche, you can ruin the destination language's suitability for its own niche.
What's Go's niche? The original intent was that it be useful for multi-million-line code bases that lived for multiple decades. Cost of compile time becomes a very big deal in that environment. (The original motivator was a 45-minute C++ compile. Multiply that times multiple developers, times multiple compiles per day, times 20 years, and it adds up to real money.)
What's Rust's niche? It's lower-level (C++-ish) code with compiler-enforced safety.
What's Haskell's niche? People are probably going to yell at me for this, but I think it's improved ability to reason about the algorithm.
It is unclear to me that an idea that's useful in one of these niches should automatically be assumed to be useful in another. Sure, if you're used to one niche, and you try to cross over to another, you miss things, but that doesn't mean that having it would be a net win in the other niche.
That being said, plenty about Go seems to make it easier to get there: the lack of reasonable tools for abstraction certainly makes copy-paste programming much more likely, along with the ensuing explosion in LOC.
Yes, but you originally asked us to do the opposite: to not modify a language based on the benefits shown in a different language; That an idea useful in one niche should automatically not be assumed to be useful in another.
Which of course is just as baseless as automatically assuming it will be (useful|viable|worth the effort).
Haskell is particularly irratating to see used for that opinion as well, given that is notable for being a research language; a language who at least partially exists to seek out, identify and implement ideas that can be transplanted into other languages, though of course it would naturally take a different shape once integrated.
Not quite. I asked you not to try to turn one language into another (that occupies a different niche). We don't need Go to become Rust, because we already have Rust. If Go becomes a better Go by stealing ideas from Rust, that's good. If Go becomes a worse Go by trying to become more of a Rust, that's a net loss.
Haskell... I admit that I was not thinking of it as a research language, where the whole point is to try out ideas. It's become more than that. It's become a "real" (production) language, not just a research language. But I will grant that it (partially) exists to experiment with ideas and export them.