Tech News - Languages

Yesterday, Bob Davis, Senior Product Manager at Red Hat announced that Clang/LLVM, Go, and Rust will now enter “Full Support Phase”. The support lifecycle is changed after the General Availability (GA) of Clang/LLVM 6.0, Go 1.10, and Rust 1.29. Previously, these languages and tools were in “Technology Preview” status. They were provided for users to test their functionality and provide feedback. This was during the development process and there was no full supported under the Red Hat Subscription Level Agreements. They were not guaranteed to be functionally complete and were not intended for live production use. GA means that these products have now officially entered a phase to receive full support. Their website states that: “During the Full Support Phase, qualified Critical and Important Security errata advisories (RHSAs) and Urgent and Selected High Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.” On availability, support for new hardware and some enhanced software functionality may also be provided at the sole discretion of Red Hat. These are generally in minor releases. The minor releases will focus only on resolving defects/bugs. New installation images of the minor releases will be provided during this full support phase. As these packages are evolving fast, the support lifecycle will also have short intervals. This means that there will be quarterly updates to Rust, and updates every 6 months to LLVM and Golang. The support for them will be different than the usual long-term support LTS approach. For LLVM, Rust, and Go only the most recent build will be maintained. If an older version has a bug, the most recent build will be updated to fix it. If a bug is present in the current build, it will be addressed in the next scheduled build. That will be the next schedules minor release. For more details, visit the Red Hat Blog. The LLVM project is ditching SVN for GitHub. The migration to Github has begun. Golang just celebrated its ninth anniversary Rust 1.30 releases with procedural macros and improvements to the module system

After the GitHub Octoverse report last month, GitHub released an analysis of the top programming languages of 2018 on its platforms. There are various ways to rank the popularity of a programming language. In the report published on the GitHub Blog, the number of unique contributors to both public and private repositories tagged with the primary language was used. In addition, the number of repositories tagged with the appropriate primary programming language was also used. JavaScript is the top programming language by repositories The most number of repositories are created in JavaScript. The number of repositories created has a steady rise from 2012. Around this time, GitHub was housing nearly 1 million repositories in total. New JavaScript frameworks like Node.js were launched in 2009. This made it possible for developers to create client and server sides with the same code. Source: GitHub Blog JavaScript also has the most number of contributors JavaScript tops the list for the language having the most number contributors in public and private repositories. This is the case for organizations of every size in all regions of the world. New languages have also been on the rise on GitHub. In 2017, TypeScript entered the top 10 programming languages for all kinds of repositories across all regions. Projects like DefinitelyTyped help in using common JavaScript libraries with TypeScript which encourages its adoption. Some languages have also seen a decline in popularity. Ruby has sunk in the charts over the last couple of years. Even though the number of contributors in Ruby is on the rise, other languages like JavaScript and Python have grown faster. Newer projects not likely to be written in Ruby. This is especially true for projects owned by individual users or small organizations. Such projects are likely written in popular languages like JavaScript, Java, or Python. Source: GitHub Blog Languages by contributors in different regions Across regions, there haven’t been many variations in languages used. Ruby is at the bottom for all regions. TypeScript ranks higher in South America and Africa compared to North America and Europe. The reason could be the developer communities being relatively new in Africa and South America. The repositories in Africa and South America were younger than the repositories in North America and Europe. Fastest growing language by contributors PowerShell is climbing the list. Go also continues to grow across repository type with rank 7. It’s rank is 9 for open source repositories. Statically-typed languages which focus on type safety and interoperability like Kotlin, TypeScript, and Rust are growing quickly. So what makes a programming language popular on GitHub? There are three factors for top programming languages to climb ranks—type safety, interoperability, and being open source. Type safety: There’s a rise in static typing except for Python. This is because of the security and efficiency static typing offers individual developers and teams. The optional static typing in TypeScript adds safety. Kotlin, offers greater interactivity while creating trustworthy, type-safe programs. Interoperability: One of the reasons TypeScript climbed the rankings was due to its ability to coexist and integrate with JavaScript. Rust and Kotlin which are also on the rise, find built-in audiences in C and Java, respectively. Python developers can directly call Python APIs from Swift which displays its versatility and interoperability. Open source: These languages are also open source projects with active commits and changes. Strong communities that contribute, evolve, and create resources for languages can positively impact its life. For more details and charts, visit the GitHub Blog. What we learnt from the GitHub Octoverse 2018 Report Why does the C programming language refuse to die? Julia for machine learning. Will the new language pick up pace?

Dart 2.1, an increment over Dart 2 is released with changes for performance and usability. New features in Dart 2.1 include smaller code size, faster type checks, better usability for type errors, and new language features to improve productivity. Support for int-to-double conversion in Dart 2.1 Developers new to Flutter often face obstacles in the form of analysis errors when specifying padding, setting font sizes, etc. These errors make sense from a system point of view. For example, the API expects a type say, a double, and the developer specifies the value in a different type say, an int. From a usability point of view, it seems foolish as there is a trivial conversion from int to double. So, Dart 2.1 now infers the line where applicable and silently evaluates an int as a double. Language support for mixins in Dart 2.1 Dart 2.1 comes with a new syntax for mixins. It features a new mixin keyword that can be used to define classes which can exclusively be used as mixins. Support is also added so that mixins can extend other classes and invoke methods in their superclass. Previously, mixins could only extend Object. An example of extending non-Object classes is from Flutter’s animation APIs. The SingleTickerProviderStateMixin which is a framework class that provides a ticker for advancing an animation by a single frame declares a mixin that implements the general TickerProvider interface. The animations are applicable only to stateful widgets since the position in the animation is considered state. The new mixin support in Dart 2.1 allows expressing this by declaring that only classes that extend the Flutter State class can use the mixin. Compile-time type checks The type system in Dart 2 protects users during development, indicating violations of the contract specified by the types. Such checks at edit time were added in Dart 2 powered by the Dart Analyzer. There is another place where developers might expect type checks. Like compile time, when performing a Flutter release build. Such checks were incomplete in Dart 2, which potentially leading to usability issues where bad source code could compile without errors. In Dart 2.1, these checks are complete. Now, the Analyzer and Dart compiler both contain the same checks. Performance improvements for Flutter developers In a few cases, though, the comprehensive checks in Dart 2 caused undesirable overheads of 20–40%. Dart 2.1 has greatly reduced cost of type checks. This is applicable to both, AOT-compiled code and code run in the VM with JIT compilation. The developer tools which run using the VM, benefit from this. Performing code analysis of one large benchmark app used to take about 41 seconds, it now takes only around 25 seconds. Performance improvements for web developers The code size and compile time is also improved for Dart code running on the web. The output size of dart2js were in focus. This yielded good results, such as a 17% reduction in minified output size and a 15% improvement in compilation time in one of the tested samples. Other changes There are also some changes made outside the core Dart SDK. One is protocol buffers (protobuf) which are a platform-neutral mechanism for serializing structured data. Dart is now an officially protobuf supported language. They have created a small sample for knative—a platform based on Kubernetes for building, deploying, and managing serverless workloads. For more details, visit the Dart Blog post. Google’s Dart hits version 2.0 with major changes for developers C# 8.0 to have async streams, recursive patterns and more Golang just celebrated its ninth anniversary

Soundation, online music production software, released their new music studio built on WebAssembly Threads, after working closely with Google. It is the first music production software to run on WebAssembly Threads, which contributes to considerably improved speed, performance, and stability when producing music in a browser. Its online music studio is used by over 80,000 creatives who produce music directly in their web browsers. For Soundation’s users, the WebAssembly technology provides an improved performance on multicore machines, between 100-300 percent*, according to measurements. Soundation has been collaborating with Google’s WASM and Chrome Audio teams for over a year, working to optimize the implementation of Soundation Studio based on WebAssembly, with support of multithreading and shared memory. Adam Hasslert, CEO, Soundation, said, “Implementing WebAssembly Threads is a key part of our mission to build the next-generation music production service online. This technology will have a significant impact on how web apps are made in the future, and it’s essential for us to lead this development and offer our users the most powerful alternative.” Thomas Nattestad at CDS, Product Manager, WebAssembly, said, “Soundation is one of the first adopters of WebAssembly Threads. They use these Threads to achieve fast, parallelized processing to seamlessly mix songs. Adding just a single Thread doubled their performance, and by the time they added five threads, they more than tripled their performance.” How did Soundation conduct the tests? Soundation made tests of complex Soundation Studio project (consisting of 10 audio tracks, 12 synthesizers, 270 audio regions with audio samples and notes with 84 filter effects applied) to generate the audio file. The test was later run on Ubuntu 16.04, Chrome 72.0.3584.0 (64-bit) on board they had Intel® Core™ i7-6700HQ. They then compared systems based on WebAssembly, PNaCL, native application using different processing buffer sizes in ring buffer. WebAssembly version has been tested using different number of threads. Here’s a video by Thomas Nattestad, the Product Manager for WebAsssembly, introducing Soundation. https://www.youtube.com/watch?v=zgOGZgAPUjQ&feature=youtu.be&t=474 Cloudflare’s Workers enable containerless cloud computing powered by V8 Isolates and WebAssembly Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications Mozilla shares plans to bring desktop applications, games to WebAssembly and make deeper inroads for the future web

C# 8.0 will introduce some new features and will likely ship out the same time as .NET Core 3.0. Developers will be able to use the new features with Visual Studio 2019. Nullable reference types in C# 8.0 This feature aims to help prevent the null reference exceptions that appear everywhere. They have riddled object-oriented programming for half a century now. The null reference exceptions stop developers from using null in ordinary reference types like string. They make these types non-nullable. They are warnings, however, not errors. On existing code, there will be new warnings. Developers will have to opt into using the new feature at the project, file, or source line level. C# 8.0 will let you express your “nullable intent”, and throws a warning when you don’t follow it. string s = null; // Warning: Assignment of null to non-nullable reference type string? s = null; // Ok Asynchronous streams with IAsyncEnumerable<T> The async feature that was from C# 5.0 lets developers consume and produce asynchronous results. This is in straightforward code, without callbacks. This isn’t helpful when developers want to consume or produce continuous streams of results. For example, data from an IoT device or a cloud service. Async streams are present for this use. C# 8.0 will come with IAsyncEnumerable<T>. It is an asynchronous version of the existing IEnumerable<T>. Now you can await foreach over functions to consume their elements, then yield return to them in order to produce elements. async IAsyncEnumerable<int> GetBigResultsAsync() {    await foreach (var result in GetResultsAsync())    {        if (result > 20) yield return result;    } } Ranges and indices A type Index is added which can be used for indexing. A type index can be created from an int that counts from the beginning. It can be alternatively created with a prefix ^ operator that counts from the end. Index i1 = 3;  // number 3 from beginning Index i2 = ^4; // number 4 from end int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; Console.WriteLine($"{a[i1]}, {a[i2]}"); // "3, 6" C# 8.0 will have an added Range type consisting of two Indexes. One will be for the start and one for the end. They can be written with an x..y range expression. Default implementations of interface members Currently, once an interface is published members can’t be added anymore without breaking all its existing implementers. With the new release, a body for an interface member can be provided. If somebody doesn’t implement that member, the default implementation will be available instead. Allowing recursive patterns C# 8.0 will allow patterns to contain other patterns. IEnumerable<string> GetEnrollees() {    foreach (var p in People)    {        if (p is Student { Graduated: false, Name: string name }) yield return name;    } } The pattern in the above code checks that the Person is a Student. It then applies the constant pattern false to their Graduated property to see if they’re still enrolled. Then checks if the pattern string name to their Name property to get their name. Hence, if p is a Student who has not graduated and has a non-null name, that name will yield return. Switch expressions Switch statements with patterns a powerful feature in C# 7.0. But since they can be cumbersome to write, the next C# version will have switch expressions. They are a lightweight version of switch statements, where all the cases are expressions. Target-typed new-expressions In many cases, on creating a new object, the type is already given from context. C# 8.0 will let you omit the type in those cases. For more details, visit the Microsoft Blog. ReSharper 18.2 brings performance improvements, C# 7.3, Blazor support and spellcheck Qml.Net: A new C# library for cross-platform .NET GUI development Microsoft announces .NET standard 2.1

Saturday was the ninth anniversary of the day when the Go team open-sourced the initial sketch of Golang. On each anniversary they list what has happened over the past year for Go. Golang adoption indicated in surveys In 2018 Go users expressed in multiple surveys about their happiness with using Go. Many developers who do not use Golang currently also indicated their intent to learn Go before any other language. In the Stack Overflow 2018 Developer Survey, Golang was in the top 5 most loved and top 3 most wanted languages. This indicated that developers using Go like it, and developers not using Go want to. ActiveState’s 2018 Developer Survey had Go topping the charts with 36% of users responding with “Extremely Satisfied” using Go and 61% of the users responded with “Very Satisfied” or better. While the JetBrains’s 2018 Developer Survey awarded Go the “Most promising language” with 12% of respondents using Go today and 16% with the intention to use Go in the future. Also in the HackerRank 2018 Developer Survey, 38% developer responses indicated that were intending to learn Go next. The evolution of the Golang community The first Go conferences and Go meetups were held five years ago. Since then, there has been major growth in community leadership. Now there are more than 20 Go conferences and over 300 Go-related meetups across the world. There have also been hundreds of great talks in 2018. The Go code of conduct has been revised to better support inclusivity in the Go community. Go 2 After five years since Go 1, the Go core team is looking into changes to support the language at scale. A draft design for Go modules was published in August, which included ideas to better support error values, error handling, and generic programming. And the most recent release, Golang 1.11, included preliminary support for modules. Golang contributors There has been an increasing number of contributors for Go through the years. In Q2 2018, a milestone was hit when for the first time, the contributions from the community were more than that of the Go team. For more details, visit the Go Blog. Go 2 design drafts include plans for better error handling and generics Why Golang is the fastest growing language on GitHub Golang 1.11 is here with modules and experimental WebAssembly port among other updates

Crystal is a general-purpose, object-oriented programming language with support from over 300 contributors. Last Friday, Crystal 0.27.0 was released. Language changes in Crystal 0.27.0 From Crystal 0.27.0, if the arguments of a method call need to be splitted across multiple lines, the comma must be put at the end of the line just before the line break. This is more in line with other conventional languages. Better handling of stack overflows A program entering an infinite recursion or running out of space in the stack memory is known as a stack overflow. Crystal 0.27.0 ships with a boundary check that allows a better error message on stack overflow. Concurrency and parallelism changes The next releases should start showing parallelism. There are some steps in preparation for that. The Boehm GC has API that enables support for multithreading environment in v7.6.x. From this version of Crystal, GC 7.6.8 or greater is used. As Crystal 0.26.1 was shipped with v7.4.10, the dependency needed to be updated first so that the CI can compile the compiler with the new GC API. Also, refactoring was done to separate the responsibilities of Fiber, Event, Scheduler, and EventLoop. Arithmetic symbols added In Crystal 0.27.0, arithmetic operators like &+, &-, &* were added. They are for additions, subtraction and multiplication with wrapping. In one of the next versions, the regular operators will raise on overflow. This will allow users to trust the result of the operations when reaching the limits of the representable range. Collection names changed In Indexable module and Hash, there are some breaking changes. The Indexable#at was replaced in favor of Indexable#fetch. The API between Indexable and Hash is now more aligned in the latest version. This includes ways to deal with default values in case of a missing key. If no default value is needed, the #[] method must be used. This is true even for Hash, since Hash#fetch(key) was dropped. Time changes There are breaking changes to support cleaner and more portable names. All references to “epoch” should now be replaced to “unix”. Also effectively, Time#epoch was renamed to Time#to_unix, #epoch_ms to #unix_ms, and #epoch_f to #to_unix_f. ISO calendar week numbers are now supported. Changing the time zone while maintaining the wall clock is also easy. File changes Working with temporal files and directories needed the Tempfile class. Now the creation of such files are handled by File.tempfile or File.tempname. This change also tidies up the usage of prefix, suffix and default temp path. Platform support There was an issue detected in Boehm GC regarding while running in Google Cloud because. The fix for this will be released in the next version of GC. Meanwhile, a patch is included in Crystal 0.27.0. There is some preparation for Windows support related to processes, forking, file handlers and arguments. Other fixes include fixing signals between forked processes, and dealing how IO on a TTY behaves in different environments. Networking changes HTTP::Server#bind_ssl was dropped since #bind_tls was introduced. It wasn’t removed to avoid a breaking change. The bindings for OpenSSL were updated to support v1.1.1. Compiler changes Support for annotations inside enums is added. Calling super will by default forward all the method arguments. Even if the call was expanded by macros in this version. When using splats argument the type of values can be restricted. This also goes for the whole Tuple or NamedTuple that is expected as splatted arguments. A bug was present when these restrictions were used, now fixed. For a complete list of changes, visit the Crystal changelog. WebAssembly – Trick or Treat? Mozilla shares plans to bring desktop applications, games to WebAssembly and make deeper inroads for the future web The D language front-end support finally merged into GCC 9

The D Language front-end got finally merged into GNU Compiler Collection (GCC) 9, yesterday, as reported by Phoronix. The D language front-end is written in C++ and it supports the D 2.0 run-time and shared libraries. Iain Buclaw in his e-mail thread titled ‘Submission of D Front End’ says,  "The front-end is split into two parts. First being a standalone D language implementation that does the source file lexing, parsing and semantic analysis. Second being the binding layer that sits between GCC and the DMD front-end, doing the actual code generation.” Approval on the plan for merging D language front-end into GCC 9 According to a report by Phoronix, last year in June, the GCC Steering Committee had approved the plan of adding the D front-end. However, it took the project more than a year as a set of 13 patches of code, which is nearly 800k lines of code was worked upon and which had undergone revisions for getting the code in adequate shape for merging. Iain Buclaw from the GDC project took the initiative of posting these patches after carefully cleaning them up and also addressing the feedback he had received before. The patch series is available on GCC-patches. Updates on the future plan As per a report by Phoronix, Richard Biener of SUSE announced on 17th October that GCC's "stage 1" development will shift to "stage 3" on 11 November. It’s clear that the open feature development is over and the focus is now on bug-fixing. 6 January 2019 is the tentative date, to begin with the fixes. GCC 9.1, the initial GCC9 stable compiler release with GDC support is expected to be out around the end of the first quarter of 2019. Read more about this news on the official site of Phoronix. GCC 8.1 Standards released! What is a micro frontend? Frontend development with Bootstrap 4

Yesterday, the rust team released a new version of the Rust systems programming language known for its safety, speed, and concurrency. Rust 1.30 comes with procedural macros, module system improvements, and more. It has been an incredibly successful year for the Rust programming language in terms of its popularity. It jumped from being the 46th most popular language on GitHub last year to the 18th position this year. The 2018 survey of the RedMonk Programming Language Rankings marked the entry of Rust in their Top 25 list. It topped the list of the most loved programming language among the developers who took the Stack overflow survey of 2018 survey for a straight third year in the row. Still not satisfied? Here are 9 reasons why Rust programmers love Rust. Key improvements in Rust 1.30 Procedural macros are now available Procedural macros allow for more powerful code generation. Rust 1.30 introduces two different kinds of advanced macros, “attribute-like procedural macros” and “function-like procedural macros.” Attribute-like macros are similar to custom derive macros, but instead of generating code for only the #[derive] attribute, they allow you to create new, custom attributes of your own. They’re also more flexible: derive only works for structs and enums, but attributes can go on other places, like functions. Function-like macros define macros that look like function calls. Developers can now also bring macros into scope with the use keyword. Updates to the Module system The module system has received significant improvements to make it more straightforward and easy to use. In addition to bringing macros into scope, the use keyword has two other changes. First, external crates are now in the prelude. Previously, on moving a function to a submodule, developers would have some of their code break. Now, on moving a function, it will check the first part of the path and see if it’s an extern crate, and if it is, it will use it regardless of where developers are in the module hierarchy. Second, use supports bringing items into scope with paths starting with crate. Previously, paths specified after use would always start at the crate root, but paths referring to items directly would start at the local path, meaning the behavior of paths was inconsistent. Now, the crate keyword at the start of the path will indicate if developers would like the path to start at their crate root. These changes combined will lead to a more straightforward understanding of how paths resolve. Other changes Developers can now use keywords as identifiers using the raw identifiers syntax (r#), e.g. let r#for = true; Using anonymous parameters in traits is now deprecated with a warning and will be a hard error in the 2018 edition. Developers can now catch visibility keywords (e.g. pub, pub(crate)) in macros using the vis specifier. Non-macro attributes now allow all forms of literals, not just strings. Previously, you would write #[attr("true")], now you can write #[attr(true)]. Developers can now specify a function to handle a panic in the Rust runtime with the #[panic_handler] attribute. These are just a select few updates. For more information, and code examples, go through the Rust Blog. 3 ways to break your Rust code into modules Rust as a Game Programming Language: Is it any good? Rust 2018 RC1 now released with Raw identifiers, better path clarity, and other changes

Mio, a cross-platform header-only C++11 memory mapping library with an MIT license, got released yesterday. Mio has been created with an objective of getting easily integrated into any C++ project. It uses a memory-mapped file IO without the need to pull in Boost libraries. The users faced issues with the Boost.Iostreams library as it didn’t work efficiently with respect to memory mapping. However, Mio has a lot of advantages over Boost.Iostreams. Advantages of Mio over Boost.Iostreams With Mio, the support for establishing a memory mapping with an already open file handle/descriptor became possible, which otherwise didn’t work with the Boost.Iostreams. Mio makes the memory mapping process easier by accepting any offset and finding the nearest page boundary. Whereas, Boost.Iostreams requires the user to pick offsets exactly at page boundaries, which may lead to errors. Boost.Iostreams implements a memory mapped file IO with a std::shared_ptr to provide shared semantics, even when it is not needed. This may lead to an overhead of the heap allocation, which may not be required. On the other hand, Mio solves this problem with its two use-cases, one that is move-only, which is a zero-cost abstraction over the system specific mapping functions and the other one which is similar to its Boost.Iostreams counterpart, with shared semantics. How does the memory mapping in Mio work? The three ways to map a file into memory are: Use the constructor, which throws on failure: mio::mmap_source mmap(path, offset, size_to_map Use the factory function: std::error_code error; mio::mmap_source mmap = mio::make_mmap_source(path, offset, size_to_map, error); Use the map member function: std::error_code error; mio::mmap_source mmap; mmap.map(path, offset, size_to_map, error); In each of the cases, you can either provide some string type for the file's path or you can simply use an existing, valid file handle. Mio does not check if the provided file descriptor has the same access permissions as the desired mapping, so the mapping process might fail. Such errors are reported via the std::error_code out parameter which is passed to the mapping function. CMake: A build system to help Mio As Mio is a header-only library, it has no compiled components. CMake build system assists Mio, by providing easy testing, installation, and subproject composition on many platforms and operating systems. In Testing When Mio is configured as the highest level CMake project, the suite of executables is built by default. Mio's test executables are integrated with the CMake test driver program, CTest. In Installation The CMake's find package intrinsic function helps Mio's build system to provide an installation target and support for downstream consumption to an arbitrary location. This can be specified by defining CMAKE_INSTALL_PREFIX at the time of configuration.  CMake will install Mio to conventional location based on the platform operating system in the absence of a user specification. Read more about Mio, in detail on the official GitHub page. Google releases Oboe, a C++ library to build high-performance Android audio apps Graph Nets – DeepMind’s library for graph networks in Tensorflow and Sonnet Ebiten 1.8, a 2D game library in Go, is here with experimental WebAssembly support and newly added APIs

Python 3.7.1 and 3.6.7 are maintenance releases for Python 3.7 and Python 3.6 respectively. They contain a variety of fixes. New features in Python 3.7 Python 3.7 was released in June and is the next branch after Python 3.6. Some of the new features in Python 3.7 are: Postponed evaluation of annotations By postponing the evaluation of annotations in Python, two bugs were fixed: Annotations were restricted to using names which were already available in the current scope. That is, they did not support forward references. Annotating source code had negative effects on starting a Python program. Legacy C locale coercion Determining a sensible default strategy for handling the 7-bit ASCII text encoding is a problem in Python 3. It is implied by the use of the default C or POSIX locale on non-Windows platforms. With PEP 538, the default interpreter command line interface is updated to automatically coerce that locale to an available UTF-8 based locale. Automatically setting LC_CTYPE using this method means that both the core interpreter and locale-aware C extensions will assume the use of UTF-8 as the default text encoding. Forced UTF-8 runtime mode The new -X utf8 command line option and PYTHONUTF8 environment variable can now be used to enable the CPython UTF-8 mode. While in UTF-8 mode, CPython ignores the locale settings to use the UTF-8 encoding by default. Built-in breakpoint() The new built-in breakpoint() function is included as an easy and consistent way to enter the Python debugger. The built-in breakpoint() function calls sys.breakpointhook(). A new C API for thread-local storage Anew Thread Specific Storage (TSS) API is added to CPython which annuls use of the existing TLS API within the CPython interpreter. It deprecates the existing API. Customization of access to module attributes Python 3.7 allows defining __getattr__() on modules. It will be called whenever a module attribute is not found otherwise. Also, defining __dir__() on modules is now allowed. New time functions with nanosecond resolution The range of clocks in modern systems can exceed the precision of a floating point number returned by the time.time() function. For having greater precision, six new nanosecond variants are added. Show DeprecationWarning in __main__ The default handling of DeprecationWarning has been changed in Python 3.7. These warnings are again shown by default. It happens only when the code triggering them is running directly in the __main__ module. Core support for typing module and generic types Earlier, any changes to the core CPython interpreter were not made by PEP 484. Since type hints and the typing module are extensively used by developers, this restriction is now removed. Hash-based .pyc Files The pyc format is extended to allow the hash of the source file to be used for invalidation instead. This was previously used for the source timestamp. Such .pyc files are considered “hash-based”. Hash-based .pyc files come can be of the types checked and unchecked. New documentation translations Three new translations namely Japanese, French and Korean are added. Some fixes in Python 3.7.1 Fix for a possible null pointer dereference in bytesobject.c. Fix a bug where iteration order of OrderedDict was not copied. A Fix for async generators not being finalized. This used to happen even when the event loop was in debug mode and garbage collector runs in another thread. Fix self-cancellation in a C implementation of asyncio.Task. Fix for a reference issue inside multiprocessing.Pool that caused the pool to remain alive on being deleted without being closed or terminated explicitly. Ensure that PyObject_Print() returns -1 on error every time. Also, Python 3.6.7 is released as the seventh maintenance release for Python 3.6. Visit the Python documentation for a complete list of bug fixes in Python 3.7.1 visit the Python documentation and know more about features in Python 3.7 in the documentation. Meet Pypeline, a simple python library for building concurrent data pipelines Python comes third in TIOBE popularity index for the first time Home Assistant: an open source Python home automation hub to rule all things smart

OpenSSH 7.9 has been released with some new features and bug fixes. There are new features like support for signalling sessions and client and server configs. In bug fixes, invalid format errors and bugs in closing connections are solved. New features in OpenSSH 7.9 Most port numbers are now allowed to be specified using service names from getservbyname(3). This is typically /etc/services. The IdentityAgent configuration directive is allowed to accept environment variable names. This adds the support to use multiple agent sockets without having to use fixed paths. Support is added for signalling sessions via the SSH protocol. However, only a limited subset of signals is supported. The support is only for login or command sessions and not subsystems that were exempt from a forced command via authorized_keys or sshd_config. Support for "ssh -Q sig" to list supported signature options is added. There is also "ssh -Q help" that will show the full set of supported queries. A CASignatureAlgorithms option is added for the client and server configs. It allows control over which signature formats are allowed for CAs to sign certificates. As an example, this allows to ban CAs that sign certificates using the RSA-SHA1 signature algorithm. Key revocation lists (KRLs) are allowed to revoke keys specified by SHA256 hash. Allowing creation of key revocation lists straight from base64-encoded SHA256 fingerprints. This supports removing keys using only the information contained in sshd(8) authentication log messages. Bug fixes in OpenSSH 7.9 ssh(1), ssh-keygen(1): Avoiding Spurious "invalid format" errors while attempting to load PEM private keys when using an incorrect passphrase. sshd(8): On receiving a channel closed message from a client, the stderr file descriptor and stdout are closed at the same time. Processes don’t stop anymore if they were waiting for stderr to close and were indifferent to the closing of stdin/out. ssh(1): You can now set ForwardX11Timeout=0 to disable the untrusted X11 forwarding timeout and support X11 forwarding endlessly. In previous versions, ForwardX11Timeout=0 was undefined. sshd(8): On compiling with GSSAPI support, cache supported method OIDs regardless of whether GSSAPI authentication is enabled in the main section of sshd_config. This behaviour avoids sandbox violations when GSSAPI authentication was enabled later in a Match block. sshd(8): Closing a connection does not failed when configuration is done with a text key revocation list that contains a very short key. ssh(1): Connections with specified ProxyJump are treated the same as ones with a ProxyCommand set with regards to hostname canonicalisation. This means that unless CanonicalizeHostname is set to 'always' the hostname should not be canonicalised. ssh(1): Fixed a regression in OpenSSH 7.8 that could prevent public- key authentication using certificates hosted in an ssh-agent(1) or against sshd(8) from OpenSSH 7.8 or newer. For more details, visit the OpenSSH website. How the Titan M chip will improve Android security IBM launches Industry’s first ‘Cybersecurity Operations Center on Wheels’ for on-demand cybersecurity support low.js, a Node.js port for embedded systems

Yesterday, Google Cloud announced a new Go 1.11 runtime for the App Engine standard environment. This provides all the benefits of App Engine such as paying only for what you use, automatic scaling and managed infrastructure. Starting with Go 1.11, which was launched in August this year, Go on App Engine has no limits on application structure, supported packages, context.Context values, or HTTP clients. What are the changes in the Go 1.11 runtime as compared to Go 1.9? 1. Now, you can specify the Go 1.11 runtime in your app.yaml file by adding the following line: runtime: go111 2. Each of your services must include a package main statement in at least one source file. 3. The appengine build tag is now deprecated and will no longer be used when building an app for deployment. 4. The way you import dependencies has changed. You can specify the dependencies in this runtime by the following two ways: Putting your application and related code in your GOPATH. Or else, by creating a go.mod file to define your module. 5. Google App Engine now does not modify the Go toolchain to include the appengine package. Using Google Cloud client library or third party libraries instead of the App Engine-specific APIs is recommended. 6. You can deploy services that use the Go 1.11 runtime using the gcloud app deploy command. You can still use the appcfg.py commands the Go 1.9 runtime, but the gcloud command-line tool is preferred. This release of the Go 1.11 runtime in the App Engine uses the latest stable release of Go 1.11 and will automatically update to new minor versions upon deployment but will not for any major versions. Also, it is currently in beta and might be changed in backward-incompatible ways in future. You can read more about Go 1.11 runtime on The Go Blog and also the documentation published by Google. Golang plans to add a core implementation of an internal language server protocol Why Golang is the fastest growing language on GitHub Golang 1.11 is here with modules and experimental WebAssembly port among other updates

Three MIT students and an associate professor published a paper in July. They introduce a concept called Instruction and Memory Level Parallelism (IMLP) task programming model for computing. They achieve this via a domain specific language (DSL) called Cimple (Coroutines for Instruction and Memory Parallel Language Extensions). Why Cimple? Before looking at what it is, let’s understand the motivation behind this work. As cited in the paper, currently there is a critical gap between millisecond and nanosecond latencies for process loading and execution. The existing software and hardware techniques hide the low latencies and are inadequate to fully utilize all of the memory from CPU caches to RAM. The work is based on a belief that an efficient, flexible, and expressive programming model can scale all of the memory hierarchy from tens to hundreds of nanoseconds. Modern processors with dynamic execution are more capable of exploiting instruction level parallelism (ILP) and memory level parallelism (MLP). They do this by using wide superscalar pipelines and vector execution units, and deep buffers for inflight memory requests. However, these resources “often exhibit poor utilization rates on workloads with large working sets”. With IMLP, the tasks execute as coroutines. These coroutines yield execution at annotated long-latency operations; for example, memory accesses, divisions, or unpredictable branches. The IMLP tasks are interleaved on a single process thread. They also integrate well with thread parallelism and vectorization. This led to a DSL embedded in C++ called Cimple. What is Cimple? It is a DSL embedded in C++, that allows exploring task scheduling and transformations which include buffering, vectorization, pipelining, and prefetching. A simple IMLP programming model is introduced. It is based on concurrent tasks being executed as coroutines. Cimple separates the program logic from programmer hints and scheduling optimizations. It allows exploring task scheduling and techniques like buffering, vectorization, pipelining, and prefetching. A compiler for CIMPLE automatically generates coroutines for the code. The CIMPLE compiler and runtime library are used via an embedded DSL. It separates the basic logic from scheduling hints and then into guide transformations. They also build an Abstract Syntax Tree (AST) directly from succinct C++ code. The DSL treats expressions as opaque AST blocks. It exposes conventional control flow primitives in order to enable the transformations. The results after using Cimple Cimple is used as a template library generator and then the performance gains are reported. The peak system throughput increased from 1.3× on HashTable to 2.5× on SkipList iteration. It speedups of the time to complete a batch of queries on one thread range from 1.2× on HashTable to 6.4× on BinaryTree. Source: Cimple: Instruction and Memory Level Parallelism Where the abbreviations are Binary Search (BS), Binary Tree (BT), Skip List (SL), Skip List iterator (SLi), and Hash Table (HT). Cimple reaches 2.5× throughput gains over hardware multithreading on a multi-core processor and 6.4× single thread. This is the resulting graph. Source: Cimple: Instruction and Memory Level Parallelism The final conclusions from the work is that Cimple is fast, maintainable, and portable. The paper will appear in PACT’18 to be held 1st to 4th November 2018. You can read it on the arXiv website. KotlinConf 2018: Kotlin 1.3 RC out and Kotlin/Native hits beta Facebook releases Skiplang, a general purpose programming language low.js, a Node.js port for embedded systems

Last week, the Fedora team announced that Swift will be available in Fedora 28.  Swift, Apple’s programming language, is built with a modern approach to safety and its addition to Fedora will facilitate Linux’s focus on the security aspect of its kernel. Why did the team opt for Swift? Swift’s applications are endless- right from systems programming to desktop applications leading right upto cloud services. This language was always focussed on being fast and safe. There is automatic memory management where arrays and integers are checked for overflow. Swift also supports a built-in mechanism for error handling. It is an efficient server-side programming language which performs fast iterations over collections of code. Additional features include: Closures with function pointers Tuples and multiple return values Generics Structs supporting methods, extensions, and protocols Functional programming patterns, like map and filter do, guard, defer, and repeat keywords provide an advanced control flow Swift is available in Fedora under the package name swift-lang. The flexible capabilities of Fedora coupled with the advantages offered by Swift make it an excellent choice for developers to work on. To know more about this news, head over to Fedora’s magazine. ABI stability may finally come in Swift 5.0 Swift 4.2 releases with language, library and package manager updates! Fedora 29 beta brings Modularity, GNOME 3.30 support and other changes