Tech News - Languages

Yesterday, the PHP development team announced the availability of PHP version 7.4. This marks the fourth feature update to the PHP 7 series. PHP 7.4 comes with numerous improvements and new features. Key features in PHP 7.4 Class properties support type declarations. Starting from PHP 7.4, arrow functions will provide a shorthand syntax for defining functions with implicit by-value scope binding The full variance support is only available if autoloading is used by the user. Also, a single file will now only support non-cyclic type references. Numeric literals can contain underscores between digits. Weak references in PHP 7.4 will allow the programmers to retain a reference to an object that does not prevent the object from being destroyed. Users can now throw exceptions from __toString(). This was previously not permitted in PHP as it used to result in a fatal error. The CURLFile now supports stream wrappers in addition to plain file names. The FILTER_VALIDATE_FLOAT filter will support the min_range and max_range options, with the same semantics as FILTER_VALIDATE_INT. A new FFI extension is introduced. It will provide a simple way to call native functions, access native variables, and create/access data structures defined in C libraries. A new IMG_FILTER_SCATTER image filter is added to introduce a scatter filter to images. Read More: The Union Types 2.0 proposal gets a go-ahead for PHP 8.0 Users are happy with the new features in PHP 7.4 release. https://twitter.com/heiglandreas/status/1199989039249678337 To know the full list of changes, head over to the PHP archive page. Users can also check out the PHP manual to learn how to migrate from PHP 7.3.x to PHP 7.4.x. PEAR’s (PHP Extension and Application Repository) web server disabled due to a security breach Symfony leaves PHP-FIG, the framework interoperability group Google App Engine standard environment (beta) now includes PHP 7.2 Redox OS will soon permanently run rustc, the compiler for the Rust programming language, says Redox creator Jeremy Soller Homebrew 2.2 releases with support for macOS Catalina

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

The Julia team yesterday announced a new version of the language, Julia v1.3. A few highlights of this release include new language features such as support for Unicode 12.1.0, support for Unicode bold digits and double-struck digits 0 through 9 as valid identifiers, and many more. What’s new in Julia v1.3? In this latest Julia v1.3, methods can now be added to an abstract type. Also, the syntax var"#str#" for printing and parsing non-standard variable names have been added. Multi-threading changes New experimental Threads.@spawn macro runs a task on any available thread. All system-level I/O operations (e.g. files and sockets) are now thread-safe. This does not include subtypes of IO that are entirely in-memory, such as IOBuffer, although it specifically does include BufferStream. The global random number generator (GLOBAL_RNG) is now thread-safe (and thread-local). New Channel(f::Function, spawn=true) keyword argument to schedule the created Task on any available thread, matching the behavior of Threads.@spawn. Simplified the Channel constructor, which is now easier to read and more idiomatic julia. Use of the keyword arguments csize and ctype is now discouraged. New library functions findfirst, findlast, findnext and findprev now accept a character as first argument to search for that character in a string passed as the second argument. Added new findall(pattern, string) method where pattern is a string or regex. Added sincosd(x) to simultaneously compute the sine and cosine of x, where x is in degrees (#30134). The function nonmissingtype, which removes Missing from type unions, has been exported. Standard library changes Regex can now be multiplied (*) and exponentiated (^), like strings. Cmd interpolation (`$(x::Cmd) a b c` where) now propagates x's process flags (environment, flags, working directory, etc) if x is the first interpolant and errors otherwise. Zero-dimensional arrays are now consistently preserved in the return values of mathematical functions that operate on the array(s) as a whole (and are not explicitly broadcasted across their elements). Previously, the functions +, -, *, /, conj, real and imag returned the unwrapped element when operating over zero-dimensional arrays. mod now accepts a unit range as the second argument to easily perform offset modular arithmetic to ensure the result is inside the range. Julia v1.3 also includes changes in other libraries including Libdl, LinearAlgebra, SparseArrays, Dates, Statistics, Sockets, and a few more. According to the team, @spawn expr from the Distributed standard library should be replaced with @spawnat :any expr. Also, Threads.Mutex and Threads.RecursiveSpinLock have been removed; developers suggest using ReentrantLock (preferred) or Threads.SpinLock instead. Another tooling improvement includes the ClangSA.jl static analysis package has been imported, which makes use of the clang static analyzer to validate GC invariants in Julia's C code. The analysis may be run using make -C src analyzegc. Users are excited to try out Julia v1.3. A user on Hacker News commented, “By far the most interesting part of this release is the new multi-threading features.” To know more about this news in detail, head over to Julia v1.3 release notes. The Julia team shares its finalized release process with the community Julia v1.2 releases with support for argument splatting, Unicode 12, new star unary operator, and more. Julia co-creator, Jeff Bezanson, on what’s wrong with Julialang and how to tackle issues like modularity and extension

Three days ago, the team behind Python announced the release of Python 3.9.0a1, which is the first out of the six planned alpha releases of Python 3.9. The final stable version of Python 3.9 is slated to release in May 2020. An alpha release indicates that developers can start testing the new features and check for bug fixes but are not recommended to use it in production. Last month, the previous stable version, Python 3.8 was released with features like walrus operator, positional-only parameters support for Vectorcall. Read More: Core Python team confirms sunsetting Python 2 on January 1, 2020 Let’s look at some of the raw features that you can be expected in the upcoming Python 3.9 version. Some improvements introduced in Python 3.9.0a1 Language Changes The __import__() function which is invoked by the import statement will now raise ImportError instead of ValueError. In the previous versions, the latter used to occur when a relative import went past its top-level package. Starting from Python 3.9.0a1, the absolute path of the script filename will be specified on the command line: the __file__ attribute of the __main__ module. The sys.argv[0] and sys.path[0] will become an absolute path rather than a relative path. Also, the traceback will now display the absolute path for __main__ module frames in this case. The encoding and errors arguments in the debug build and development mode will now be checked in the string encoding and decoding operations. Improved Modules ast: It is added in the indent option to dump() and produces a multi-line indented output. asyncio: It can now use coroutine which is a generalized form of subroutines. Subroutines enter and exit at only two different points, while coroutines can be entered, exited, and resumed at many points. Moreover, asyncio.run() is updated to use the new coroutine. New functions like curses.get_escdelay(), curses.set_escdelay(), curses.get_tabsize(), and curses.set_tabsize() and constants F_OFD_GETLK, F_OFD_SETLK and F_OFD_SETLKW is included in Python 3.9.0a1. Few Python users have already started testing the Python 3.9.0a1 release. https://twitter.com/codewithanthony/status/1197559895744110592 The next alpha release for Python 3.9 is scheduled for 16th December 2019. To know more about Python 3.9.0a1, check out the official documentation. Introducing Spleeter, a Tensorflow based python library that extracts voice and sound from any music track Severity issues raised for Python 2 Debian packages for not supporting Python 3 Introducing OpenDrop, an open-source implementation of Apple AirDrop written in Python Poetry, a Python dependency management and packaging tool, releases v1 beta 1 with URL dependency PyPy will continue to support Python 2.7, even as major Python projects migrate to Python 3

On Tuesday, Racket, a general-purpose programming language announced Racket 7.5. Racket is based on the Scheme dialect of Lisp programming language and is designed to be a platform for programming language design and implementation. Racket is also used to refer to the family of Racket programming languages and the set of tools supporting development on and with Racket. Key features in Racket 7.5 This new release will be distributed under a new and less-restrictive license, either the Apache 2.0 or the MIT license Racket CS will remain in beta for the v7.5, but the compatibility and performance continue to improve. It is expected to be ready for production use by the next release In this release of Racket 7.5 the Web Server provides a standard JSON MIME type, including a response/jsexpr form for HTTP responses bearing JSON In this release GNU MPFR operations run about 3x faster Typed Racket supports definitions of new struct type properties and type checks uses existing struct type properties in struct definitions. Previously, these were ignored by the type checker, so type errors may have been hidden The performance bug in v7.4’s big bang has been repaired DrRacket supports Dark Mode for interface elements. With this release plot can display parametric 3d surfaces and redex supports modeless judgment forms Additionally with the above changes, in the Racket 7.5 MacOS Catalina 10.15 includes a new requirement that executables be “notarized”, to give Apple the ability to prevent certain kinds of malware. In this release, all of the disk images (.dmg’s) are notarized, along with the applications that they contain (.app’s). Many users may not notice any difference, but two groups of Catalina users will be affected; First those who use the “racket” binary directly, and second, those that download the .tgz bundles. In both cases, the operating system is likely to inform that the given executable is not trusted, or that the developer can’t be verified. Fortunately, both groups of users are probably also running commands in a shell, hence the solution for both groups will be the same that is to disable the quarantine flag using the xattr command, for example, xattr -d com.apple.quarantine /path/to/racket. To know more about this news, check out the official announcement on the Racket page. Matthew Flatt’s proposal to change Racket’s s-expressions based syntax to infix representation creates a stir in the community Racket 7.3 releases with improved Racket-on-Chez, refactored IO system, and more Racket 7.2, a descendent of Scheme and Lisp, is now out! Racket v7.0 is out with overhauled internals, updates to DrRacket, TypedRacket among others  

On Tuesday, Facebook mandates Visual Studio Code, the source code editor developed by Microsoft, as their default development environment. Additionally, they also stated that the company will work with Microsoft to expand the remote development extension for Visual Studio Code so that engineers can do large-scale remote development. As per the official announcement page, Facebook engineers have written millions of lines of codes and there is no mandated development environment. Till now Facebook developers used Vim or Emacs  and the development environment was disjointed. And certain developers also used Nuclide, an integrated development environment developed by Facebook. But in late 2018, they announced to their internal engineers that they would move Nuclide to Visual Studio Code. They have also done plenty of development work to migrate the current Nuclide functionality, along with new features to Visual Studio Code and currently it is used extensively across the company in beta. Why Visual Studio Code? The Visual Studio Code is a very popular development tool, with great support from Microsoft and the open source community. It runs on macOS, Windows, and Linux, and has a robust and well-defined extension API that enables to continue building the important capabilities required for the large-scale development done at Facebook. The company believes that it is a platform on which they can safely bet their development platform future. They have also partnered with Microsoft for remote development. At present, Facebook engineers install Visual Studio Code on a local PC, but the actual development is done directly on the development server in the data center. Therefore, it aims to improve efficiency and productivity by making the code on the server accessible in a seamless and high-performance manner. The company believes that using remote extensions will provide many benefits like: Work with larger, faster, or more specialized hardware than what’s available on local machine Create tailored, dedicated environments for each project’s specific dependencies, without worrying about errors due to mixed or conflicting configurations Support the flexibility of being able to quickly switch between multiple running development environments without impacting local resources or tool performance Facebook mandates Visual Studio Code as an integrated development environment which can be used internally, specifically, because Facebook uses various programming languages. It also uses Mercurial as the source control infrastructure, it will work on the development of extensions to allow direct source control operations within Visual Studio Code. Facebook states, “VS Code is now an established part of Facebook’s development future. In teaming with Microsoft, we’re looking forward to being part of the community that helps Visual Studio Code continue to be a world class development tool.” On Hacker News, developers are discussing various issues related to remote development extensions in VS Code, one of them is it is not open-source and Facebook should take efforts to make it an open project. One comment reads, “Just an FYI for people - The Remote Development extensions are not open source. I'd hope if Facebook were joining efforts, they'd do so on a more open project. 1: https://code.visualstudio.com/docs/remote/faq#_why-arent-the... 2: https://github.com/microsoft/vscode/wiki/Differences-between... 3: https://github.com/VSCodium/vscodium/issues/240 (aka, on-the-wire DRM to make sure the remote components only talk to a licensed VS Code build from Microsoft) MS edited the licensing terms many moons ago, to prepare for VS Code in browser using these remote extensions/apis that no one else can use)- https://github.com/microsoft/vscode/issues/48279 Finally, this is the thread where you will see regular users being negatively impacted by the DRM (a closed source, non-statically linked proprietary binary downloaded at runtime) that implements this proprietary-ness: https://github.com/microsoft/vscode-remote-release/issues/10... (of course, also with enough details to potentially patch around this issue if you were so inclined). Further, MS acknowledged that statically linking would help in May, and yet it appears to still be an issue. I just hope they don't come after Eclipse Theia…” Microsoft releases Cascadia Code version 1909.16, the latest monospaced font for Windows Terminal and Visual Studio Code 12 Visual Studio Code extensions that Node.js developers will love [Sponsored by Microsoft] 5 developers explain why they use Visual Studio Code [Sponsored by Microsoft] 5 useful Visual Studio Code extensions for Angular developers Facebook releases PyTorch 1.3 with named tensors, PyTorch Mobile, 8-bit model quantization, and more

Kotlin 1.3.60 was released yesterday with new features, as well as quality and tooling improvements. This release adds support for more Kotlin/Native platforms and targets. It also improves the Kotlin/MPP IDE experience. For Kotlin/JS, Kotlin 1.3.60 adds support for source maps and improves the platform test runner integration. The team has also significantly enhanced some “create expect” quick-fixes to the multiplatform side of Kotlin. IntelliJ IDEA and Kotlin Eclipse IDE plugin updates Scratch files are now redesigned and improved to let you see the results, which are shown in a different window. The Kotlin team is working on enhancing the user experience with Kotlin Gradle build scripts. Developers can set function breakpoints in the Kotlin code. The debugger will then stop execution on entering or exiting the corresponding function. Multiple improvements to Java-to-Kotlin converter. The kotlin-eclipse plugin now supports experimentally incremental compilation for single modules. Improvements to Kotlin/Native compiler in Kotlin 1.3.60 The Kotlin/Native compiler has compatibility with the latest tooling bits: XCode 11 and LLVM 8.0. It also adds new platforms/targets such as watchOS, tvOS, and Android (native). Kotlin 1.3.60 adds experimental symbolication of iOS crash reports for release binaries (including LLVM-inlined code, which is one step further than what XCode is able to decode). Thread-safe tracking of Objective-C weak/shared references to Kotlin objects. Support for suspend callable references. The ability to associate a work queue with any context/thread, not just the ones created ad⁠-⁠hoc through Worker.start. The kotlinx.cli project has been (mostly) rewritten and is included in this release of the Kotlin/Native compiler. The runtime performance of Kotlin/Native compiler has also been improved: interface calls are now up to 5x faster, and type checks up to 50x faster in Kotlin 1.3.60. The team has also shared upcoming changes planned for Kotlin 1.4 which is to be released in 2020. Currently, Kotlin 1.4 is available in the experimental state. You can find the complete list of Kotlin 1.3.60 changes in the changelog. Kotlin 1.3.50 released with ‘duration and time Measurement’ API preview, Dukat for npm dependencies, and more. Introducing Coil, an open-source Android image loading library backed by Kotlin Coroutines Microsoft announces .NET Jupyter Notebooks

At Microsoft Ignite 2019, Microsoft announced that Jupyter Notebooks will now allow users to run .NET code with the new .NET Jupyter Notebooks. Try .NET has grown to support more interactive experiences across the web with runnable code snippets, interactive documentation generator for .NET Core with dotnet try global tool. The same codebase is taken to the next level by announcing C# and F# in Jupyter notebooks. What’s new in .NET Jupyter Notebook By default, the .NET notebook experience enables users to display useful information about an object in table format. .NET notebooks also by default, ship with several helper methods for writing HTML; from basic helpers that enable users to write out a string as HTML or output Javascript to more complex HTML with PocketView. .NET Notebooks are a perfect match for ML .NET .NET notebooks bring interesting options for ML.NET, like exploring and documenting model training experiments, data distribution exploration, data cleaning, plotting data charts, and learning. To leverage ML.NET in Jupyter notebooks, users can check out the blog post Using ML.NET in Jupyter notebooks with several online samples. Create charts using Xplot Charts are rendered using Xplot.Plotly. As soon as users import XPlot.Plotly namespace into their notebooks(using Xplot.Ploty;), they can begin creating rich data visualizations in .NET. Source: Microsoft.com .NET for Apache Spark With .NET for Apache Spark, .NET developers have two options for running .NET for Apache Spark queries in notebooks: Azure Synapse Analytics Notebooks and Azure HDInsight Spark + Jupyter Notebooks. Both the experiences allow developers to write and run quick ad-hoc queries in addition to developing complete, end-to-end big data scenarios, such as reading in data, transforming it, and visualizing it. To learn how to get started with .NET for Apache Spark, visit the GitHub repo. Many users are excited to try out the new .NET Jupyter Notebooks. A user on Hacker News commented, “This is great news. Jupyter has become my default tool for prototyping code. I keep trying other platforms that should theoretically have the same features, but I just find Jupyter much more pleasant to use.” Another user commented, “I love .NET and I love Jupyter. I don't know how well they will combine though. I feel like the lack of Pandas and flexible typing of Python will make it a lot less useful.” To know more about this announcement in detail, Scott Hanselman’s post on his website. Introducing Voila that turns your Jupyter notebooks to standalone web applications JupyterHub 1.0 releases with named servers, support for TLS encryption and more .NET Framework API Porting Project concludes with .NET Core 3.0

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

Yesterday, Steve Canon, a member of Apple’s Swift Standard Library team announced a new open-source project called Swift Numerics. The goal behind this project is to enable the use of Swift language in new domains of programming. What is Swift Numerics Swift Numerics is a Swift package containing a set of fine-grained modules. These modules fall broadly under two categories. One, modules that are too specialized to be included into the standard library, but are general enough to be in a single common package. The second category includes those modules that are “under active development toward possible future inclusion in the standard library.” Currently, Swift Numerics has two most-requested modules: Real and Complex. The Real module provides basic math functions proposed in SE-0246. This proposal was accepted but due to some limitations in the compiler, it is not yet possible to add the new functions directly to the standard library. Real provides the basic math functionalities in a separate module so that developers can start using them right away in their projects. The Complex module introduces a Complex number type over an underlying Real type. It includes usual arithmetic operators for complex numbers. It is conformant to usual protocols such as Equatable, Hashable, Codable, and Numeric. The support for complex numbers can be especially useful when working with Fourier transforms and signal processing algorithms. The modules included in Swift Numerics have minimal dependencies. For instance, the current modules only require the availability of the Swift and C standard libraries and the runtime support provided by compiler-rt. Also, the Swift Numerics package is open-sourced under the same license and contribution guidelines as the Swift project (Apache License 2.0). In a discussion on Hacker News, many developers shared their views on Swift Numerics. A user commented,  “Really looking forward to ShapedArray. Eventually, a lot of what one might do with Python may be available in Swift.” Read the official announcement by Apple to know more about Swift Numerics. Also, check out its GitHub repository. Swift shares diagnostic architecture improvements that will be part of the Swift 5.2 release Developers from the Swift for TensorFlow project propose adding first-class differentiable programming to Swift Declarative UI programming faceoff: Apple’s SwiftUI vs Google’s Flutter Introducing SwiftWasm, a tool for compiling Swift to WebAssembly Swift is improving the UI of its generics model with the “reverse generics” system

Yesterday Elm 0.19.1 was released with a new improvements to the compiler that now display syntactical errors in a new fashion that pointing users to their mistakes as well as suggesting them additional resources.  The goal of 0.19.1 is to clean up the rough edges such that we have a really solid foundation for newcomers, professionals, scientists. Evan Czaplicki, the creator of these improved error messages explains in a blog post, “the new error messages points to the spot where it got stuck, but more importantly, it tries to help by (1) giving examples and (2) linking to a page that explains how imports work. It tries to help you learn!” For example, if you miss out on including a curly braces in your JavaScript code, the error message shows up at the very end of the file. Now with the improved Elm compiler, the error message will point out the error where it occurred while also suggesting a viable fix. Source: Elm’s blog Czaplicki hopes that this project can eliminate the survivorship bias present in the programming ecosystem, which he believes is also one of the reasons why it took so long for Elm to prioritize this project. “I hope this work on syntax error messages will help make Elm more friendly and accessible, and I hope it will help make space for other language designers to prioritize this kind of project!”, he adds. Other improvements in Elm 0.19.1 Faster compilation, especially for incremental compiles Uses filelocks so that cached files are not corrupted when plugins run elm make multiple times on the same project at the same time. More intuitive multiline declarations in REPL Various bug fixes (e.g. --debug, x /= 0, type Height = Height Float in --optimize) Developers on Twitter appreciated Elm’s focus on errors. https://twitter.com/vronnie911/status/1186377031015157762 https://twitter.com/domenkozar/status/1163795173022806016 Read more about improved error messages in Elm 0.19.1 on this blog post. What to expect from D programming language in the near future OpenBSD 6.6 comes with GCC disabled in base for ARMv7 and i386, SMP improvements and more. Swift shares diagnostic architecture improvements that will be part of the Swift 5.2 release.

The team behind Swift shared a new blog post yesterday detailing their new diagnostic architecture which is being implemented as a part of the upcoming Swift 5.2 release (expected early November). This new architecture aims to improve the diagnostics from the compiler. It will make it easier to improve/port existing diagnostics to be used by new feature implementors. The Swift compiler uses type checker to ensure the correctness of a program. Type checker enforces rules about how types are used in source code and show when those rules are violated. However, it guesses the exact location of an error which is not helpful in certain scenarios because it is not specific or actionable. With the new diagnostic infrastructure, the team is trying to implement a new type checker that attempts to “fix” problems right at the point where they occur while remembering the fixes it has applied. This way, type checker can pinpoint errors in more kinds of programs. New constraint fix resolves inconsistent situations The type checker converts the source code into a constraint system, which represents relationships among the types in the code. The Constraint System first generates the constraint and then solves them. The process of constraint generation produces a constraint system that relates the types of various subexpressions within an expression. The constraint solver takes a given set of constraints and determines the most specific type binding for each of the type variables in the constraint system. To improve the constraint solving mechanism, the new diagnostic infrastructure employs a constraint fix that tries to resolve inconsistent situations where the solver gets stuck with no other types to attempt. This fix captures all useful information about the error location from the solver and uses that later for diagnostics. While the former approach guesses where the error is located, the new approach has a symbiotic relationship with the solver which provides all of the error locations to it. How constraint fix works A constraint fix is created whenever a constraint failure is detected. The constraint fix captures three crucial pieces of information about a failure: kind of failure that occurred, location in the source code where the failure came from, and types and declarations involved in the failure. The constraint solver then accumulates these fixes. Once it arrives at a solution, it looks at the fixes that were part of a solution and produces actionable errors or warnings. The Swift team has shared examples of improved diagnostics and SwiftUI examples to better demonstrate the workings of this new diagnostic infrastructure. People are quite excited about these error improvements in Swift and shared their views on the associated thread in Swift Forums. “Omg better error messages! That's so awesome! Right now error messages are the worst part of swift, I'm excited. I hope it will be the end of types called _ in error messages” “Awesome work @xedin! The blog post is highly informative and I thoroughly enjoyed reading it. I very much look forward to seeing the new diagnostic architecture in action.” Developers from the Swift for TensorFlow project propose adding first-class differentiable programming to Swift Apple releases the native SwiftUI framework with declarative syntax, live editing, and support of Xcode and more. Swift is improving the UI of its generics model with the “reverse generics” system

On Tuesday, Atila Neves the Deputy leader for D programming language posted about his vision for D and what he would like to do with D lang in the near future. Make D programming language default for web dev and mobile applications D’s static reflection and code generation capabilities make it an ideal candidate to implement a codebase that needs to be called from several different languages and environments (e.g. Python, Java, R). Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it. With D, none of that is necessary. One can write the production code in D and have libraries automatically making the code callable from other languages. Hence it will be easy to write D code that runs as fast or faster than the alternatives, and it will be a win on all fronts. Memory Safety for D lang Atila believes that D is a systems programming language with value types and pointers, it isn’t memory safe. He says that DIP1000 is in the right direction, but it still needs to be memory safe unless programmers opt-out via @trusted block or function. The DIP1000 proposal includes a scope mechanism that will know when the lifetime of a reference is over by providing a mechanism to guarantee that a reference cannot escape lexical scope. Thus it can safely implement memory management schemes rather than tracing the garbage collection. Safe and easy concurrency in D programming language As per Atila safe and easy concurrency in D is mostly achieved through actor models, but they still need to finalize shards and make everything @safe as well. Centralizing all reflection needs with an API Atila says instead of disparate ways of getting things done with fragmented APIs like (__traits, std.traits, custom code), he would like there to be a library that centralizes all reflection needs with a great API. Easy interoperability for C++ developers C++ has been successful so far in making the transition from C virtually seamless. Atila wants current C++ programmers with legacy codebases to just as easily be able to start writing D code. Faster development times D needs a fast interpreter so that developers can skip machine code generation and linking. This should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. String interpolation in D programming language Code generation is one of D’s greatest strengths, and token strings enable visually pleasing blocks of code that are actually “just strings”. Hence, String interpolation would make it vastly easier to use. To know more about D programming language, check out the official post by Atila Neves. “Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett The V programming language is now open source – is it too good to be true? Rust’s original creator, Graydon Hoare on the current state of system programming and safety

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

On Friday, Libc++ version 9 was released; libc++ is an implementation of the C++ standard library, targeting C++11, C++14 and above. Libc++ 9 is a part of the LLVM Compiler Infrastructure, release 9.0.0 which was made available in September. Libc++ 9 adds explicit support for WebAssembly System Interface (WASI) along with major improvements from the previous release and new feature work. Libc++ has also dropped support for GCC 4.9; they now support GCC 5.1 and above. WASI is a system interface for the WebAssembly platform. Currently, it supports sandboxed access to the filesystem via a POSIX-like API, as well as other basic interfaces like argv, environment variables, random numbers, and timers. There are three popular implementations of WASI: wasmtime, Mozilla’s WebAssembly runtime, Lucet, Fastly’s WebAssembly runtime, and a browser polyfill. Improvements in Libc ++ 9 Minor fixes to std::chrono operators. libc++ now correctly handles Objective-C++ ARC qualifiers in std::is_pointer. Front and back methods are added to std::span std::to_chars now adds leading zeros. Ensure std::tuple is trivially constructible. std::aligned_union now works in C++03. Output of nullptr to std::basic_ostream is formatted properly. P0608 is now implemented as a sane variant converting constructor. std::is_unbounded_array and std::is_bounded_array added to type traits. std::atomic now includes many new features and specialization Added std::midpoint and std::lerp math functions and std::is_constant_evaluated function Erase-like algorithms now return size type. Added contains method to container types. std::swap is now a constant expression. std::move and std::forward now both work in C++03 mode. People on Twitter were quite happy with WASI support in libc ++ https://twitter.com/Stephen_d2005/status/1178489876070535168 https://twitter.com/iwillrunoutofsp/status/1182702301062008832 You can also see the release notes for additional information. Introducing Weld, a runtime written in Rust and LLVM for cross-library optimizations LLVM 9 releases with official RISC-V target support, asm goto, Clang 9, and more LLVM’s Clang 9.0 to ship with experimental support for OpenCL C++17, asm goto initial support and more. LLVMs Arm stack protection feature turns ineffective when the stack is re-allocated