Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Software Development

What’s Coming to Golang in 2019: Modules, Generics, Better Error-Handling

Big changes are coming to the Go community in 2019. To learn more, we spoke with Steve Francia, who joined Google in 2016 to become its product lead for Go, and to handle developer relations for the popular programming language.
Feb 5th, 2019 11:20am by
Featued image for: What’s Coming to Golang in 2019: Modules, Generics, Better Error-Handling

Big changes are coming to the Go community in 2019. To learn more, we spoke with Steve Francia, who joined Google in 2016 to become its product lead for Go, and to handle developer relations for the popular programming language. Prior to joining Google, Francia lead two of the world’s most successful open source companies, first as chief developer advocate at MongoDB and then as a vice president and chief operator at Docker.

Francia spoke to us about Go’s innovative new module system, error-handling, Go 2, a revised proposal process, the importance of community to Go, and other topics…

You’ve said you’re launching “significant changes to Go’s language and tooling, and the biggest change will be dependency management.” Can you tell me more about modules?

So modules are — it’s not a new concept. (Laughs) It’s one that’s existed in a lot of other languages.

But we’re taking a new and somewhat innovative approach to it. There’s a lot of work we’ve been doing to make it tightly integrated with all the Go tooling, to make sure our users have a good and simple experience, while also eliminating some of the concerns that exist in other languages and have existed in Go previously, in terms of better security and better reliability and reproducible builds. And as part of it, there’s a lot of behind-the-scenes security work happening to make sure that people can have those things.

You’re talking about certificates and registries, right?

Right. For certificates, we’re actually launching a notary which will sign things.

And then there’ll be a Go Modules index, sort of this central directory of what’s out there in the decentralized community.

That’s exactly right. That’s one of the goals is to make it so developers can find what they need easier. And we’re hoping that that’ll be a significant improvement to the way that they use Go. Our overall goal is to make it so that developers can find what they’re looking for quickly, and they can evaluate it. Because as you’re familiar with, not every library is the same quality as every other library. Not every one fits the needs that you have. So we’re trying to make that evaluation process as straightforward as possible, and then the ability for them to actually use and digest them, as easy as possible, as well.

Go is kind of unique in that we’ve never had a central registry for Golang packages — and that will not change. We still will not have a central registry. So unlike many other languages, where you need to register that “I own package X… so everyone else has to have a new name,” ours is more decentralized, and people publish packages all over GitHub, GitLab, on Google Source, etc. And that will continue to be the case. But we’re doing things to launch support for mirroring proxies, which will give higher availability than these single sources that we have today and also better security on them.

One of the advantages to this approach is that go get doesn’t change. You’re still going to use go get as you did more or less before. We really wanted to keep intact that very simple workflow that Go has always had, and we largely, I think, have been successful at that. There’s going to be a few small tweaks to it, but more or less the workflow is very similar to what you’ve had before, or what our users have experienced for the last 10 years, with the material difference of getting higher availability and higher security.

And the big change that modules add that go get didn’t have before was the ability to have versions. go get just always grabbed the latest of everything, and as projects matured that made it very hard for them to be able to release new versions with breaking changes. As the need for that increased, so did the need for version-aware tooling. That’s really one of the big things that drove this.

So another way to look at modules is adding version support to go get….

What’s the ETA?

We’re going to launch things in stages. We expect in early second quarter that we’ll have what we’ll call an Alpha release of this. It’s going to be public, we’re going to let people work on it, and then we’re going to work throughout the rest of Q2 and into Q3 to have a fully stable release. All of this is leading up to Go 1.13, which will out in August, which will have modules on by default. That’s the major feature in that release.

What’s driving this change? Was it users that were calling for this, or was it sort of a nice-to-have that you really wanted to add?

It was largely driven by user feedback. Go has always had built-in dependency management support — but it had some pretty significant limitations. And as projects scaled, and as our community scaled, it turns out those limitations were becoming a friction point for users. A lot of solutions were created to kind of work around them, but all of those had some limitations too. It became a growing need of our user base, as the user base both grew and matured.

We obtain this information through surveys, which we’ve done — annual user surveys. Very large annual surveys of our users, as well as user conversations and feedback through issue trackers and proposals and various ways.

I think in some regards, you know, Go has been a little bit behind some other communities, previous, to modules. Node is a great example of a community that has made it very easy to obtain modules. Or packages or plug-ins or whatever term each language uses. Ruby, with bundler, was also a bit of an inspiration. Php has Packagist, and — so a lot of languages have this support already.

I think Go, with modules, not only caught up to them, but also did some innovative things. Hopefully, as time plays out, we’ll realize those innovations were positive and, you know, maybe other languages will take note. Although I think the jury’s out for — for a while (laughs) to see how well-received those innovations are.

You’ve made a few changes to your proposal process. How is that working out?

Very well. I wouldn’t call it so much a new proposal process as just a refinement to the one that we’ve been using for several years. And the refinement has been very good. It’s kind of rounded out the one place that wasn’t working ideally before. And the timing was good. We’re really embarking on what we call Go 2.0. Or, Go 2 — sorry no “point 0.” It’s just Go 2. Making more revisions to the language and tooling.

Go modules was the first major change that we’re going to roll out, and we’re working on other things. Other things that are upcoming are the way Go handles errors — and we have a proposal that we’re working through with that — and generics. We published the proposals for these late last year, and we’re working with the community. It’s a very community-driven effort, getting feedback and refinements. Those are two big things that we’re very focused on getting right for our users.

So when will these actually land?

When we get it right. Because we’ve honestly — we really respect our users. And we want to make sure we do right by them. For us it is much more important to give them a right solution — we’ll say two years from now — than a right-now solution that doesn’t quite meet their needs. And so, you know, we do feel a lot of pressure to get it right, a lot more than we feel pressure to get it now. And we think that’s the right thing we can do for our users

You’ve also got to worry about preserving backward compatibility too.

That is a huge focus of ours…

In November of 2009 we open sourced Go, and a couple years later we had our first 1.0 release, and at that time we made our commitment that we were not going to make changes to the language. Any version going forward would be compatible with code written for 1.0. And that’s remained true for the last — over five years…

That’s why I made the distinction of “Go 2.0” versus “Go 2”. Our intent here is actually to keep everything compatible with Go 1, and to not ever have a breaking — we have no intent, and we’re trying hard to avoid, a breaking release. And, you know, we might eventually get to the point where we realize that that — that we need to do it, but so far, we’re optimistic that we won’t have a breaking release, and we can add these great features to the language while keeping compatibility with all the Go code that’s out there that’s been written over the last 10 years.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Docker.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.