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.
Microservices / Software Development

This Week in Programming: When NOT to Do Microservices

This Week in Programming gathers all the latest news from around the Web on development for cloud native computing.
Jan 11th, 2020 6:00am by
Featued image for: This Week in Programming: When NOT to Do Microservices
Feature image: Post Malone, from Tore Sætre, via Wikipedia, licensed under CC BY-SA 4.0.

Microservices, microservices, microservices, microservices. By now, you’ve perhaps heard the word so much, you can’t help but return to the chant of “developers” by a sweaty Steve Ballmer on stage a decade ago.

Maybe your company has already made the switch, leaving behind its legacy monolith for the promised land of a distributed architecture, or maybe it’s just pondering the move. After all, everything’s better as a microservice, right?

Maybe not.

This week, we hear the tale of one such software project that has gone down the path of microservices, only to decide that monolith was indeed the way to go, and it comes to us from a project you might otherwise think would do nothing other than be 100% all in on distributed architecture — the open source service mesh Istio.

The tale comes to us from Christian Posta, a field chef technology officer with, who offers up Istio as an example of when not to do microservices, writing that “a microservices approach may be appropriate when the culmination of an application’s architecture has become a bottleneck (as a result of the various people/process/tech factors) for making changes and “going faster,” but it’s not the only approach.

In the case of Istio, you might imagine that a tool that is meant to “help solve difficult application-networking challenges introduced by a microservices/cloud architecture,” writes Posta, would be best served by a microservices architecture itself. Instead, Istio plans to revert to a more monolithic approach with Istio 1.5, expected out next month, for a simple reason, which Posta cites from some design docs: “The complexity of the microservices approach proved to not deliver the value or goals it intended. On the contrary, it worked against those goals.”

Posta offers a diagram that shows the complexity of the current implementation, and it has some semblance of a bowl of spaghetti. Skipping the nitty-gritty details of Istio itself, one bit in the middle of his post really captures the issue at hand here:

The #1 tradeoff when going to a microservices architecture is complexity. When you go from one thing (monolith) to a bunch of little things communicating with each other (to optimize for a particular concern), you significantly increase complexity both in the architecture as well as the infrastructure necessary to run things.

This may be a necessary tradeoff insofar you realize the benefits. If not, it’s best you evaluate your assumptions and correct course. That’s what’s happening with Istio right now.

The resultant diagram instead looks like the spaghetti while it’s still in the box — all neat and orderly and simple. Now, of course, this might be the tale of microservices in general, but the point is that all that complexity is only worthwhile in the end if it delivers the desired results. Whether it’s because of scaling concerns, the desire to use different languages for different purposes, domain groupings, or security concerns, there are valid reasons for microservices, but simply avoiding the feared term “monolith” is just not one of them.

For Istio, the move back to the monolith now offers its users some benefits that they did not enjoy while enduring the utopia of a microservice architecture, writes Posta, including a simple installation with a single deployable service, reduced configuration complexity, easier debugging, and an increased efficiency.


This Week in Programming

  • Visual Studio Code’s 2020 Python Release: To start us off on the news end of things this week, all you Visual Studio Code Python developers have a new Visual Studio Code January 2020 release to install. The latest Python extension offers performance improvements in the Jupyter Notebook editor, kernel selection in Jupyter Notebooks, auto-activation of environments in the terminal on load, and fixes to rebuilding ctags on save and on start. Now, we know how much y’all like Python, and we hate to be the ones to break it to you, but…
  • …C Is Now The Most Popular: Or at least, so sayeth the TIOBE Index, which is a ranking of top programming languages according to “the number of skilled engineers world-wide, courses and third-party vendors” and, well, searches on Google, Bing, what have you. While Python had taken the top spot for 2018, and, as they write in the blog post, “everybody thought that Python would become TIOBE’s programming language of the year for the second consecutive time,” C beat it out. Why? It gives credit for C’s popularity to the Internet of Things, where C is both universally available and fast. TIOBE also points to gains by Swift and Ruby as a standout, while Rust, Kotlin, Julia and TypeScript did not fare as well as expected. But hey, it’s all just a horse race, so code in what works, right?

  • Ruby Releases 2.7 With Improved Garbage Collection: Speaking of Ruby, the 25-year-old language has just released Ruby 2.7 and InfoWorld brings us the details on the latest production release, which it says notably improves garbage collection and pattern matching. According to the release notes for Ruby 2.7, the features of note include pattern matching, improvement of the read-eval-print-loop (REPL), the introduction of compaction garbage collection, and the separation of positional and keyword arguments. Take a gander at either for the detailed explanations.
  • Go Marches On with Go 1.14: Go, meanwhile, continues its march forward with Go 1.14, which InfoWorld again details, noting that this latest version focuses on runtime and compiler improvements, as well as to Windows and WebAssembly support. The release isn’t out quite yet, but rather expected for mid-February, and the release notes point to this version as “the last Go release to support 32-bit binaries on macOS.”

  • The Retrospectives and Resolutions Continue: You thought we were through with 2019? That resolutions were behind you? Not quite. As the new year still dawns upon us, some of us are still stuck in 2019, and others still think there’s time left to squeeze in one last prediction for 2020. Without further ado, here are a few that crossed our feeds that you might find worthy. First, JavaScript package manager npm offered up a security review for 2019 with some basic numbers, such as 737 erroneously published npm tokens revoked, and $13 million of cryptocurrency saved from theft by catching the Komodo Agama wallet backdoor. AWS offered up a list of the top ten AWS open source blog posts and GitLab offered a review of 2019 that explored all of the highlights in terms of product, community, and company. And for those of you still ironing out your strategy for a new you in 2020, Hacker News had a thread on what technologies to learn in 2020. Top answer? “Learn how to really use a relational database, relational data modeling, and SQL.”

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