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 / Tech Life

This Week in Programming: Pondering the Evolution of Perl 7

This Week in Programming brings together all the latest developer news for the cloud native computing community.
Aug 15th, 2020 6:00am by
Featued image for: This Week in Programming: Pondering the Evolution of Perl 7

Earlier this year, we saw the introduction of Perl 7, with the new version billed as mostly just Perl 5.32, “but with different, saner, more modern defaults.” Of course, while that’s true, there is some general disagreement to be found among the Perl community and some who are, according to Perl Foundation board member Ricardo Signes asking “what the hell is going on?” recently drew some attention to the topic of “the proposed Perl 7 fork” (a characterization that some in the comments took issue with, preferring that Raku be identified as such), posting a full response by Signes to a Perl emailing list answering just that question.

While, as we noted, Perl 7 was introduced with a tone that seemed to say not much was changing, the core idea of moving to version 7 was true that the language could move beyond some past restrictions. Such changes, you might expect, are met with resistance and confusion, and this case is no exception. “The central Perl 7 question is not about version numbering, but rather about backward compatibility guarantees,” Signes writes in his response. “Maybe there are kinds of backward compatibility that can be shrugged off without disrupting the vast majority of Perl users, while making the language easier to use and (very importantly) easy to *continue* to improve.  This is obviously the core hope of the Perl 7 plan.”

The question of breaking compatibility, however, is just the first point of contention, he notes before moving on to the second — if it should be broken, then how? On this point, a passage from Signes’s message stands out:

“There is not yet a consensus here, seemingly among any two people. There is not a cabal of people saying ‘let’s all break these five things we agree on, quick, before anybody can stop us.’ I think sometimes it smells that way, but I have been in the discussions about what we can and should change, and why, and there is no unified front,” he writes. “The big agreement is, if anything, ‘Changing the version numbering to make it clear when to expect breaking changes is reasonable.'”

The plan, he writes, “is to come up with a plan,” for which the Perl Steering Committee has been formed (or at least is in the process of doing so) and Signes offers some words of assurance to those who may question the languages movement toward Perl 7, the next version that isn’t quite so simply agreeable as it may have initially seemed on the surface.

“You should not expect to see a stream of unjustified dictates issuing forth from some secret body on high. You should expect to see perl5-porters operating as it generally did: with proposals coming to the list, getting discussion, and then being thumbed up or down by the project manager,” writes Signes. “This is what has been happening for years, already.  Some proposals were already discussed by the project manager and some were not.  If you eliminated any named mailing list for doing this, it would still happen. The PSC is a means to say that there is a default group for such discussions.”

If you’re looking for further assurance, fellow Perl Foundation board member Curtis “Ovid” Poe also offers his opinion on the move to Perl 7 in an interview, saying that he is “100% on board with the project” and noting that “there’s a difference between having a goal and having a plan. There’s widespread agreement on the goal, but there’s less agreement about the plan. That’s great so long as people can use this to find the best path.”

This Week in Programming

  • Google Intros a Chrome Dev Portal, of Sorts: Given the recent boom in Chromebook sales (127% year over year growth compared to 40% for other notebooks), Google is getting even more serious about its foray into Chromebooks with the introduction of a “dedicated resource for technical developers, designers, product managers and business leaders” The site will host news, product announcements, technical documentation, and code samples, as well as practical tips from experts. The site, Google notes, will be fully open-source and “designed considering all the principles and methods for creating highly capable and reliable Progressive Web Apps (PWAs).”
  • Go 1.15 Arrives with “No Changes to the Language”: This week saw the release of Go 1.15, which includes a number of changes to the implementation of the toolchain, runtime, and libraries, but no changes to the language itself, according to the release notes. Highlighted changes include “substantial” improvements to the Go linker and a number of Core Library improvements, among others, and the team says that they “expect almost all Go programs to continue to compile and run as before.” DevClass further writes up the news, noting that “the linker has become 20 per cent faster, requiring 30 per cent less memory on average” for certain operating systems running on AMD64 architectures. The linker improvements are expected to continue with further releases and, for now, the Go community can enjoy a release with seemingly little debate.

  • Jupyter Book Gets Re-Written “from the Ground up”: If you’re looking to present data findings using Python in an interactive way, with live code, equations, visualizations and narrative text, then Jupyter Notebooks have been your go-to. Now, if you want to compile a number of those notebooks together into “publication-quality books, websites, and documents from source material that contains computational content,” Jupyter Books are one way you can do that. This week, Jupyter has announced a new Jupyter Book, “re-written from the ground up, making it easier to install, faster to use, and able to create more complex publishing content in your books.” Currently in beta, the updated Book is now supported by the Executable Book Project and, while retaining a similar feel, has “a lot of new features due to the new Jupyter Book stack underneath.” Among the biggest changes, they write, Jupyter Books now support the Markedly Structured Test (MyST) Markdown language, which is a superset of Jupyter Markdown, meaning that any default markdown in a Jupyter Notebook is valid in Jupyter Book. For the full details on the update, check out the post or dive into the new Jupyter Book documentation or the Jupyter Book GitHub repository.
  • Facebook Opens up Pysa, a Python Static Analyzer: Speaking of Python, Facebook has decided to open up about Pysa, an open source static analysis tool to detect and prevent security issues in Python code, whose name is short for “Python Static Analyzer.” The tool is built on top of their type checker for Python, Pyre, and helps to detect a wide range of issues, from proper use of frameworks to detecting common web app security issues, like XSS and SQL injection. So far, they say that the tool has detected “44 percent of the issues that our engineers found in the Instagram server codebase” in just the first half of 2020, and “330 unique issues in proposed code changes which we categorized by severity.” If you want to give Pysa a try on your own code, check out  the documentation and tutorial.

Feature image by Suzanne D. Williams on Unsplash.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.