Tech News - Languages

Yesterday, Microsoft released a new static type checker for Python called Pyright to fill in the gaps in existing Python type checkers like mypy. Currently, this type checker supports Python 3.0 and its newer versions. What are the type checking features Pyright brings in? It comes with support for PEP 484 (type hints including generics), PEP 526 (syntax for variable annotations), and PEP 544 (structural subtyping). It supports type inference for function return values, instance variables, class variables, and globals. It provides smart type constraints that can understand conditional code flow constructs like if/else statements. Increased speed Pyright shows 5x speed as compared to mypy and other existing type checkers written in Python. It was built keeping large source bases in mind and can perform incremental updates when files are modified. No need for setting up a Python Environment Since Pyright is written in TypeScript and runs within Node, you do not need to set up a Python environment or import third-party packages for installation. This proves really helpful when using the VS Code editor, which has Node as its extension runtime. Flexible configurability Pyright enables users to have granular control over settings. You can specify different execution environments for different subsets of a source base. For each environment, you can specify different PYTHONPATH settings, Python version, and platform target. To know more in detail about Pyright, check out its GitHub repository. Debugging and Profiling Python Scripts [Tutorial] Python 3.8 alpha 2 is now available for testing Core CPython developer unveils a new project that can analyze his phone’s ‘silent connections’  

Oracle has announced a major shift in the pricing structure for various offerings of Java. Currently, there are many offerings for the core Java language in terms of Java binaries, Java for desktops, commercial offering, among others. Java binaries are offered free for developers under the General Public License 2 (GPL 2). Java SE is offered, at an entry-level support, for $2.50/desktop for a month, or $25/CPU for a month. Under the free offering for developers, Oracle will provide OpenJDK builds (the backend that keeps Java running on any system) under the GPL + CPE license. To make the offering more flexible, Oracle is working on Oracle JDK which would support Java SE 11 (the LTS release) set to launch in September 2018. With Oracle JDK, Oracle is trying to make the offering of Java binaries simpler for the developers as it would be royalty-free for open-source development, testing, etc. For the commercial license, Oracle will be offering the Java SE Subscriptions combined with the technical support and access to all the updates that will follow the Java SE release cycle. Apart from the commercial offering, Oracle also has varied pricing for offerings through Oracle Academy. With the new Java SE Subscription, comes with a feature called Java Advanced Management Console. This feature will enable the license holders to identify, manage, and tune Java SE use in systems used across the enterprise. It also includes Oracle Premier Support, to enable support for Java across current and previous versions. Oracle, in their press release, mentioned the update in the subscription model is inspired by how Linux provides support for updates in the platform. It mentions "the subscription model for updates and support has been long established in the Linux ecosystem". By this new subscription model, Oracle ensures that anyone requiring the additional level of support for Oracle products can receive it with flexible pricing and still keep a balance between its open source and commercial offerings. For all the details on these subscriptions, you can visit the Java SE subscription FAQs. Oracle reveals issues in Object Serialization. Plans to drop it from core Java. 5 Things you need to know about Java 10 Oracle Apex 18.1 is here!

Yesterday, the Rust team announced the release of Rust 1.35.0. This release highlights the implementation of Fn* closure traits for Box<dyn Fn*>. Additionally it has features like coercing closures which are extended to unsafe fn pointers, dbg! macro can now be called without passing any arguments, a number of APIs have become stable and many more. Key features explained in brief: Fn* closure traits implemented for Box<dyn Fn*> In Rust 1.35.0, the FnOnce, FnMut, and the Fn traits are now implemented for Box<dyn FnOnce>, Box<dyn FnMut>, and Box<dyn Fn> respectively. This allows users to use boxed functions in places where a function is to be implemented. It is also now possible to directly call Box<dyn FnOnce> objects. Coercing closures to unsafe function pointers In the earlier versions, it was possible to coerce closures which do not capture from the environment, into function pointers only . With this release, coercing closures has been extended to ‘unsafe’ function pointers also. Calling dbg!() with no argument ‘dbg!()’ macro allows to quickly inspect the value of some expression with context. Now, users can call dbg!() without passing any arguments. This is useful in tracing what branch your application will take. Library stabilizations In 1.35.0, a number of APIs have become stable. Few new implementations and other changes have also been made. Some are mentioned below: Copy the sign of a floating point number onto another Check whether a Range contains a value Map and split a borrowed RefCell value in two Replace the value of a RefCell through a closure Hash a pointer or reference by address, not value Copy the contents of an Option<&T> To know more about the changes in Library, head over to the release notes page. Changes in Clippy Clippy is a collection of lints to catch common mistakes and improve the Rust code. In this release of Rust, a new lint ‘drop_bounds’ has been added. Also Clippy has split the lintredundant_closure into redundant_closure and redundant_closure_for_method_calls. Changes in Cargo When passing a test filter, such as ‘cargo test foo’, the user does not have to build examples (unless they set test = true). ‘rustc-cdylib-link-arg’ key has been added to build scripts to specify linker arguments for cdylib crates. ‘Cargo clippy-preview’ is now a built-in cargo command. The verification step in ‘cargo package’ that checks if any files are modified is now stricter. It uses a hash of the contents instead of checking file system mtimes. It also checks all files in the package. To know more about the changes in Cargo, head over to the release notes page. Read more about the Rust 1.35.0 announcement on the official Rust blog. Read More Rust’s recent releases 1.34.0 and 1.34.1 affected from a vulnerability that can cause memory unsafety Rust 1.34 releases with alternative cargo registries, stabilized TryFrom and TryInto, and more Rust shares roadmap for 2019

On Tuesday, ActiveState a Canadian software company announced to add thousands of Python packages to its ActiveState Platform. ActiveState helps enterprises scale securely with open source languages and offers developers various tools to work on. More than 2 million developers and 97% of Fortune 1,000 enterprises use ActiveState to support mission-critical systems and speed up their software development process. The ActiveState Platform is a SaaS platform for open source language automation to centrally build, certify and resolve runtime environments. It incorporates more than 20 years of engineering expertise in order to automate much of the complexity associated with building, maintaining and sharing Python and Perl runtimes. With minimal knowledge, a developer can automatically build open source language runtimes, resolve dependencies, and certify it against compliance and security criteria. The result is a consistent, reproducible runtime from development to production. In this latest installment, the company has added more than 50,000 package versions covering the most popular Python 2 and 3 packages, as well as their dependencies. These dependencies can be automatically resolved, built and packaged into runtimes to eliminate issues. “Python is one of the most popular programming languages on the planet right now, so it's no wonder that the majority of the more than 200,000 developers on the ActiveState Platform are asking us to do more to support their Python development efforts. In order to ensure our customers can automatically build all Python packages, even those that contain C code, we're designing systems to vet the code and metadata for every package in PyPI. Today's release is a significant first step toward that goal.” says Jeff Rouse, Vice president, product management at ActiveState. The company is preparing itself for Python 2 EOL and in the process, it has vetted thousands of key Python 2 packages critical to the support of customers' Python 2 applications. In addition, the company has added many of the most popular Python 3 packages to support the efforts of their broad and wide customer base. It is a significant milestone on the road to make all of the Python Package Index (PyPI) available on the ActiveState Platform. To know more about this news, check out the official press release by the company. Listen: How ActiveState is tackling “dependency hell” by providing enterprise-level support for open source programming languages [Podcast] Introducing ActiveState State Tool, a CLI tool to automate dev & test setups, workflows, share secrets and manage ad-hoc tasks Python 3.9 alpha 1 is now ready for testing PyPI announces 2FA for securing Python package downloads Getting Started with Python Packages

Microsoft yesterday unveiled Static TypeScript as an alternative to embedded interpreters. Static TypeScript (STS) is an implementation of a Static Compiler for TypeScript which runs in the web browser. It is primarily designed to aid school children in their computer science programming projects. STS is supported by a compiler that is also written in Typescript. It generates machine code that runs efficiently on Microcontrollers in the target RAM range of 16-256kB. Microsoft’s plan behind building Static TypeScript Microcontrollers are typically programmed in C, C++, or in assembly, none of which are particularly beginner friendly. MCUs that can run on modern languages such as JavaScript and Python usually involve interpreters like IoT.js, Duktape, or MicroPython. The problem with interpreters is high memory usage, leaving little room on the devices themselves for the program developers have written. Microsoft therefore decided to come with STS which is a more efficient alternative to the embedded interpreter approach. It is statically typed, which makes for a less surprising programming experience. Features of Static TypeScript STS eliminates most of the “bad parts” of JavaScript; following StrongScript, STS uses nominal typing for statically declared classes and supports efficient compilation of classes using classic techniques for vtables. The STS toolchain runs offline, once loaded into a web browser, without the need for a C/C++ compiler. The STS compiler generates efficient and compact machine code, which unlocks a range of application domains such as game programming for low resource devices . Deployment of STS user programs to embedded devices does not require app or device driver installation, just access to a web browser. The relatively simple compilation scheme for STS leads to surprisingly good performance on a collection of small JavaScript benchmarks, often comparable to advanced, state of the art JIT compilers like V8, with orders of magnitude smaller memory requirements. Differences with TypeScript In contrast to TypeScript, where all object types are bags of properties, STS has at runtime four kinds of unrelated object types: A dynamic map type has named (string-indexed) properties that can hold values of any type A function (closure) type A class type describes instances of a class, which are treated nominally, via an efficient runtime subtype check on each field/method access An array (collection) type STS Compiler and Runtime The STS compiler and toolchain (linker, etc.) are written solely in TypeScript. The source TypeScript program is processed by the regular TypeScript compiler to perform syntactic and semantic analysis, including type checking. The STS device runtime is mainly written in C++ and includes a bespoke garbage collector. The regular TypeScript compiler, the STS code generators, assembler, and linker are all implemented in TypeScript and run both in the web browser and on command line.  The STS toolchain, implemented in TypeScript, compiles STS to Thumb machine code and links this code against a pre-compiled C++ runtime in the browser, which is often the only available execution environment in schools. Static TypeScript is used in all MakeCode editors STS is the core language supported by Microsoft’s MakeCode Framework. MakeCode provides hands on computing education for students with projects. It enables the creation of custom programming experiences for MCU-based devices. Each MakeCode editor targets programming of a specific device or device class via STS. STS supports the concept of a package, a collection of STS, C++ and assembly files, that also can list other packages as dependencies. This capability has been used by third parties to extend the MakeCode editors, mainly to accommodate hardware peripherals for various boards. STS is also used in MakeCode Arcade. With Arcade, STS lets developers of all skill levels easily write cool retro-style pixelated games. The games are designed by the user to be run either inside a virtual game console in the browser or on inexpensive microcontroller-based handhelds. For more in-depth information, please read the research paper. People were quite interested in this development. A comment on Hacker News reads, “This looks very interesting. If all it takes is dropping “with, eval, and prototype inheritance” to get fast and efficient JS execution, I’m all for it.” Other news in tech TypeScript 3.6 releases with stricter generators, new functions in TypeScript playground, better Unicode support and more Microsoft announces XLOOKUP for Excel users that fixes most VLOOKUP issues Microsoft announces its support for bringing exFAT in the Linux kernel; open sources technical specs

Yesterday, the Program Manager at Typescript, Daniel Rosenwasser announced the release of TypeScript 3.6. This is a major release of TypeScript as it contains many new features in Language and Compiler such as stricter generators, more accurate array spread, improved UX around Promises, better Unicode support for identifiers, and more. TypeScript 3.6 also explores a new TypeScript playground, new Editor features, and many breaking changes. TypeScript 3.6 beta was released last month. Language and Compiler improvements Stricter checking to Iterators and Generators Previously, generator users in TypeScript could not differentiate if a value was yielded or returned from a generator. In TypeScript 3.6, due to changes in the Iterator and IteratorResult type declarations, a new type called the Generator type has been introduced. It is an Iterator that will have both the return and throw methods present. This will allow a stricter generator checker to easily understand the difference between the values from their iterators. TypeScript 3.6 also infers certain uses of yield within the body of a generator function. The yield expression can be used explicitly to enforce the type of values that can be returned, yielded, and evaluated. More accurate array spread In pre-ES2015 targets, TypeScript uses a by default --downlevelIteration flag to use iterative constructs with arrays. However, many users found it undesirable that emits produced by it had no defined property slots. To address this problem, TypeScript 3.6 presents a new __spreadArrays helper. It will “accurately model what happens in ECMAScript 2015 in older targets outside of --downlevelIteration.” Improved UX around Promises TypeScript 3.6 explores new improvements in the Promise API, which is one of the most common ways to work with asynchronous data. TypeScript’s error messages will now inform the user if a then() or await content of a Promise API is not written before passing it to another function. The Promise API will also provide quick fixes in some cases. Better Unicode support for Identifiers TypeScript 3.6 contains better support for Unicode characters in identifiers when emitting to ES2015 and later targets. import.meta support in SystemJS: The new version supports the transformation of import.meta to context.meta when the module target is set to system. get and set accessors are allowed in ambient contexts: The previous versions of TypeScript did not allow the use of get and set accessors in ambient contexts. This feature has been changed in TypeScript 3.6, since the ECMAScript’s class fields proposal have differing behavior from an existing version of TypeScript. The official post also adds, “In TypeScript 3.7, the compiler itself will take advantage of this feature so that generated .d.ts files will also emit get/set accessors.” Read Also: Microsoft introduces Pyright, a static type checker for the Python language written in TypeScript New functions in TypeScript playground The TypeScript playground allows users to compile TypeScript and check the JavaScript output. It has more compiler options than typescriptlang and all the strict options are turned on by default in the playground. Following new functions are added in TypeScript Playground: The target option which allows users to switch out of es5 to es3, es2015, esnext, etc All the strictness flags Support for plain JavaScript files The post also states that in the future versions of TypeScript, more features like JSX support, and polishing automatic type acquisition can be expected. Breaking Changes Class members named "constructor" are now simply constructor functions. DOM updates like the global window will no longer be defined as type Window. Instead, it is defined as type Window & typeof globalThis. In JavaScript files, TypeScript will only consult immediately preceding JSDoc comments to figure out declared types. TypeScript 3.6 will not allow the escape sequences. Developers have liked the new features in TypeScript 3.6. https://twitter.com/zachcodes/status/1166840093849473024 https://twitter.com/joshghent/status/1167005999204638722 https://twitter.com/FlorianRappl/status/1166842492718899200 Interested users can check out TypeScript’s 6-month roadmap. Visit the Microsoft blog for full updates of TypeScript 3.6. Next.js 9 releases with built in zero-config TypeScript support, automatic static optimization, API routes and more Babel 7.5.0 releases with F# pipeline operator, experimental TypeScript namespaces support, and more TypeScript 3.5 releases with ‘omit’ helper, improved speed, excess property checks and more

Python made it to the TIOBE index in the third position for the first time in its history. The TIOBE programming community index is a common measure of programming language popularity. It is created and maintained by the TIOBE company based in the Netherlands. The popularity in the index is calculated based on the number of search engine results for search queries with the name of the language. They consider searches from Google, Google Blogs, MSN, Yahoo!, Baidu, Wikipedia, and YouTube. The TIOBE index is updated once a month. Source: TIOBE Python is third behind Java and C. Python’s rating is 7.653 percent while Java had a rating of 17.436 percent. C was in the second place rated at 15.447 percent. Python moved above C++ to be placed third. C++ was third last month and now is in the fourth place this month, with a rating of 7.394 percent. Python has increasing ubiquity, being used in many research areas like AI and machine learning which are all the buzz today. The increasing popularity is not surprising as Python has versatile applications. AI and machine learning, software development, web development, scripting, scientific applications, and even games, you name it. Python is easy to install, learn, use, and deploy. The syntax is also very simple and beginner friendly. TIOBE states that this third place took a really took a long time. “At the beginning of the 1990s it entered the chart. Then it took another 10 years before it reached the TIOBE index top 10 for the first time. After that it slowly but surely approached the top 5 and eventually the top 3.“ Python has also been the language of the year in the index for the years 2007 and 2010. The current top 5 languages are Java, C, Python, C++, and Visual Basic .NET. To read more and to view the complete list of the index, visit the TIOBE website. Build a custom news feed with Python [Tutorial] Home Assistant: an open source Python home automation hub to rule all things smart Build botnet detectors using machine learning algorithms in Python [Tutorial]

Oracle has announced the release of Java 10 version on March 20. While this is not an LTS version, there are few changes in this version which are worth noting. In this article we’ll look at  5 of the most important things you’ll need to watch out for, especially if you’re a Java developer. Java releases long term support versions in every 3 year. As per this scheduling, their future long term support version, Java 11 will be releasing in Fall 2018. Java 10 is a precursor to that and contains some important changes which will take a clearer shape in the next version. Java 10 is trying to emulate some of the popular features of Scala and Kotlin. One of the primary reasons can be the growing popularity of Kotlin in both web and mobile development domain and also the dynamic typing capability in Scala and Kotlin both.  The introduction of local variable type is one of them. This feature implies that variables can now be declared as “var” and when you assign a certain integer or a string to it then the compiler will automatically know what type of variable it is. Although this doesn’t make Java a dynamically typed language like Python, still this allows a lot more flexibility for the programmers and lets them avoid boilerplates in their code. There are 2 JEPs in JDK 10 that focus on improving the current Garbage Collection (GC) elements. The first one, Garbage-Collector Interface (JEP 304) will introduce a clean garbage collector interface to help improve the source code isolation of different garbage collectors. In current Java versions there are bits and pieces of GC source files scattered all over the HotSpot sources. This becomes an issue when implementing a new garbage collector, since developers have to know where to look for those source files. One of the main goals of this JEP is to introduce better modularity for HotSpot internal GC code, have a cleaner GC interface and make it easier to implement new collectors. Java 10 promises to become much faster than its previous version by making the full garbage collector parallel. This is a welcome move and change from the version 9 since this allows the developers scope to better allocate memory and use the GC (Garbage Collector) in parallel. The GC  in the previous versions didn’t have the capability to load values in parallel and that made it heavy and difficult to operate for complex applications. The present parallel GC removes that factor and makes it much more lightweight and efficient. Java 10 enables programmers to allow heap allocation on alternative memory devices. This feature lets the Java VM decide on the most important tasks and then allocate maximum memory for those priority processes with other processes are allocated to alternative memory. This helps in fastening up the overall process. This change is important for the Java developers because this will help them in better and efficient memory management and hence will increase the performance of their applications. With these changes, Java 10 has opened up the doors for a more open and flexible language which is looking towards the future. With Kotlin breathing down its neck as a worthy alternative, the stage is set for Java to work towards a more dynamic and easy to use power packed version 11 in 2018 fall. We would be waiting for that along with the Java developers for sure. What can you expect from the upcoming Java 11 JDK? Oracle reveals issues in Object Serialization. Plans to drop it from core Java. Java Multithreading: How to synchronize threads to implement critical sections and avoid race conditions  

In a blog post, the state of Rust and WebAssembly for 2018 was discussed by the Rust-Wasm team. The Rust and WebAssembly domain working group worked to make a shared vision into a reality: “Compiling Rust to WebAssembly should be the best choice for fast, reliable code for the Web.” With the evolution of ideas, another core value was formed: “Rust and WebAssembly is here to augment your JavaScript, not replace it.” Goals were set for the joint ecosystem. #1 JavaScript interoperation with zero-cost By leveraging zero-cost abstractions Rust enables fast and expressive code. The Rust team wanted to apply this principle to the whole JS interop infrastructure. Developers can write their own boilerplate to pass DOM nodes to wasm generated by Rust but that shouldn’t be the case. Hence they created wasm-bindgen as the foundation for JavaScript interoperation with zero cost. The communication between JavaScript and WebAssembly is facilitated by wasm-bindgen. This generates glue code which developers would have had to write themselves. With the wasm-bindgen ecosystem helps developers to: Exporting rich APIs from Rust-generated wasm libraries. This makes them callable from JavaScript. Import JavaScript and Web APIs into the Rust-generated wasm. #2 Rust-Generated Wasm as an NPM library Good integration is about fitting Rust-generated WebAssembly into the JavaScript’s distribution mechanisms. A big part of that is NPM. The Rust team built a wasm-pack to creating and publishing NPM packages from Rust and WebAssembly code. Sharing Rust-generated wasm modules is now as simple as: wasm-pack publish #3 To get developers productive fast The Rust team wrote a Rust and WebAssembly book to teach all the ins and outs of WebAssembly development with Rust. It features a tutorial to build an implementation of the Conway's Game of Life and teaches you how to write tests, debugging, and diagnosing slow code paths. Getting a Rust-WebAssembly project set up initially involves a boilerplate and configuration that new users may find difficult or experienced ones may find as a waste of time. Hence the Rust team has created a variety of project templates for different use cases: wasm-pack-template to create NPM libraries with Rust and Wasm. create-wasm-app to create Web applications built on top of Rust-generated wasm NPM libraries. rust-webpack-template to create whole Web applications with Rust, WebAssembly, and the Webpack bundler. rust-parcel-template to create whole Web applications with Rust, WebAssembly, and the Parcel bundler. #4 Rust-Generated Wasm needs to be testable and debuggable wasm can’t log any panics or errors because by default as it doesn’t have any “syscall” or I/O functionality. Imports have to be manually added for that, and then instantiate the module with appropriate functions. To remedy this, and to ensure that panics are always debuggable, the Rust team created the console_error_panic_hook crate. It redirects panic messages into the browser’s devtools console. For more details on the state of the joint ecosytem in 2018, visit the Rust and WebAssembly Blog. Mozilla shares plans to bring desktop applications, games to WebAssembly and make deeper inroads for the future web Red Hat announces full support for Clang/LLVM, Go, and Rust WebAssembly – Trick or Treat?

The discussions regarding the Julia release process started last year when it hit Julia 1.0. Yesterday, Stefan Karpinski, one of Julia's core developers shared its finalized release process giving details on the kind of releases, the stages of the release process, the phases of a release, and more. “This information is collected from a small set of posts on discourse and conversations on Slack, so the information exists “out there”, but this blog post brings it all together in a single place. We may turn this post into an official document if it’s well-received,” Stefan wrote. Types of Julia releases As with most programming languages that follow Semantic Versioning (SemVer), Julia has three types of releases: Patch, Minor, and Major. A patch release will be represented by the last digit of Julia’s version number. It will include things like bug fixes, low-risk performance improvements, and documentation updates. The team plans to release a patch every month for the current active release branches, however, this will depend on the number of bug fixes. The team also plans to run PackageEvaluator (PkgEval) on the backports five days prior to the patch release. PkgEval is used to run tests for every registered package, update the web pages of Julia packages, and create status badges. A minor release will be represented by the middle digit of Julia’s version number. Along with some bug fixes and new features, it will include changes that are unlikely to break your code and the package ecosystem. Any significant refactoring of the internals will also be included in the minor release. Since minor releases are branched every four months, developers can expect three minor releases every year. A major release will be represented by the first digit of Julia’s version number. Typically, major releases consist of breaking changes, but the team assures to introduce them only when there is an absolute need, for instance, fixing API design mistakes. It will also include low-level changes that can end up breaking some libraries but are essential for fundamental improvements to the language. Julia’s release process There are three phases in the Julia release process. The development phase takes up 1-4 months where new features are introduced, bugs are fixed, and more. Before the feature freeze, alpha (early preview) and beta (later preview) versions are released for developers to test them and to share their feedback. After the feature freeze, a new unstable release branch is created. In the development phase, the new features will be merged onto the master branch, while the bug fixes will go on the release branch. The second phase, stabilization, also takes up 1-4 months where all known release-blocking bugs are fixed and release candidates are built. Then they are checked for any more release-blocking bugs for one week and if there are none a final release is announced. After this, starts the maintenance phase where bug fixes are backported to the release branch. This continues till a particular release branch is declared to be unmaintained. To ensure the quality of releases and maintaining a predictable release rate the Julia team overlaps the development and stabilization phases. “The development phase of each release is time-boxed at four months and the development phase of x.(y+1) starts as soon as the development phase for x.y is over. Come rain or shine we have a new feature freeze every four months: we pick a day and you’ve got to get your features merged by that day. If new features aren’t merged, they’re not going in the release. But that’s ok, they’ll go in the next one,” explains Karpinski. Talking about long term support, Karpinski wrote that there will be four active branches. The master branch is where all the new features, bug fixes, and breaking changes will go. The unstable release branch will include all the active bug fixing and performance work that happens prior to the next minor release. The stable release branch is where the most recently released minor or major version exists. The fourth one is the long term support (LTS) branch, which is currently Julia 1.0. This branch continues to get applicable bug fixes until it is announced to be unmaintained. Karpinski also shared the different fault tolerance personas in Julia. Check out his post on the Julia blog to get a better understanding of the Julia release process. Julia announces the preview of multi-threaded task parallelism in alpha release v1.3.0 Julia Angwin fired as Editor-in-Chief of The Markup prompting mass resignations in protest Creating a basic Julia project for loading and saving data [Tutorial]  

Last week, Microsoft open-sourced its implementation of the C++ Standard Library, also known as STL. The library is shipped along with MSVC (Microsoft Visual C++ compiler) toolset and the Visual Studio IDE. This announcement was made by MSVC team at the CppCon 2019 conference, two days ago. Users can use the C++ library repo for participating in the STL's development by reporting issues and commenting on pull requests. The MSVC team is still working on migrating the C++ Standard Library to GitHub. Currently, the Github repository contains all of MSVC's product source code including a new CMake build system and a README. The team also plans to use the GitHub issues to track C++20 features, LWG issues, conformance bugs, performance improvements, and other todos. The roadmap and iteration plans of the C++ Standard Library is also under progress. Why Microsoft open-sourced the C++ Standard Library? Microsoft has open-sourced STL to allow it’s users easy access to all the latest developments in C++ by trying out latest changes and improving pull requests by reviewing them. The MSVC team hopes that as C++ standardization accelerates, it will be easier for users to accept the major features. Microsoft chose to open-source STL particularly due to its unique design and fast-evolving nature when compared to other MSVC libraries and compiler. It is also “easy to contribute to, and somewhat loosely coupled, unlike the compiler.” The official blog post adds, “We also want to contribute back to the C++ community by making it possible to take our implementations of major features.” What are the primary goals of the C++ Standard Library? Microsoft is implementing the latest C++ Working Draft, which will eventually become the next C++ International Standard. The goals of the Microsoft C++ Standard Library are to be conformant to spec, extremely fast, usable, and extensive compatibility. Speed being the core strength of C++, STL needs to be extremely fast at runtime. Thus, the MSVC team spends more time on the optimization of the C++ Standard Library than the most general-purpose libraries. They are also working on parts of the programming experience like compiler throughput, diagnostic messages, and debugging checks. They are also keeping VS 2019 binary-compatible with VS 2017 and VS 2015. They consider source compatibility to be important, but not all-important; breaking source compatibility can be an acceptable cost if done for the right reasons in the right way. The blog post states that MSVC’s STL is distributed under the Apache License v2.0 with LLVM Exceptions and is distinct from the libc++ library. However, if any libc++’s maintainers are interested in taking feature implementations from MSVC’s STL or in collaborating on the development of new features in both libraries simultaneously, the MSVC team will help irrespective of the licensing. Users have welcomed Microsoft’s move to open-source it’s C++ Standard Library (STL). A Redditor says, “Thank you! Absolutely amazing. It's been one of my guilty pleasures ever since I started with C++ to prod about in your internals to see how stuff works so this is like being taken to the magical chocolate factory for me.” Another user comments, “thank you for giving back to the open source world. ❤🤘” Interested readers can learn how to build with the Native Tools Command Prompt and a Visual Studio IDE on Github. Latest news in Tech Open AI researchers advance multi-agent competition by training AI agents in a simple hide and seek environment As Kickstarter reels in the aftermath of its alleged union-busting move, is the tech industry at a tipping point? Linux 5.3 releases with support for AMD Navi GPUs, Zhaoxin x86 CPUs and power usage improvements

On Monday, Neil Williams a software developer from Linux CodeHelp raised severity issues for Python 2 leaf packages in Debian which do not support Python 3. Neil has urged Debian maintainers to remove Python 2 from all the Debian packages. He specifically mentions one of the packages, Calibre, an e-book management software which is completely open source and licensed under the GNU GPL v3. Calibre is written primarily in Python with some C/C++ code for speed and system interfacing. But it is not yet compatible with Python 3 as it requires at least Python 2.7.9. In 2017, an issue was raised on the Calibre platform by a user, “Python 2 is retiring in thirty months. Calibre needs to convert to Python 3.” Kovid Goyal, author of the Calibre platform responded saying, “No, it doesn't. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.” Now the latest Calibre version requires Python modules which are no longer available for Python 2. Gregor Riepl, a systems engineer in response to Neil says, “As of now, calibre is not of sufficient quality to be part of a Debian release and until it drops all Python2 requirements, it must be considered RC buggy.” This means that Calibre >= 4.0 for the foreseeable future will not be available in Debian. Calibre version 3.48 will be the last version that can run on Debian until the upstream Calibre switches to Python 3. Riepl further asked Neil if his quality argument is due to the Calibre authors resistance to migrate to Python 3. Neil responded, “No, it is based just on the removal of Python2 from Debian and avoiding special cases. Right now, any and every package in Debian testing which requires Python2 and has no Python3 alternative in Debian or ready for upload is of poor quality for no other reason than that. All such packages are of such poor quality that the package should be removed from testing - in an orderly manner, leaf packages first. That is in the best interests of all users, despite what may or may not happen to any particular subset(s) of users.  The decision flow is easy - if the answer in each case is "no", then move on to the next and if you get to the bottom, the bug should be RC. * Has the package already been removed from testing? * Is a Python3-only version already in Debian? * Is a Python3-only version available upstream? * Does the package have any reverse dependencies? * If you get here, it is already too late, there have already been   enough warnings. Upgrade the bug to RC and get the package   auto-removed from testing.” Neil said he was aware of the history of Calibre and understood what would happen if it is no longer a part of Debian. But that did not matter as removal of Python 2 is more important for the next Debian release. He also believes that Calibre has a relatively large user base that doesn't know much or care about the Python 2 deprecation. User will simply perceive dropping Calibre as a bad move on Debian's side and rush towards other packages of significantly lower quality. He further concluded, “Calibre is nothing special - it's a Python2 leaf package like vland and tftpy and any one of far too many others. Calibre can stay in unstable - it will go FTBFS, of course, but that isn't a problem either, IMHO. It's calibre's problem - not Debian's problem. There's always the option of users installing the old Python2 stuff from Buster to keep calibre hobbling along. Debian is the higher priority here. Calibre would be nice to have but it does not deserve to cause delays on anybody else's voluntary effort. No package has that right.” Community feels Python 2 will result in unmaintained runtime and libraries in packages On Hacker News, users are discussing how Python foundation is pushing in packages to migrate to Python 3 that will result in Python 2 having an entire set of unmaintained runtime and libraries in the package repository. One user comments, “Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support. I doubt anyone is checking for potential security problems in Algol 68 and Fortran 77 implementations that Debian ships, and I don't think the people using those packages are particularly inconvenienced by that. It seems a shame that the social pressure to persuade people to port their code to Python 3 means that Debian is going to have weaker support for 10-year-old Python than 40-year-old Fortran. In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that.” Another user responded, “This isn't about "languages". It's about software! Algol 68 and Fortran 77 may have stale (but maintained) compilers or interpreters in the package repository. Starting very soon - Python 2 will have an entire set of unmaintained runtime and libraries in the package repository. You know - actual, officially, unmaintained software! Unmaintained software that other packages, including Calibre in this example, further build on. Of course they're throwing this out.” Python 3.8 is now available with walrus operator, positional-only parameters support for Vectorcall, and more Core Python team confirms sunsetting Python 2 on January 1, 2020 PyPy will continue to support Python 2.7, even as major Python projects migrate to Python 3

Last week, the Golang team announced that the Go module mirror, index, and checksum database are now production-ready thus adding reliability and security to the Go ecosystem. For Go 1.13 module users, the go command will use the module mirror and checksum database by default. New production-ready modules for Go 1.13 module Module Mirror A module mirror is a special kind of module proxy that caches metadata and source code in its own storage system. This allows the mirror to continue to serve source code that is no longer available from the original locations thus speeding up downloads and protect users from the disappearing dependencies. According to the team, module mirror is served at proxy.golang.org, which the go command will use by default for module users as of Go 1.13. For users still running an earlier version of the go command, they can use this service by setting GOPROXY=https://proxy.golang.org in their local environment. Read Also: The Go team shares new proposals planned to be implemented in Go 1.13 and 1.14 Module Index The module index is served by index.golang.org. It is a public feed of new module versions that become available through proxy.golang.org. Module index is useful for tool developers who want to keep their own cache of what’s available in proxy.golang.org, or to keep up-to-date on some of the newest modules go developers use. Read Also: Implementing Garbage collection algorithms in Golang [Tutorial] Checksum Database Modules introduced the go.sum file, a list of SHA-256 hashes of the source code and go.mod files of each dependency when it was first downloaded. The go command can use these hashes to detect misbehavior by an origin server or proxy that gives a different code for the same version. However, the go.sum file has a limitation, it works entirely by trust based on user’s first use. When a user adds a version of a never seen before dependency, the go command fetches the code and adds lines to the go.sum file quickly. The problem is that those go.sum lines aren’t being checked against anyone else’s and thus they might be different from the go.sum lines that the go command just generated for someone else. The checksum database ensures that the go command always adds the same lines to everyone's go.sum file. Whenever the go command receives new source code, it can verify the hash of that code against this global database to make sure the hashes match, ensuring that everyone is using the same code for a given version. The checksum database is served by sum.golang.org and is built on a Transparent Log (or “Merkle tree”) of hashes backed by Trillian, a transparent, highly scalable and cryptographically verifiable data store. The main advantage of a Merkle tree is that it is tamper-proof and has properties that don’t allow for misbehavior to go undetected, making it more trustworthy. The Merkle tree checks inclusion proofs (if a specific record exists in the log) and “consistency” proofs (that the tree hasn’t been tampered with) before adding new go.sum lines to a user’s module’s go.sum file. This checksum database allows the go command to safely use an otherwise untrusted proxy. Because there is an auditable security layer sitting on top of it, a proxy or origin server can’t intentionally, arbitrarily, or accidentally start giving you the wrong code without getting caught. “Even the author of a module can’t move their tags around or otherwise change the bits associated with a specific version from one day to the next without the change being detected,” the blog mentions. Developers are excited about the launch of the module mirror and checksum database and look forward to checking it out. https://twitter.com/hasdid/status/1167795923944124416 https://twitter.com/jedisct1/status/1167183027283353601 To know more about this news in detail, read the official blog post. Other news in Programming Why Perl 6 is considering a name change? The Julia team shares its finalized release process with the community TypeScript 3.6 releases with stricter generators, new functions in TypeScript playground, better Unicode support for identifiers and more

Last week, the Union Types 2.0 RFC by Nikita Popov, a software developer at JetBrains got accepted for PHP 8.0 with 61 votes in favor and 5 against. Popov submitted this RFC as a GitHub pull request to check whether it would be a better medium for RFC proposals in the future, which got a positive response from many PHP developers. https://twitter.com/enunomaduro/status/1169179343580516352 What the Union Types 2.0 RFC proposes PHP type declarations allow you to specify the type of parameters and return values acceptable by a function. Though for most of the functions, the acceptable parameters and possible return values will be of only one type, there are cases when they can be of multiple types. Currently, PHP supports two special union types. One is the nullable types that you can specify using the ‘?Type’ syntax to mark a parameter or return value as nullable. This means, in addition to the specified type, NULL can also be passed as an argument or return value. Another one is ‘array’ or ‘Traversable’ that you can specify using the special iterable type. The Union Types 2.0 RFC proposes to add support for arbitrary union types, which can be specified using the syntax T1|T2|... Support for Union types will enable developers to move more type information from ‘phpdoc’ into function signatures. Other advantages of arbitrary union types include early detection of mistakes and less boilerplate-y code compared to ‘phpdoc’. This will also ensure that type is checked during inheritance and are available through Reflection. This RFC does not contain any backward-incompatible changes. However, existing ReflectionType based code will have to be adjusted in order to support the processing of code that uses union types. The RFC for union types was first proposed 4 years ago by PHP open source contributors, Levi Morrison and Bob Weinand. This new proposal has a few updates compared to the previous one that Popov shared on the PHP mailing list thread: Updated to specify interaction with new language features, like full variance and property types. Updated for the use of the ?Type syntax rather than the Type|null syntax. It only supports "false" as a pseudo-type, not "true". Slightly simplified semantics for the coercive typing mode. In a Reddit discussion, many developers welcomed this decision. A user commented, “PHP 8 will be blazing. I can't wait for it.” While some others felt that this a one step backward. “Feels like a step backward. IMHO, a better solution would have been to add function overloading to the language, i.e. give the ability to add many methods with the same name, but different argument types,” a user expressed. You can read the Union Types 2.0 RFC to know more in detail. You can read the discussion about this RFC on GitHub. Symfony leaves PHP-FIG, the framework interoperability group Oracle releases GraphPipe: An open-source tool that standardizes machine learning model deployment Connecting your data to MongoDB using PyMongo and PHP

After releasing TypeScript 3.3 RC, two weeks ago, yesterday Microsoft announced the availability of TypeScript 3.3. TypeScript 3.3 contains no breaking changes and is a comparatively smaller release than usual. What’s new in Typescript 3.3 Better behavior when calling union types When there is a union type A | B, TypeScript now allows users to access all of the properties common to both A and B. For example, the intersection of members. You can get a property from a union type only if it’s known to be present in every union type. When every type has only one signature with identical parameters, things work. Such a restriction was too much and have errors in some areas. So, in TypeScript 3.3, the following code as shown in the blog will work: type Fruit = "apple" | "orange"; type Color = "red" | "orange"; type FruitEater = (fruit: Fruit) => number;     // eats and ranks the fruit type ColorConsumer = (color: Color) => string;  // consumes and describes the colors declare let f: FruitEater | ColorConsumer; f("orange"); // It works! Returns a 'number | string'. f("apple");  // error - Argument of type '"apple"' is not assignable to parameter of type '"orange"'. f("red");    // error - Argument of type '"red"' is not assignable to parameter of type '"orange"'. The parameters of the above signatures are ‘intersected’ to create a new signature. When the impossible intersections are gone, what remains is “orange” & “orange” which is just “orange”. That is not to say there are no restrictions. The new behavior is active only when only one type in the union has multiple overloads and a generic signature. The forEach method will now be callable, but there may be some issues under noImplicitAny. --build --watch use incremental file watching In TypeScript 3.3, --build mode’s --watch flag leverage incremental file watching. This results in significantly faster builds with a reduction of 50% to 75% in build times of the original --build --watch times. Sublime Text supports JavaScript editing The TypeScript plugin for Sublime Text now supports editing in JavaScript files. Users will now get more accurate completions, rename, go-to-definition, and more in JavaScript code that utilizes JSDoc and interoperates with TypeScript code. Typescript recently announced the ‘TypeScript Roadmap’ for January 2019- June 2019 which outlines the priorities that the team will be focussing on, over the next 6 months. Future of ESLint support in TypeScript PayPal replaces Flow with TypeScript as their type checker for every new web app npm JavaScript predictions for 2019: React, GraphQL, and TypeScript are three technologies to learn