Go 1.10 Beta 1 is released
groups.google.com
groups.google.com
Seriously, Go is not a perfect language, but I have come to really appreciate the stance that the Go team have taken on stability. Looking forward to Go 2, but very happy to keep on with Go 1.
Running old code and having it "just work" is something I really love with go. I hope go-2 new features won't come at the cost of breaking old code.
Here is the relevant part from it:
> Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part.
For all the good that has come out of .NET, and the nice platform it is today, there are a lot of high level design decisions where the team decidedly landed on 'the wrong answer'. To their credit they've been moving towards 'the right answer' for a while now.
Auto-wrapped properties instead of exposed value fields. Smart initialization. Safe default values. Generics. Anonymous functions. Nulls. Higher order functions.
Still under way: pattern matching, DSL support, option type, type aliasing, etc.
Related, but I also find it highly fascinating on those topics how much of Visual Basic's design they ignored, derided, and have then had to re-implement after-the-fact. A lot of babies got thrown out with the COM+/VB6/MFC bathwater.
Not sure what you mean here, COM has become the main way of doing Windows APIs since Vista, going full circle to the original design of COM Runtime with WinRT (now UWP).
COMs resilience in the face of competing models, as you've pointed out, and the fractured GUI landscape of the windows client platform are symptoms, IMO, of ceding a pretty mature platform for something almost, but not quite, as capable. It has taken .Net over a decade to relearn lessons won painfully for the VB5 and VB6 teams, and I believe they lost a lot of larger systems because of WinForms restrictions in the 2005-2009 window.
The generics in C#/Vb.Net are pretty nice too, but their absence in the language during the design of the original standard libraries is still felt (typically along IDictionary and ICollection interfaces).
It seems obvious in retrospect how useful they are, but I do remember lots of contemporaneous "debate" about how academic and complicating they would be that turned out to be. My personal opinion is that these debates were relics of the C++ contingent of the ecosystem, and less applicable to languages running on top of virtual machines.
But I agree they can be tricky to get right (compare e.g. declaration-site vs use-site variance [0]) or "accidentaly Turing-complete" TypeScript [1].
[0]: https://schneide.wordpress.com/2015/05/11/declaration-site-a...
[1]: https://gist.github.com/hediet/63f4844acf5ac330804801084f87a...
Well, I hope go get generics fast then. Seriously, what is this community that rejects any possible enhancement to a language? Even C gets new features albeit slowly. A language that doesn't evolve is a dead one.
There is nothing complicated with generics, they are just incomplete types, that's all. Generics =/= C++ templates.
Ada has a great implementation of generic programming which forces the developer to complete generic types before using them. In fact Ada got a lot of things that go got wrong despite being way older, especially when it comes to concurrency and types.
Package based generics make them completely compile time and runtime safe, no type erasure. The'd be the equivalent of reflect.MakeFunc or reflect.MakeStruct at compile time, so without any performance penality or ugly reflection, which go has right now.
It is very common (especially in libraries) to pass `interface{}` around and use reflection to do manual type checking and type casting.
With generics the code that uses `interface{}` today would actually be much more readable, because the intention of the author would be clear.
We just want that special casing gone so we could write, say, a generic set that works just as well as map
I do not agree with your comment. I don't see how generics are needed to deal with "complex business logic". Yes, ultimately I would like to see generics added to the Go language. As does the Go development team. But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals.
And until then, I am quite happy that they didn't implement some half-finished concept.
Complex business logic really has no place in Go. I would advise people to use more expressive languages (ideally with a modern type system). Go was designed for low-level network systems programming and is not well suited to more high-level problems, despite what the hype train might claim. I see the future as a polyglot one. Folks should use the most appropriate language for whatever domain they are currently working in and not let their careers be defined by any one language or technology.
It's not so much "we should add generics but no one is really working on it" it's more "we should add generics and we've tried a dozen designs that haven't really panned out and we're still working on it".
That's what makes me think they will end up happening.
CLU was designed in 1975 and ML in 1973, several languages with support for some kind of generics have been born and died since then.
So in 42 years, there wasn't a single generic implementation that could fit Go's design goals, other than not having generics at all?!
There is nothing special in Go's type system that hasn't been tried out in 42 years of generics CS research.
The fact that Go "has not existed for 42 years" is irrelevant -- almost all of its characteristics have been present for 3 to 5 decades, even altogether in the same language(s).
"..Updated 2015-09-25: So, about six years later, people are still reading this. I'm not sure how to feel about this; Looking at it now, it's incoherent, badly argued, and a lot of the details are simply wrong. But 1000 hits a month indicate that people still get value out of it."
But this article link is still quite handy for random proof of Go badness.
He might have changed his mind, but the facts are more stubborn.
> I don't see how generics are needed to deal with "complex business logic".
Here, we're talking about what user (developer who chooses between Go and Java) needs or wants. User doesn't care about costs behind the product.
However, instead of proving this statement, you jump to a different perspective whatsoever:
> But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals.
And here you're estimating things from the cost perspective; and it quite logically follows that it's not rational for Go developers to dive into generics at the moment. Just keep it mind that this decision means that Go stays unappealing to users like me.
And also for the Go developers, it is not about "cost". They have no idea how they could implement generics without fundamentally changing the Go language to something different than what it was about before. They are working on concepts, but nothing resulted what would be a candidate for implementation.
Personally, I don't get the fuss. If you want generics, go use Java/Kotlin/something else. I don't see anyone complaining about the lack of generics in C or brainfuck, what makes golang special?
They could be faked with macros since the early days, which was what Borland's BIDS framework in Borland C++ 2.0 for MS-DOS made use of, dropped when version 3.0 with initial template support was released (around 1992).
Additionally, C now has basic language support for generics in C11 with _Generic.
People like 90% of Go e.g. simplicity, build process, speed and feel that if they added features such as generics, decent error handling e.g. Option or Exceptions then it might go to 95%.
Everyone is looking for that perfect development platform.
Because it's painful to see a language that would be just perfect for a LOT of things with just ONE extra feature - but without this feature that is a requirement, we have to chose alternatives that have irritating downsides.
That typically depends on reflection facilities provided by the language, not genetics. In fact genetics, unless done with extreme care, inevitably makes reflection API more complex. In turn that makes it harder to write readers/writers for typical business formats harming the case of business applications.
I have been coding since early 80's, naturally I have delivered lots of production code without generics.
Oberon, one of my favorite language family and influence to Go, which I used for a while, also did not had generics.
But that was in 1996, when generic programming was WIP in ANSI C++, ML compilers were starting to be adopted, Ada was too expensive, Java and .NET were yet to come.
In 2017 I only use static typed languages without support for genericity when forced to do so.
Really you are spoiled for choice and there is no need to insist every language should follow your particular language philosophy.
The error's text is close to useless for even a moderately complex JSON object, but at least it's possible to catch this condition now.
If you then break the API's backwards compatibility by, say, removing a field, then your API will visibly break, which is correct, something you'd otherwise not detect.
The solution to maintaining backwards compatibility is a combination of explicit versioning, erroring like this, good documentation, and trying to support old features for as long as possible.
Definitely never liked Go's silent ignoring of JSON keys. The workarounds (e.g. overriding the unmarshal code to apply a check) have always been very invasive.
Edit: Maybe you meant in the client, since you wrote "against". If so, I would still argue that strictness is good, as you do want your client to break (or at least warn) if something changes.
That's a different issue. Fields going missing is definitely something I want to cause big problems.
I do mean consumers (e.g. unmarshalling JSON responses from APIs), as the typical mechanism to support backwards compatibility is by adding keys. Otherwise you can't upgrade ever without entirely new API versions, and you force lockstep for deployments. Needing new data is a common thing - maybe you have user endpoint that's not returning <some_flag> that you added that you now want in some new service. Bumping APIs for every added field would get unwieldy fast and you'll have services scattered among many API 'versions'.
It's just like in protobuf. In protobuf (or most other service-to-service serialization libs), adding a new field is not backwards incompatible.
Huh? I don't know the details of what you're (de)serializing, but the standard strategy for default values that are not zero values is to have unpack into a pointer. For example, if you have a message like
{ "foo": 23, "bar": 42 }
var msg struct {
Foo int
Bar *int
}
err := json.Unmarshal(data, &msg)
//handle error
if msg.Bar == nil {
defaultValue := 5
msg.Bar = &defaultValue
}
type Message struct {
Foo int
Bar int
}
func (m *Message) UnmarshalJSON(in []byte) error {
var msg struct {
Foo int
Bar *int
}
err := json.Unmarshal(data, &msg)
if err != nil {
return err
}
m.Foo = msg.Foo
m.Bar = 5
if msg.Bar != nil {
m.Bar = *msg.Bar
}
return nil
}
type Test struct {
Foo string
Bar string
}
func NewTest() *Test {
return &Test{Foo: "a"}
}
func main() {
t := NewTest()
if err := json.Unmarshal([]byte(`{"Bar": "b"}`), t); err != nil {
log.Fatal(err)
}
fmt.Printf("%#v\n", t)
}
&main.Test{Foo:"a", Bar:"b"}Is x86 vector support only being added now?
The standard library is actually chock full of specialized assembly implementations of various algorithms. Well worth a look even if you don't use Go. Here's an example of aes encryption which is a relatively recent instruction: https://golang.org/src/crypto/aes/asm_amd64.s
What I am really looking forward to is the NUMA awareness in the runtime. Most servers are now NUMA machines, in fact AMD Threadripper is NUMA and it costs a few hundred $ only.
Why was there ever a limit? Is anyone in the know on this?
Neat! I've been waiting for this.