Tech News - Languages

Last week, Stjepan Glavina, a Rust programmer at Ferrous Systems, announced that the ‘async-std’ library has now reached its beta phase. This library has the “looks and feels” of Rust’s standard library but replaces its components with their async counterparts. The current state of asynchronous programming in Rust Asynchronous code facilitates the execution of multiple tasks concurrently on the same OS thread. It can potentially make your application much faster while using fewer resources as compared to a corresponding threaded implementation. Speaking of Rust’s asynchronous ecosystem, we can say that it is still early days. The standard library’s Future trait was recently stabilized and the async/await feature will soon be landing in a future version. Why async-std is introduced Rust’s Future trait is often considered to be difficult to understand, not because it is complex but because it is something that people are not used to. Stating what makes Futures confusing, the book accompanying the ‘async-std’ library states, “Futures have three concepts at their base that seem to be a constant source of confusion: deferred computation, asynchronicity and independence of execution strategy.” The ‘async-std’ library, together with its supporting libraries, aims to make asynchronous programming easier in Rust. It is based on Future and supports a set of traits from the futures library. It is also designed to support the new async programming model that is slated to be stabilized in Rust 1.39. The async-std library serves as an interface to all important primitives including filesystem operations, network operations and concurrency basics like timers. In addition to the async variations of I/O primitives found in std, it comes with async versions of concurrency primitives like Mutex and RwLock. It also ships with a ‘tasks’ module that performs a single allocation per spawned task and awaits the result of the task without the need of an extra channel. Speaking about the learning curve of async-std, Glavina said, “By mimicking standard library's well-understood APIs as closely as possible, we hope users will have an easy time learning how to use async-std and switching from thread-based blocking APIs to asynchronous ones. If you're familiar with Rust's standard library, very little should come as a surprise.” The library received a mixed reaction from the community. A user said, “In fact, Rust does have a great solution for non-blocking code: just use threads! Threads work great, they are very fast on Linux, and solutions such as goroutines are just implementations of threads in userland anyway...People tell me that Rust services scale up to thousands of requests per second on Linux by just using 1:1 threads.” A Rust developer on Reddit commented, “Looks good. I'm hoping we can soon see this project, the futures crate, async WGs crates and Tokio converge to build unified async foundations, reduce duplicated efforts (and avoid seeing dependencies explode when using several crates using async together). It's unclear to me why apparently similar crates are popping up, but I hope this is just temporary explorations of async that will merge together.” Check out the official announcement to know more about the async-std library. Also, check out its book: Async programming in Rust with async-std. Rust 1.37.0 releases with support for profile-guided optimization, built-in cargo vendor, and more Introducing Abscissa, a security-oriented Rust application framework by iqlusion Introducing Ballista, a distributed compute platform based on Kubernetes and Rust  

Earlier this week, the team behind Racket announced the release of Racket 7.3. This release comes with improved Racket-on-Chez, refactored IO system, a new shear function in the Pict library, and more. The Racket programming language is general-purpose, multi-paradigm, and is a dialect of Lisp and Scheme. Updates in Racket 7.3 Snapshot builds of Racket-on-Chez are now available Racket’s core was largely implemented in C, which affects its portability to different systems, maintenance, and performance. Hence, back in 2017, the team decided to make the Racket distribution run on Chez Scheme. With the last release (Racket 7.2), the team shared that the implementation of Racket on Chez Scheme (Racket CS) has reached almost complete status with all functionalities in place. With this release, the team has added more improvements to Racket-on-Chez and has made its snapshot builds available on Racket Snapshots. The team further shared that by next release we can expect Racket-on-Chez to be included as a download option. Other updates In addition to the improvements in Racket-on-Chez, the following updates are introduced: Racket’s IO system is refactored to provide better performance and a simplified internal design. The JSON reader is now dramatically faster. The Racket web library now comes with improved support for 307 redirects. The Plot library comes with color map support for renderers. The Plot library allows you to produce any kind of plot including scatter plots, line plots, contour plots, histograms, and 3D surfaces and isosurfaces. A ‘shear’ function is added to the Pict library, Racket’s one of the standard functional picture libraries. Read the full announcement on Racket’s official website. Racket 7.2, a descendant of Scheme and Lisp, is now out! Racket v7.0 is out with overhauled internals, updates to DrRacket, TypedRacket among others Swift is improving the UI of its generics model with the “reverse generics” system

Yesterday, the team at Nim announced Nim version 1.0, a general-purpose, compiled programming language that focuses on efficiency, readability and flexibility. Major changes in Nim 1.0 Backwards compatibility The switch -d:nimBinaryStdFiles has been removed in this release and stdin/stdout/stderr are now the binary files again.  In this release, the language definition and compiler are now stricter about gensym'ed symbols in hygienic templates.  Changes made to library The team has removed unicode.Rune16 in this release as the name ‘Rune16 ’ was wrong. In Nim 1.0, encodings.getCurrentEncoding distinguishes between the OS's encoding and console's encoding.  In this release, json.parseJsonFragments iterator can speedup JSON processing. Oid usage has been enabled in hashtables. std/monotimes module has been added that implements monotonic timestamps. Compiler In Nim 1.0, the Nim compiler warns about unused module imports. Users can use a top-level {.used.} pragma in the module that can be importable without giving a warning. In this version, the Nim compiler nomore recompiles the Nim project via nim c -r if case no dependent Nim file is changed. Users seem to be excited about this news and are appreciating the efforts taken by the team. A user commented on HackerNews, “Great! I love this language, so simple and powerful, so fast executables!”  Another user commented, “I would have never thought to live long enough to see this happening! I started using Nim in 2014, but abandoned it after a few years, frustrated by the instability of the language and what I perceived as a lack of vision. (In 2014, release 1.0 was said to be "behind the corner".) This release makes me eager to try it again. I remember that the language impressed me a lot: easy to learn, well-thought, and very fast to compile. Congratulations to the team!” Other interesting news in programming How Quarkus brings Java into the modern world of enterprise tech LLVM 9 releases with official RISC-V target support, asm goto, Clang 9, and more Twitter announces to test ‘Hide Replies’ feature in the US and Japan, after testing it in Canada

With JDK 11 reaching general availability next week, there is also a proposed schedule released for JDK 12. The proposed schedule indicates a final release in March 2019 along with two JDK Enhancement Proposals (JEPs) proposed for JDK 12. Mark Reinhold, Chief Architect of the Java Platform Group at Oracle, made an announcement in a mail posted to the OpenJDK mailing list. Per the mail, JDK 12 should be out to the public on March 19, 2019. The proposed schedule for JDK 12 will be as follows: 13th December 2018 Rampdown Phase One 17th January 2019 Rampdown Phase Two 31st January 2019 Release-Candidate Phase 19th March 2019 General Availability JDK 11 had a total of 17 JEPs contributed out of which three were from the community, the highest number in any JDK release. The other 14 were from Oracle according to a tweet by @bellsoftware. For JDK 12, there are two JEPs integrated which will be available as a preview language feature and four candidate JEPs. JDK 12 preview features JEP 325: Switch Expressions (Preview) This JEP is going to allow the switch statement to be used as both statements and as an expression. Both forms can use either a “traditional” or “simplified” scoping and control flow behavior. The changes to the switch statement will simplify everyday coding. It will also pave the way for the use of pattern matching in switch. JEP 326: Raw String Literals (Preview) This JEP adds raw string literals to Java. A raw string literal can span many source code lines. It does not interpret escape sequences, such as \n, or Unicode escapes, of the form \uXXXX. This does not introduce any new String operators. There will be no change in the interpretation of traditional string literals. JDK 12 JEP candidates JEP 343: Packaging Tool To create a new tool based on the JavaFX javapackager tool for packaging self-contained Java applications. JEP 342: Limit Speculative Execution To help both developers and deployers to defend against speculative-execution vulnerabilities. This is to be done by providing a means to limit speculative execution and not a complete defense against all forms of speculative execution. JEP 340: One AArch64 Port, Not Two Remove all arm64 port related sources while retaining the 32-bit ARM port and the 64-bit AArch64 port. This will help focus on a single 64-bit ARM implementation and eliminate duplicate work to maintain two ports. JEP 341: Default CDS Archives Enhance the JDK build process to generate a class data-sharing (CDS) archive by using the default class list, on 64-bit platforms. The goal is to improve out-of-the-box startup time and eliminating the need for users to run -Xshare:dump to benefit from CDS. To know more details on the proposed schedule for JDK 12, visit the OpenJDK website. JEP 325: Revamped switch statements that can also be expressions proposed for Java 12 Mark Reinhold on the evolution of Java platform and OpenJDK No more free Java SE 8 updates for commercial use after January 2019

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

On August 22, the JetBrains team announced the release of Kotlin 1.3.50. Some of the major improvements in this Kotlin version include a preview of the new Duration and Time Measurement API in the standard library, using Dukat for the experimental generation of external declarations for npm dependencies in Gradle Kotlin/JS projects, a separate plugin for debugging Kotlin/Native code in IntelliJ IDEA Ultimate, and much more. The team has also worked on improving Java-to-Kotlin converter and on Java compilation support in multi-platform projects. Let us have a look at these improvements in brief. Major improvements in Kotlin 1.3.50 Changes in the standard library Experimental preview of duration and time measurement API A new duration and time measurement API is available for preview. The researchers say that if the API expects the duration stored as primitive value like Long, one can erroneously pass the value in the wrong unit, and unfortunately, the type system doesn’t help prevent that. Hence, the team created a regular class to store duration solves this problem. However, this brings another problem, i.e., additional allocations. Now the API can use the Duration type, and all the clients will need to specify the time in the desired units explicitly. This release brings support for MonoClock which represents the monotonic clock, which doesn’t depend on the system time. The monotonic clock can only measure the time difference between given time points, but doesn’t know the “current time.” The Clock interface provides a general API for measuring time intervals. MonoClock is an object implementing Clock; it provides the default source of monotonic time on different platforms. When using the Clock interface, the user explicitly marks the time of action start, and later the time elapsed from the start point. It is especially convenient if one wants to start and finish measuring time from different functions. To know more about this feature in detail, read Kotlin/KEEP on GitHub. Experimental API for bit manipulation The standard library now contains an experimental API for bit manipulation. Similar extension functions for Int, Long, Short, Byte, and their unsigned counterparts have also been added. IntelliJ IDEA support in Kotlin 1.3.50 Improvements in Java to Kotlin converter This release includes a preview of Java to Kotlin converter to minimize the amount of “red code” one has to fix manually after the conversion. This improved version of the converter tries to infer nullability more correctly based on the Java type usages in the code. The goal is to decrease the number of compilation errors and to make the produced Kotlin code more convenient to use. The new converter fixes many other known bugs, too; for instance, it now correctly handles implicit Java type casts. This new converter may become the default one in the future. To turn it on, specify the Use New J2K (experimental) flag in settings. Debugging improvements In Kotlin 1.3.50, the team has improved how the Kotlin “Variables” view chooses variables to display. As there’s a lot of additional technical information in the bytecode, the Kotlin “Variables” view highlights only the relevant variables. Local variables inside the lambda, as well as captured variables from the outer context and parameters of the outer function, are correctly displayed: Source: jetbrains.com Kotlin 1.3.50 also adds improved support for the “Evaluate expression” functionality in the debugger for many non-trivial language features, such as local extension functions or accessors of member extension properties. Users can now modify variables via “Evaluate expression”: Source: jetbrains.com Added new intentions and inspections This release includes the addition of new intentions and inspections. One of the goals of intentions is to help users learn how to write idiomatic Kotlin code. The following intention, for instance, suggests using the indices property rather than building a range of indices manually: Source: jetbrains.com Updates to Kotlin/JS Kotlin 1.3.50 adds support for building and running Kotlin/JS Gradle projects using the org.jetbrains.kotlin.js plugin on Windows. Users can now build and run projects using Gradle tasks, dependencies from NPM required in the Gradle configuration are resolved and included. Users can also try out their applications using webpack-dev-server and much more. The team has also added performance improvements for Kotlin/JS by improving the incremental compilation time for projects. With this users expect speedups of up to 30% when compared to 1.3.41. This version also shows an improved integration with NPM, which means that projects are now resolved lazily and in parallel, and support for projects with transitive dependencies between compilations in the same project has been added. Kotlin 1.3.50 also brings changes in the structure and naming of generated artifacts. Generated artifacts are now bundled in the distributions folder, and they include the version number of the project and archiveBaseName (which defaults to the project name), e.g. projectName-1.0-SNAPSHOT.js. Using Dukat for automatic conversion of TypeScript declaration files Dukat allows the automatic conversion of TypeScript declaration files (.d.ts) into Kotlin external declarations. This makes it more comfortable to use libraries from the JavaScript ecosystem in a type-safe manner in Kotlin, thus, reducing the need for manually writing wrappers for JS libraries. Kotlin/JS now ships with experimental support for Dukat integration for Gradle projects. With this integration, by running the build task in Gradle, typesafe wrappers are automatically generated for npm dependencies and can be used from Kotlin. As Dukat is still in a very early stage, its integration is disabled by default. The team has prepared an example project, which demonstrates the use of dukat in Kotlin/JS projects. Updates to Kotlin/ Native Previously, the version of Kotlin/Native differed from the version of Kotlin. However, in this version, schemes for Kotlin and Kotlin/Native are now aligned. This release uses version 1.3.50 for both Kotlin and Kotlin/Native binaries, reducing the complexity. This release brings more pre-imported Apple frameworks for all platforms, including macOS and iOS. The Kotlin/Native compiler now includes actual bitcode in produced frameworks. Several performance improvements have also made in the interop tool. The team has also announced that Null-check optimizations have been planned for Kotlin 1.4. Starting from Kotlin 1.4, "all runtime null checks will throw a java.lang.NullPointerException instead of a KotlinNullPointerException, IllegalStateException, IllegalArgumentException, and TypeCastException. This applies to: the !! operator, parameter null checks in the method preamble, platform-typed expression null checks, and the as operator with a non-null type. This doesn’t apply to lateinit null checks and explicit library function calls like checkNotNull or requireNotNull." Apart from the changes mentioned, Java compilation can now be included in Kotlin/JVM targets of a multiplatform project by calling the newly added withJava() function of the DSL. This release also adds multiple features and improvements in scripting and REPL support. To know more about these changes and other changes in detail, read Kotlin 1.3.50 official blog post. Introducing Coil, an open-source Android image loading library backed by Kotlin Coroutines Introducing Kweb: A Kotlin library for building rich web applications How to avoid NullPointerExceptions in Kotlin [Video]

After the release of Java Development Kit 10 in March this year, Oracle is all set to release JDK 11. Expected in September 2018 as part of Oracle’s new six-month release cadence for the standard edition of Java, Version 11 has just a handful of features announced so far. JDK 11 is set to be a long-term support unlike JDK 10, hence it will be a reference implementation of Java Platform, Standard Edition (Java SE) 11. JDK 11 is set to receive premier-level support from Oracle until September 2023 and extended support, featuring patches and security alerts, until 2026. Java 11 is also set to lose some capabilities as the support for CORBA, Java EE, and JavaFX will be removed. For now, JDK 11 is set to have four new features, although more are expected later. This post summarizes some details about each of the four JEPs (JDK Enhancement Proposal) currently targeted for JDK 11. Epsilon: An Arbitrarily Low-Overhead Garbage Collector The Epsilon garbage collector, billed as a “no-op” collector, will handle memory allocation without implementing any actual memory reclamation mechanisms. Epsilon’s use cases include testing for performance, memory pressure, and the virtual machine interface. It also could be used for short-lived jobs. Local-Variable Syntax for Lambda Parameters A local-variable syntax for lambda parameters aims to achieve one goal which is to allow var reserved word to be used to declare the formal parameters of an implicitly typed lambda expression. Dynamic Class-File Constants The Java class-file format will be extended to support a new constant pool form, CONSTANT_Dynamic. The goal is to reduce the cost and disruption of developing new forms of materializable class-file constraints. Remove the Java EE and CORBA Modules The Java EE and CORBA modules were deprecated in Java SE 9, with the intent to remove them in a later release—that is now set to be JDK 11. Changes under consideration for Java JDK 11 The builders of Java 11 are also looking at several proposed changes or additions to JDK 11: Adding raw string literals to Java This would make it easier to express character sequences in a readable form, with no Java indicators. It also would make it simpler to supply strings targeted for grammar syntaxes other than Java, as well as supply strings spanning several lines of source code without supplying special indicators. Extending the switch statement This functionality can be used as either a statement or an expression. This also would improve how switch handles nulls. These changes would simplify coding and prepare for pattern matching in switch. Nest-based access control This is a context that aligns with the current notion of nested types in Java. Nests allow classes that are logically part of the same code entity but compiled to distinct class files to access each other’s private members without needing compilers to insert accessibility-broadening bridge methods. To know more about Java 11 JDK read Oracle’s official blog. Read Next 26 new Java 9 enhancements you will love How to recognize Patterns with Neural Networks in Java How to create a standard Java HTTP Client in ElasticSearch

Adding to the list of Python-like programming languages is Coconut that allows developers write simple and elegant functional code, while using the familiar Python environment and libraries. It is basically a superset of Python that adds on top of Python syntax and is inspired by programming languages like Haskell, CoffeeScript, F#, and patterns.py. The language is written by Evan Hubinger, an undergraduate student studying mathematics and computer science at Harvey Mudd College. Why Coconut was developed? Writing functional programs in Python can be challenging at times. While Python does allow developers to write high-order functions, it lacks concise syntax for lambdas, boilerplate-less pattern matching, etc. One Hacker News user mentioned, “It's capable of functional programming in the sense that functions are first class values that you can pass around, but it is infamously hostile to functional programming. For example, Python still doesn't have multiline lambdas, and the justifications for why always boil down to it being "unpythonic".” This is what Coconut tries to solve by bringing tools of modern functional programming. It provides a clean -> operator replacing Python’s lambda statements. It supports pipeline-style programming, partial application, pattern-matching, destructuring assignment, parallel programming, and more. To provide optional static type-checking you can integrate Coconut with MyPy, which is an optional static type checker for Python. But, it is not purely functional that allows programmers to choose whatever programming style they are comfortable with. As it is a variant of Python, developers who have experience in working on Python will not have much difficulty in learning it. Coconut code are compiled to Python code. Developers can access the Coconut compiler through its command-line utility, which also comes with an interpreter to enable real-time compilation. Additionally, it also supports the use of IPython/Jupyter notebooks. What are the Python version it supports? It supports these Python versions: >= 2.6 on the 2.x branch or >= 3.2 on the 3.x branch. To make Coconut built-ins universal across Python versions, it automatically overwrites Python 2 built-ins with their Python 3 counterparts. It also overwrites some Python 3 built-ins for optimization and enhancement purposes. If developers want to access the original Python versions of any overwritten built-ins, they can retrieve the old built-in by prefixing them with py_. pandas will drop support for Python 2 this month with pandas 0.24 Qt for Python 5.12 released with PySide2, Qt GUI and more Google researchers introduce JAX: A TensorFlow-like framework for generating high-performance code from Python and NumPy machine learning programs

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

Michael Thomsen, the Project Manager for Dart announced the stable release of the general purpose programming language, Dart 2.2. This version, which is an incremental update to v2, offers improved performance of ahead-of-time (AOT) compiled native code and a new set literal language feature. Improvements in Dart 2.2 Improved AOT performance Developers have worked on improving the AOT performance by 11–16% on microbenchmarks (at the cost of a ~1% increase in code size). Prior to this optimization, developers had to make several lookups to an object pool to determine the destination address. However, the optimized AOT code is now able to call the destination directly using a PC-relative call. Extended Literals to support sets Dart supported the literal syntax only for Lists and Maps, which caused difficulties in initializing Sets as it had to be initialized via a list as follows: Set<String> currencies = Set.of(['EUR', 'USD', 'JPY']); This code proved to be inefficient due to the lack of literal support and also made currencies a compile-time constant. With Dart 2.2’s extension of literals to support sets, users can initialize a set and make it const using a convenient new syntax: const Set<String> currencies = {'EUR', 'USD', 'JPY'}; Updated Dart language Specification Dart 2.2 includes the up-to-date ‘Dart language specification’ with the spec source moved to a new language repository. Developers have also added continuous integration to ensure a rolling draft specification is generated in PDF format as and when the specification for future versions of the Dart language evolves. Both the 2.2 version and rolling Dart 2.x specifications are available on the Dart specification page. To know more about this announcement in detail, visit Michael Thomsen’s blog on Medium. Google Dart 2.1 released with improved performance and usability Google’s Dart hits version 2.0 with major changes for developers Is Dart programming dead already?  

Yesterday, the team behind Rust announced the release of Rust 1.36.0. This release brings a stabilized 'Future' trait, NLL for Rust 2015, stabilized Alloc crate as the core allocation and collections library, a new --offline flag for Cargo, and more. Following are some of the updates in Rust 1.36.0: The stabilized 'Future' trait A ‘Future’ in Rust represents an asynchronous value that allows a thread to continue doing useful work while it waits for the value to become available. This trait has been long-awaited by Rust developers and with this release, it has been finally stabilized. “With this stabilization, we hope to give important crates, libraries, and the ecosystem time to prepare for async / .await, which we'll tell you more about in the future,” the Rust release team added. The alloc crate is stable The ‘std’ crate of the standard library provides types like Box<T> and OS functionality. But, the problem is it requires a global allocator and other OS capabilities. Beginning with Rust 1.36.0, the parts of std that are dependent on a global allocator will now be available in the ‘alloc’ crate and std will re-export these parts later. Use MaybeUninit<T> instead of mem::uninitialized Previously, the ‘mem::uninitialized’ function allowed you to bypass Rust’s memory-initialization checks by pretending to generate a value of type T without doing anything. Though the function has proven handy while lazily allocating arrays, it can be dangerous in many other scenarios as the Rust compiler just assumes that values are properly initialized. In Rust 1.36.0, the MaybeUninit<T> type has been stabilized to solve this problem. Now, the Rust compiler will understand that it should not assume that a MaybeUninit<T> is a properly initialized T. This will enable you to do gradual initialization more safely and eventually use ‘.assume_init()’. Non-lexical lifetimes (NLL) for Rust 2015 The Rust team introduced NLL in December last year when announcing Rust 1.31.0. It is an improvement to Rust’s static model of lifetimes to make the borrow checker smarter and more user-friendly. When it was first announced, it was only stabilized for Rust 2018. Now the team has backported it to Rust 2015 as well. In the future, we can expect all Rust editions to use NLL. --offline support in Cargo Previously, the Rust package manager, Cargo used to exit with an error if it needed to access the network and the network was not available. Rust 1.36.0 comes with a new flag called ‘--offline’ that makes the dependency resolution algorithm to only use locally cached dependencies, even if there might be a newer version. These were some of the updates in Rust 1.36.0. Read the official announcement to know more in detail. Introducing Vector, a high-performance data router, written in Rust Brave ad-blocker gives 69x better performance with its new engine written in Rust Introducing PyOxidizer, an open source utility for producing standalone Python applications, written in Rust

Last week, Michael Thomsen, the Project Manager for Dart announced the stable release of Dart 2.5 SDK (Software Development Kit). This release includes two technical previews of ML Complete and the dart:ffi foreign function interface to be used for calling C code directly from Dart. Dart 2.5 also brings improved support for constant expressions. Preview of ML Complete In his blog, Thomsen has regarded ML Complete as a “powerful addition” to their existing suite of productivity tools like hot reload, customizable static analysis, and Dart DevTools. It works by training a model of possible member occurrences in a given context. The possible occurrences can be analyzed from the available open-source Dart code on Github. The training model uses TensorFlow Lite tools to predict the next probable symbol, while the developer is editing. As ML Complete is built directly into the Dart analyzer, it is available on all Dart-enabled editors including Android Studio, IntelliJ, and VS Code. Since it is still in preview, developers are advised to use the Flutter dev channel or the Dart dev channel for previewing this feature. Preview of the dart:ffi foreign function interface The dart:ffi feature enables users to take advantage of the existing native APIs, where Dart code is already running. Users can also utilize the existing cross-platform native libraries written in C. Currently, the support for calling C directly from Dart is limited to the Dart VM deep integration which uses native extensions. The new dart:ffi foreign function interface will function on a new mechanism, offering great performance, easy approach, and will work across many Dart supported platforms and compilers. Dart-C interop works on two main scenarios: Calling a C-based system API on the host operating system (OS) For calling a C-based system API, the Linux command system is used. The system command allows the execution of any system command. It also allows the argument to be essentially passed to the shell/terminal and also run there. For implementing the dart:ffi, the Dart code needs to represent the C function and the types of its arguments and return type. It also needs to represent the corresponding Dart function, and its types. Both the representations are done by defining two typedefs in the C header for the command. Calling a C-based library for a single OS or cross-platform The dart:ffi feature is also used to implore C-based frameworks and components. It will allow the user to run TensorFlow across all the operating systems where code completion is needed. It also offers high performance of the native TensorFlow implementation. Thomsen adds, “We also expect that the ability to call C-based libraries will be of great use to Flutter apps. You can imagine calling native libraries such as Realm or SQLite, and we think dart:ffi will be valuable for enabling plugins for Flutter desktop.” Developers are advised to use the Flutter master channel or a Dart dev channel to quickly learn about the changes and improvements in the dart:ffi feature. Read Also: Dart 2.2 is out with support for set literals and more! Improvements in constant expressions In the earlier versions, the abilities of constant expressions were limited, however, Dart 2.5 includes many new changes. In Dart 2.5, constant expressions can be defined using many ways, which includes the ability to use casts and the new control flow and collection spread features. Image Source: Medium Users love Dart 2.5 features. https://twitter.com/geek_timofey/status/1171507571372380167 https://twitter.com/Fredrikkerlund2/status/1171461649217097728 https://twitter.com/RashidG92908642/status/1171910418807369728 To know more about this announcement in detail, visit Michael Thomsen’s blog on Medium. Other Interesting News in Programming Microsoft releases Cascadia Code version 1909.16, the latest monospaced font for Windows Terminal and Visual Studio Code Microsoft open-sources its C++ Standard Library (STL) used by MSVC tool-chain and Visual Studio Linux 5.3 releases with support for AMD Navi GPUs, Zhaoxin x86 CPUs and power usage improvements

Go 1.12 was released yesterday with opt-in support for TLS 1.3, improved modules support, support for windows/arm, and improved macOS & iOS forwards compatibility. The previous Go version, Go 1.11 was released in August last year. What’s new in Go 1.12? Opt-in support for TLS 1.3 Go 1.12 adds opt-in support for TLS 1.3 in the crypto/tls package. It can be enabled by adding the value tls13 = 1 to the GODEBUG environment variable. It will be enabled by default in Go 1.13. All TLS 1.2 features except TLSUnique in ConnectionState and renegotiation are available in TLS 1.3 and provide equivalent or better security and performance. TLS 1.3 cipher suites are not configurable. Since TLS 1.3 0-RTT mode involves clients keeping state regarding which servers support 0-RTT, a Go 1.12 server cannot be part of a load-balancing pool where some other servers do support 0-RTT. In TLS 1.3, the client is the last one to speak in the handshake, so if it causes an error to occur on the server, it will be returned on the client by the first Read, not by Handshake. Improved Module support The go command now supports module-aware operations outside of a module directory, provided that those operations do not need to resolve import paths relative to the current directory or explicitly edit the go.mod file. Commands such as go get, go list, and go mod download behave as if in a module with initially-empty requirements. go commands that download and extract modules are now safe to invoke concurrently. The go directive in a go.mod file now indicates the version of the language used by the files within that module. The go command will now try to use the modules mentioned in the main module's replace directives before consulting the module cache and the usual network sources. This happens when an import cannot be resolved using the active modules. Other changes Go's new windows/arm port supports running Go on Windows 10 IoT Core on 32-bit ARM chips. It also supports AIX 7.2 and later on POWER8 architectures (aix/ppc64). For macOS, Go 1.13 will require macOS 10.11 El Capitan or later. The go vet command has been rewritten so go tool vet is no longer supported. The Go tour is no longer included in the main binary distribution. The build cache is now required as a step toward eliminating $GOPATH/pkg Go 1.12 will translate the C type EGLDisplay to the Go type uintptr. The compiler's live variable analysis has improved. Wrappers generated by the compiler to implement method expressions are no longer reported by runtime.CallersFrames and runtime.Stack. The compiler toolchain now uses different conventions to call Go functions and assembly functions. Go 1.12 is the last release that will include the godoc webserver; in Go 1.13 it will be available via go get. The trace tool now supports plotting mutator utilization curves, including cross-references to the execution trace. Go 1.12 significantly improves the performance of sweeping when a large fraction of the heap remains live. These are just a select few updates. For full details about the changes in Go 1.12, you may go through the Go 1.12 release notes. Go 1.11 support announced for Google Cloud Functions! Go 1.11.3 and Go 1.10.6 released with fixes to security issues Google Cloud announces new Go 1.11 runtime for App Engine

Yesterday the Mypy team uploaded mypy 0.730 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes many features, bug fixes and library stub updates. You can install it as follows: python3 -m pip install -U mypy Python creator Guido van Rossum tweeted about this release, he says “mypy 0.720 released. New semantic analyzer is now the default! Also, --warn-unreachable flag, and many more fixes and updates.” Major updates in Mypy 0.730 Some of the breaking changes in the Mypy 0.730 include: More precise error locations If you call a function with an incompatible argument type, mypy now points the error message to the argument with the incompatible type. Previously, mypy pointed to the function being called, which could be confusing in multi-line calls. Error codes Mypy 0.730 can now optionally display error codes. They are shown within square brackets after each error message: prog.py:24: error: "str" has no attribute "trim"  [attr-defined] Enable error codes using --show-error-codes (or show_error_codes = True in a configuration file). Ignoring specific error codes You can ignore only errors with specific error codes on a particular line by using a # type: ignore[code, ...] comment. This reduces the risk of ignoring unexpected, serious errors when using # type: ignore comments that ignore (almost) all possible errors on a line. Colors in output Mypy 0.730 now uses colored, more user-friendly output by default. You can use --no-color to disable colored output. You can use --no-error-summary to hide the summary line with the number of errors. Pretty output mode You can use --pretty to display each line which had errors and a caret that points to the location of the error on each line. Old semantic analyzer removed This release of Mypy 0.730 no longer includes the old semantic analyzer. Reachability and context managers The --warn-unreachable option now behaves more correctly with “exception-swallowing” context managers. If a context manager is currently declared to return bool but it never swallows exceptions, you should annotate the return of __exit__ as Literal[False] instead of bool, or otherwise mypy may complain about missing return statements. To know more about this release, read the full documentation on Read the Docs. Other interesting news in programming Łukasz Langa at PyLondinium19: “If Python stays synonymous with CPython for too long, we’ll be in big trouble” Microsoft introduces Pyright, a static type checker for the Python language written in TypeScript Python 3.8 alpha 2 is now available for testing

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