Tech News - Languages

Chris Dickinson, a developer working on implementing Git in Rust shared updates on his project Git-rs. This is his second try over the same project. He writes, “I'm trying again this year after reading more of "Programming Rust" (Blandy, Orendorff).” Dickinson has maintained a ‘To Do’ list wherein he has written the steps right from reading the objects from loose store to creating a packfile and publishing it to crates. You can checkout his full project for his day-by-day updates. It is also quite interesting to see how developers are sharing their projects on Git and learning something new on a daily basis based on their experience. Users are overall happy to see Dickinson’s contribution. A user commented on Reddit, “Maybe everybody is happy just to use this as a personal learning experience for now, but I think there will be a lot of interest in a shared project eventually.” Users are also sharing their experiences from their own projects. A user commented on HackerNews, “I love to see people reimplementing existing tools on their own, because I find that to be a great way to learn more about those tools. I started on a Git implementation in Rust as well, though I haven't worked on it in a while.” Why work with Rust? Rust has been gaining tremendous popularity in recent times. Steve Klabnik, a popular blogger/developer shares his experiences working with Rust and how the language has outgrown him. He writes in his blog post, “I’m the only person who has been to every Rust conference in existence so far. I went to RustCamp, all three RustConfs, all five RustFests so far, all three Rust Belt Rusts. One RustRush. Am I forgetting any? Thirteen Rust conferences in the past four years.” He further adds, “ I’m starting to get used to hearing “oh yeah our team has been using Rust in production for a while now, it’s great.” The first time that happened, it felt very strange. Exciting, but strange. I wonder what the next stage of Rust’s growth will feel like.” Rust is also in the top fifteen (by the number of pull requests) as of 2018 in the GitHub Octoverse report. Moreover, according to the Go User Survey 2018, 19% of the respondents ranked it as a top preferred language which indicates a high level of interest in Rust among this audience. Last month, the team at Rust announced the stable release, Rust 1.33.0. This release brought improvements to const fns, compiler, and libraries. Last week, the Rust community organized the Rust Latam 2019 Conference at Montevideo for the Rust community. It involved 200+ Rust developers and enthusiasts from the world. https://twitter.com/Sunjay03/status/1112095011951308800 ‘Developers’ lives matter’: Chinese developers protest over the “996 work schedule” on GitHub Sublime Text 3.2 released with Git integration, improved themes, editor control and much more! Microsoft open sources the Windows Calculator code on GitHub  

TypeScript 3.2 was released yesterday. It is a language that brings static type-checking to JavaScript which enables developers to catch issues even before the code is run. TypeScript 3.2 includes the latest JavaScript features from ECMAScript standard. In addition to type-checking, it provides tooling in editors to jump to variable definitions, find the user of a function, and automate refactorings. You can install TypeScript 3.2 via NuGet or install via npm as follows: npm install -g typescript Now let’s look at the new features in TypeScript 3.2. strictBindCallApply TypeScript 3.2 comes with stricter checking for bind, call, and apply. In JavaScript, bind, call, and apply are methods on functions that allow actions like bind this and partially apply arguments. They also allow you to call functions with a different value for this, and call functions with an array for their arguments. Earlier, TypeScript didn’t have the power to model these functions. Demand to model these patterns in a type-safe way led the TypeScript developers to revisit this problem. There were two features that opened up the right abstractions to accurately type bind, call, and apply without any hard-coding: this parameter types from TypeScript 2.0 Modeling the parameter lists with tuple types from TypeScript 3.0 The combination of these two can ensure that the uses of bind, call, and apply are more strictly checked when we use a new flag called strictBindCallApply. When this new flag is used, the methods on callable objects are described by a new global type—CallableFunction. It declares stricter versions of the signatures for bind, call, and apply. Similarly, any methods on constructable (which are not callable) objects are described by a new global type called NewableFunction. A caveat of this new functionality is that bind, call, and apply can’t yet fully model generic functions or functions having overloads. Object spread on generic types JavaScript has a handy way of copying existing properties from an existing object into a new object called “spreads”. To spread an existing object into a new object, an element with three consecutive periods (...) can be defined. TypeScript does well in this area when it has enough information about the type. But it wouldn’t work with generics at all until now. A new concept in the type system called an “object spread type” could have been used. This would be a new type operator that looks like this: { ...T, ...U } to reflect the syntax of an object spread. If T and U are known, that type would flatten to some new object type. This approach was complex and required adding new rules to type relationships and inference. After exploring several different avenues, two conclusions arrived: Users were fine modeling the behavior with intersection types for most uses of spreads in JavaScript. For example, Foo & Bar. Object.assign: This a function that exhibits most of the behavior of spreading objects. It is already modeled using intersection types. There has been very little negative feedback around that. Intersections model the common cases and they’re relatively easy to reason about for both users and the type system. So now TypeScript 3.2 allows object spreads on generics and models them using intersections. Object rest on generic types Object rest patterns are kind of a dual to object spreads. It creates a new object that lacks some specified properties instead of creating a new object with some extra or overridden properties. Configuration inheritance via node_modules packages TypeScript has supported extending tsconfig.json files by using the extends field for a long time. This feature is useful to avoid duplicating configuration which can easily fall out of sync. It really works best when multiple projects are co-located in the same repository. This way each project can reference a common “base” tsconfig.json. But some projects are written and published as fully independent packages. Such projects don’t have a common file they can reference. So as a workaround, users could create a separate package and reference that. TypeScript 3.2 resolves tsconfig.jsons from node_modules. TypeScript will dive into node_modules packages when a bare path for the "extends" field in tsconfig.json is used. Diagnosing tsconfig.json with --showConfig The TypeScript compiler, tsc, now supports a new flag called --showConfig. On running tsc --showConfig, TypeScript will calculate the effective tsconfig.json and print it out. BigInt BigInts are a part of an upcoming ECMAScript proposal that allow modeling theoretically arbitrarily large integers. TypeScript 3.2 comes with type-checking for BigInts along with support for emitting BigInt literals when targeting esnext. Support for BigInt in TypeScript introduces a new primitive type called bigint. BigInt support is only available for the esnext target. Object.defineProperty declarations in JavaScript When writing in JavaScript files using allowJs, TypeScript 3.2 recognizes declarations that use Object.defineProperty. This means better completions, and stronger type-checking when enabling type-checking in JavaScript files. Improvements in error messages A few things have been added in TypeScript 3.2 that will make the language easier to use. Better missing property errors Better error spans in arrays and arrow functions Error on most-overlapping types in unions or “pick most overlappy type” Related spans on a typed this being shadowed A new warning message that says Did you forget a semicolon? on parenthesized expressions on the next line is added More specific messages are displayed when assigning to const/readonly bindings When extending complex types, more accurate messages are shown Relative module names are used in error messages Improved narrowing for tagged unions TypeScript now makes narrowing easier by relaxing rules for a discriminant property. The common properties of unions are now considered discriminants as long as they contain some singleton type and contain no generics. For example, a string literal, null, or undefined. Editing improvements The TypeScript project doesn’t have a compiler/type-checker. The core components of the compiler provide a cross-platform open-source language service that can power smart editor features. These features include go-to-definition, find-all-references, and a number of quick fixes and refactorings. Implicit any suggestions and “infer from usage” fixes noImplicitAny is a strict checking mode, and it helps ensure the code is as fully typed as possible. This also leads to a better editing experience. TypeScript 3.2 produces suggestions for most of the variables and parameters that would have been reported as having implicit any types. TypeScript provides a quick fix to automatically infer the types when an editor reports these suggestions. Other fixes There are two smaller quick fixes: A missing new is added when a constructor is called accidentally. An intermediate assertion is added to unknown when types are sufficiently unrelated. Improved formatting TypeScript 3.2 is smarter in formatting several different constructs. Breaking changes and deprecations TypeScript has moved more to generating DOM declarations in lib.d.ts by leveraging IDL files. Certain parameters no longer accept null or accept more specific types. Certain WebKit-specific properties have been deprecated. wheelDelta and friends have been removed as they are deprecated properties on WheelEvents. JSX resolution changes The logic for resolving JSX invocations has been unified with the logic for resolving function calls. This action has simplified the compiler codebase and improved certain use-cases. The further TypeScript releases will need Visual Studio 2017 or higher. For more details, visit the Microsoft Blog. Introducing ReX.js v1.0.0 a companion library for RegEx written in TypeScript Vue.js 3.0 is ditching JavaScript for TypeScript. What else is new? Babel 7 released with Typescript and JSX fragment support

Yesterday, Diane Hosfelt, a Research Engineer at Mozilla, shared what she and her team experienced when rewriting Firefox internals in Rust. Taking Quantum CSS as a case study, she touched upon the potential security vulnerabilities that could have been prevented if it was written in Rust from the very beginning. Why Mozilla decided to rewrite Firefox internal in Rust? Quantum CSS is a part of Mozilla’s Project Quantum, under which it is rewriting Firefox internals to make it faster. One of the major parts of this project is Servo, an engine designed to provide better concurrency and parallelism. To achieve these goals Mozilla decided to rewrite Servo in Rust, replacing C++. Rust is very similar to C++ in some ways while being different in terms of the abstractions and data structures it uses. It was created by Mozilla keeping concurrency safety in mind. Its type and memory-safe property make programs written in Rust thread-safe. What type of bugs does Rust prevent? Overall Rust prevents bugs related to memory, bounds, null/uninitialized variables, or integer by default. Hosfelt mentioned in her blog post, “Due to the overlap between memory safety violations and security-related bugs, we can say that Rust code should result in fewer critical CVEs (Common Vulnerabilities and Exposures).” However, there are some types of bugs that Rust does not address like correctness bugs. According to Hosfelt, Rust is a good option in the following cases: When your program involves processing of untrusted input safely When you want to use parallelism for better performance When you are integrating isolated components into an existing codebase You can go through the blog post by Diane Hosfelt on Mozilla’s website. Mozilla shares key takeaways from the Design Tools survey Mozilla partners with Scroll to understand consumer attitudes for an ad-free experience on the web Mozilla partners with Ubisoft to Clever-Commit its code, an artificial intelligence assisted assistant

Researchers Paul Emmerich et al have developed a new simple user space network driver called ixy. According to the researchers, ixy is an educational user space network driver for the Intel ixgbe family of 10 Gbit/s NICs. Its goal is to show that writing a super-fast network driver can be surprisingly simple in high-level languages like Rust, Go, Java and C# among others. Ixy has no dependencies, high speed, and a simple-to-use interface for applications to be built on it. The researchers have published their findings in a paper titled The Case for Writing Network Drivers in High-Level Programming Languages. Initially, the researchers implemented ixy in C and then successfully implemented the same driver in other high-level languages such as Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python. The researchers have found that the Rust driver executes 63% more instructions per packet but is only 4% slower than a reference C implementation. Go’s garbage collector keeps latencies below 100 µs even under heavy load. Network drivers written in C are vulnerable to security issues Drivers written in C are usually implemented in production-grade server, desktop, and mobile operating systems. Though C has features required for low-level systems programming and fine-grained control over the hardware, they have vulnerabilities for security as “they are exposed to the external world or serve as a barrier isolating untrusted virtual machines”. The paper states that the C code “accounts for 66% of the code in Linux, but 39 out of 40 security bugs related to memory safety found in Linux in 2017 are located in drivers. These bugs could have been prevented by using high-level languages for drivers.” Implementing Rust, Go and other high level languages in ixy network driver Rust: A lightweight Rust struct is allocated for each packet that contains metadata and owns the raw memory. The compiler enforces that the object has a single owner and only the owner can access the object. This prevents use-after-free bugs despite using a completely custom allocator. Rust is the only language evaluated in the case study that protects against use-after-free bugs and data races in memory buffers. Go: It has an external memory that is wrapped in slices to provide bounds checks. The atomic package in Go also indirectly provides memory barriers and volatile semantics thus offering stronger guarantees. C#: The researchers have implemented two external memories out of the many available. It offers a more direct way to work with raw memory by offering full support for pointers with no bounds checks and volatile memory access semantics. Java: The researchers have targeted OpenJDK 12 which offers a non-standard way to handle external memory via the sun.misc.Unsafe object that provides functions to read and write memory with volatile access semantics. OCaml: OCaml Bigarrays backed by external memory is used for DMA buffers and PCIe resources, the allocation is done via C helper functions. The Cstruct library from the OCaml allowed researchers to access data in the arrays in a structured way by parsing definitions similar to C struct definitions and generating code for the necessary accessor functions. Haskell: It is a compiled functional language with garbage collection. The necessary low-level memory access functions are available via the Foreign package. Memory allocation and mapping is available via System.Posix.Memory. Swift: Its memory is managed via automatic reference counting, i.e., the runtime keeps a reference count for each object and frees the object once it is no longer in use. It also offers all the features necessary to implement drivers. JavaScript: ArrayBuffers is used to wrap external memory in a safe way, these arrays can then be accessed as different integer types using TypedArrays, circumventing JavaScript’s restriction to floating-point numbers. Memory allocation and physical address translation is handled via a Node.js module in C. Python: For this driver, the implementation was not explicitly optimized for performance and meant as a simple prototyping environment for PCIe drivers and as an educational tool. The researchers have provided primitives for PCIe driver development in Python. Rust is found to be the prime candidate for safer network drivers After implementing the network driver ixy in all high-level languages, the researchers conclude that Rust is the prime candidate for safer drivers. The paper states, “Rust’s ownership based memory management provides more safety features than languages based on garbage collection here and it does so without affecting latency.” Other languages like Go and C# are also a suitable language if the system can cope with sub-millisecond latency spikes due to garbage collection. Other languages like Haskell and OCaml will also be more useful if their performance is less critical than having a safe and correct system. Though Rust performs better than C, it is 4% slower than the C driver. The reason behind is that Rust applies bounds checks while C does not. Another reason is that C does not require a wrapper object for DMA buffers. Image Source: Research paper Users have found the result of this high-level language implementation of network drivers quite interesting. https://twitter.com/matthewwarren/status/1172094036297048068 A Redditor comments, “Wow, Rust and Go performed quite well. Maybe writing drivers in them isn't that crazy” Many developers are also surprised to see the results of this case study, especially the performance of Go and Swift. A comment on Hacker News says, “The fact that Go is slower than C# really amazes me! Not long ago I switched from C# to Go on a project for performance reasons, but maybe I need to go back.” Another Redditor says, “Surprise me a bit that Swift implementation is well below expected. Being Swift a compiled native ARC language, I consider the code must be revised.” Interested readers can watch a video presentation by Paul Emmerich on ‘How to write PCIe drivers in Rust, go, C#, Swift, Haskell, and OCaml’. Also, you can find more implementation details in the research paper. Other News in Tech New memory usage optimizations implemented in V8 Lite can also benefit V8 Google releases Flutter 1.9 at GDD (Google Developer Days) conference Intel’s DDIO and RDMA enabled microprocessors vulnerable to new NetCAT attack

Last week, the Python team released NumPy version 1.17.0. This version has many new features, improvements and changes to increase the performance of NumPy. The major highlight of this release includes a new extensible numpy.random module, new radix sort & timsort sorting methods and a NumPy pocketfft FFT implementation for accurate transforms and better handling of datasets of prime length. Overriding of numpy functions has also been made possible by default. NumPy 1.17.0 will support Python versions 3.5 - 3.7. Python 3.8b2 will work with the new release source packages, but may not find support in future releases. The Python team had previously updated users that Python 2.7 maintenance will stop on January 1, 2020. NumPy 1.17.0 officially dropping Python 2.7 is a step towards the adoption of Python 3. Developers who want to port their Python 2 code in Python 3, can check out the official porting guide, released by Python. Read More: NumPy drops Python 2 support. Now you need Python 3.5 or later. What’s new in NumPy 1.17.0? New extensible numpy.random module with selectable random number generators NumPy 1.17.0 has a new extensible numpy.random module. It also includes four selectable random number generators and improved seeding designed for use in parallel processes. PCG64 is the new default numpy.random module while MT19937 is retained for backwards compatibility. Timsort and radix sort have replaced mergesort for stable sorting Both the radix sort and timsort have been implemented and can be used instead of mergesort. The sorting kind options ‘stable’ and ‘mergesort’ have been made aliases of each other with the actual sort implementation for maintaining backward compatibility. Radix sort is used for small integer types of 16 bits or less and timsort is used for all the remaining types of bits. empty_like and related functions now accept a shape argument Functions like empty_like, full_like, ones_like and zeros_like will now accept a shape keyword argument, which can be used to create a new array as the prototype and overriding its shape also. These functions become extremely useful when combined with the __array_function__ protocol, as it allows the creation of new arbitrary-shape arrays from NumPy-like libraries. User-defined LAPACK detection order numpy.distutils now uses an environment variable, comma-separated and case insensitive detection order to determine the detection order for LAPACK libraries. This aims to help users with MKL installation to try different implementations. .npy files support unicode field names A new format version of .npy files has been introduced. This enables structured types with non-latin1 field names. It can be used automatically when needed. New mode “empty” for pad The new mode “empty” pads an array to a desired shape without initializing any new entries. New Deprications in NumPy 1.17.0 numpy.polynomial functions warn when passed float in place of int Previously, functions in numpy.polynomial module used to accept float values. With the latest NumPy version 1.17.0, using float values is deprecated for consistency with the rest of NumPy. In future releases, it will cause a TypeError. Deprecate numpy.distutils.exec_command and temp_file_name The internal use of these functions has been refactored for better alternatives such as replace exec_command with subprocess. Also, replace Popen and temp_file_name <numpy.distutils.exec_command> with tempfile.mkstemp. Writeable flag of C-API wrapped arrays When an array is created from the C-API to wrap a pointer to data, the writeable flag set during creation indicates the read-write nature of the data. In the future releases, it will not be possible to convert the writeable flag to True from python as it is considered dangerous. Other improvements and changes Replacement of the fftpack based fft module by the pocketfft library pocketfft library contains additional modifications compared to fftpack which helps in improving accuracy and performance. If FFT lengths has large prime factors then pocketfft uses Bluestein's algorithm, which maintains O(N log N) run time complexity instead of deteriorating towards O(N*N) for prime lengths. Array comparison assertions include maximum differences Error messages from array comparison tests such as testing.assert_allclos now include “max absolute difference” and “max relative difference” along with previous “mismatch” percentage. This makes it easier to update absolute and relative error tolerances. median and percentile family of functions no longer warn about nan Functions like numpy.median, numpy.percentile, and numpy.quantile are used to emit a RuntimeWarning when encountering a nan. Since these functions return the nan value, the warning is redundant and hence has been removed. timedelta64 % 0 behavior adjusted to return NaT The modulus operation with two np.timedelta64 operands now returns NaT in case of division by zero, rather than returning zero. Though users are happy with NumPy 1.17.0 features, some are upset over the Python version 2.7 being officially dropped. https://twitter.com/antocuni/status/1156236201625624576 For the complete list of updates, head over to NumPy 1.17.0 release notes. Plotly 4.0, popular python data visualization framework, releases with Offline Only, Express first, Displayable anywhere features Python 3.8 new features: the walrus operator, positional-only parameters, and much more Azure DevOps report: How a bug caused ‘sqlite3 for Python’ to go missing from Linux images

Scala in its recent announcement suggested the roadmap for Scala 3.0 and what features developers can expect in Scala 3. Following this, the Scala community also announced the new release will be Scala 2.13 and mentioned that Scala 3 will succeed Scala 2.13. With the first official talk about Scala 3, the community also unveiled its secret project called Dotty. It announced that Dotty will become Scala 3. Dotty is a set of compiler technology for Scala. The suggested timeline for the preview release of Scala 3.0 is around early 2020. With this development, the community has suggested that Scala 2.13, expected to release in few months, will be an important release for migration to Scala 3. What can you expect in Scala 3? The community is working to fuse two big paradigms: Object-Oriented programming and functional programming together to make development more convenient in Scala ecosystem. Alongside this ongoing improvement, the community is focussing on the following aspects: With Scala 3, the community is emphasizing on 4 main features of Scala: consistency, safety, ergonomics, and performance. The community is working on adding types and operators to carry out these functionalities. In Scala 3 expect advanced programming paradigms like metaprogramming and generative programming. Currently, the macro systems are implemented at an experimental level to carry out metaprogramming. The community has suggested replacing the macro system with some other solution. Generative programming design with scala is currently under development. Improvement in Scala tools for building strong foundations for software design. Also removal of some components of the language that are rarely used to make the language lightweight. Automatic rewriting through the scalafix tool for efficient migration of code from Scala 2 to Scala 3. Updated Scala compiler, IDE plugins, REPL, Scaladoc, and build tools. The community is working on updating the Dotty plugins and its standard build tools SBT for working properly with Scala 3. Scala 3 will share the same standard library used in Scala 2. However, with the update, Scala 3 will not be binary compatible with Scala 2 because of the update in Scala compiler. The community is working on making the migration as smooth as possible which makes the release of Scala 2.14 pivotal. To get an early preview of Scala 3 features, developers can start working on the development of Dotty, available on the GitHub repository and report any issues on the issues page. Scala 2.12.5 is here!

It’s been more than 20 years since Microsoft released the first version of the C# language. Over the years C# has experienced a remarkable evolution, from being called as a Java copycat to one of the most loved and used programming languages. The current developments in C# 7 ecosystem are exciting, and grabbing the attention of developers, but what about the future? Can developers take a sneak peek into the future of C#? Well of course they can! The Microsoft language design team have been developing the language features ‘in the open’ for quite some time now. They have proposed several new features for the upcoming C# 8.0 and have released several prototypes for the developers, to try them out and provide feedback on the official Github repo. Let’s take a look at the most likely new C# 8 features: Nullable Reference Types The name of this particular feature might confuse a lot of developers wondering “Isn’t nullable reference a bad idea?” or “Shouldn’t it be called non nullable reference types?”. Sir Tony Hoare, a British computer scientist invented null references and famously called them the “Billion Dollar Mistake” as the biggest problem is, of course, the risk of getting the infamous null-reference exception. Since all reference types in C# can be null, you always run the risk of getting an exception when you try to access some member of the object. Functional languages try to deal with this problem by having a type that represents the concept of potential absent value. Instead of introducing non-nullable reference types in C#, Microsoft has chosen to consider reference types as non-nullable by default and provide mechanisms to deal with nullable types. Since the premise of a reference is often considered to be non-nullable and to be dereferenced. Asynchronous Streams Asynchronous streams provide the ability to use async/await inside an iterator. In most cases, an iterator is implemented synchronously. There are some cases, however, where it might need to await a call on every iteration to fetch the next item. In such cases, asynchronous streams can come in handy. To support this feature, a couple of things need to be taken care of: New types, the async equivalents of IEnumerable and IEnumerator Ability to specify an await on an iterator construct such as foreach. Default interface implementations: The primary use case for default interface methods is to enable the developer to safely evolve an interface. You could add new methods to it and, as long as you provide a default implementation, existing clients of the interface wouldn’t be forced to implement it. Another important value proposition of default implementation on interfaces relates to Android and iOS. Since both Java and Swift offer this feature, it’s tricky to use C# to wrap Android/iOS APIs that make use of default interface implementations. C# 8.0 will make it possible to wrap those APIs more faithfully. There are plenty of other features proposed to be implemented in C# 8 such as target-typed new expressions, covariant return types, and extension everything. All these features are in different stages of development and a lot can (and probably will) change from now until C# 8.0’s release Till then you can closely follow the official Github repo for C#.   Stay up to date with the latest features, release dates, and general discussions on key programming tools and tech by subscribing to Packt Hub. Check out other latest news: Red Programming Language for Android development! What’s new in Visual Studio 1.22 OpenCV 4.0 is on schedule for July release

Just two months ago, the team behind GCC (GNU Compiler Collection) made certain changes to GCC 9.1. And Last week, the team released GCC 9.1 with improved diagnostics, location and simpler C++ errors.  What’s new in GCC 9.1? Changes to diagnostics The team added a left-hand margin that shows line numbers. GCC 9.1 now has a new look for the diagnostics. The diagnostics can label regions of the source code in order to show relevant information. The diagnostics come with left-hand and right-hand sides of the “+” operator, so GCC highlights them inline. The team has added a JSON output format such that GCC 9.1 now has a machine-readable output format for diagnostics. C++ errors  The compiler usually has to consider several functions while dealing with C++ at a given call site and reject all of them for different reasons. Also, the g++‘s error messages need to be handled and a specific reason needs to be given for rejecting each function. This makes simple cases difficult to read. This release comes with a  special-casing to simplify g++ errors for common cases. Improved C++ syntax in GCC 9.1 The major issue within GCC’s internal representation is that not every node within the syntax tree has a source location. For GCC 9.1, the team has worked to solve this problem so that most of the places in the C++ syntax tree now retain location information for longer. Users can now emit optimization information GCC 9.1 can now automatically vectorize loops and reorganize them to work on multiple iterations at once. Users will now have an option, -fopt-info, that will help in emitting optimization information. Improved runtime library in GCC 9.1 This release comes with improved experimental support for C++17, including <memory_resource>. There will also be a support for opening file streams with wide character paths on Windows. Arm specific This release comes with support for the deprecated Armv2 and Armv3 architectures and their variants have been removed. Support for the Armv5 and Armv5E architectures has also been removed. To know more about this news, check out RedHat’s blog post. DragonFly BSD 5.4.1 released with new system compiler in GCC 8 and more The D language front-end support finally merged into GCC 9 GCC 8.1 Standards released!

Last week, Bryn Jackson, CEO of Spectrum, a real-time community-centered conversational platform, announced that the project is now acquired by GitHub. Bryn, along with Brian Lovin, and Max Stoiber founded the Spectrum community platform in February 2017. This community is a place to ask questions, request features, report bugs, and also chat with the Spectrum team for queries. In a blogpost Bryn wrote, “After releasing an early prototype, people told us they also wanted to use it for their communities, so we decided to go all-in and build an open, inclusive home for developer and designer communities. Since officially launching the platform late last year, Spectrum has become home to almost 5,000 communities!” What will Spectrum bring to GitHub communities? By joining GitHub, Spectrum aims to align to GitHub’s goals of making developer lives easier and of fostering a strong community across the globe. For communities across GitHub, Spectrum will provide: A space for different communities across the internet. Free access to its full suite of features - including unlimited moderators, private communities and channels, and community analytics. A deeper integration with GitHub Spectrum has also opened a pull request to add some of GitHub’s policies to Spectrum’s Privacy Policy, which will be merged this week. Though many users have not heard about Spectrum, they are positively reacting towards its acquisition by GitHub. Many users have also compared it with other platforms such as Slack, Discord, and Gitter. To know more about this news, read Bryn Jackson’s blog post. GitHub Octoverse: The top programming languages of 2018 GitHub has passed an incredible 100 million repositories Github now allows repository owners to delete an issue: curse or a boon?

Last week, Poetry, a dependency management and packaging tool for Python released their version 1 beta 1. Before venturing into details of this Poetry release, let’s have a brief overview about Python, its issues with dependency management, pipenv and Poetry in general. There’s no doubt that Python is loved by many developers. It is considered as one of the top-rated programming languages with benefits like extensive support library, less-complex syntax, high productivity, excellent integration feature, and many more. Though it has been rated as one of the fastest growing programming languages in 2019, there are some problems with Python, which if rectified, can make it more powerful and accessible to users. Python’s poor dependency management is one such issue. Dependency management helps in managing all the libraries required to make an application work. It becomes extremely necessary when working in a complex project or in a multi-environment. An ideal dependency management tool assists in tracking, updating libraries easier and faster, as well as to solve package dependency issues. Python’s dependency management requires users to make a virtual environment to have separate dependencies, manual addition of version number in every file, inability to parallelize dependency installation and more.  To combat these issues, Python now has two maturing dependency management tools called Pipenv and Poetry. Each of these tools simplify the process of creating a virtual environment and sorting dependencies.  The PyPA-endorsed Pipenv automatically creates and manages a virtualenv for user projects. It also adds/removes packages from the Pipfile as a user installs/uninstalls packages. Its main features include automatically generating a Pipfile and a Pipfile.lock, if one doesn't exist, creating a virtualenv, adding packages to a Pipfile when installed to name a few. On the other hand, Poetry dependency management tool uses only one pyproject.toml file to manage all the dependencies. Poetry allows users to declare the libraries that their project depends on and Poetry will automatically install/update them for the user. It allows projects to be directly published to PyPI, easy tracking of the state of dependencies, and more.  New features in Poetry v1 beta 1 The major highlight in Poetry v1 beta 1 is the new added support for url dependencies in the pull request checklist. This new feature is a significant one for Python users, as it can be added to a current project via the add command or by modifying the pyproject.toml file directly.  Other features in Poetry v1 beta 1 Support for publishing to PyPI using API tokens Licenses can be identified by their full name Settings can be specified with environment variables Settings no longer need to be prefixed by settings, when using the config command.  Users, in general, are quite happy with the Poetry dependency management tool for Python, as can be seen in the user reactions below from Hacker News.  A comment on Hacker News reads, “I like how transparent poetry is about what's happening when you run it, and how well presented that information is. I've come to loathe pipenv's progress bar. Running it in verbose mode isn't much better. I can't be too mad at pipenv, but all in all poetry is a better experience.” Another user says, “Poetry is very good. I think projects should use it. I hope the rest of the ecosystem can catch up quickly. Tox and pip and and pex need full support for PEP 517/518.” Another user comments, “When you run poetry, it activates the virtualenv before it runs whatever you wanted. So `poetry add` (it's version of pip install) doesn't require you to have the virtualenv active. It will activate it, run the install, and update your dependency specifications in pyproject.toml.  You can also do `poetry run` and it will activate the virtualenv before it runs whatever shell command comes after. Or you can do `poetry shell` to run a shell inside the virtualenv. I like the seamless integration, personally.” Łukasz Langa at PyLondinium19: “If Python stays synonymous with CPython for too long, we’ll be in big trouble” PyTorch 1.2 is here with a new TorchScript API, expanded ONNX export, and more NumPy 1.17.0 is here, officially drops Python 2.7 support pushing forward Python 3 adoption

Racket programming language has a new version update, Racket 7.0. Users might not see huge differences between the previous version of Racket, v6.12 released in January 2018. However, v7.0 differs in the internals significantly. Racket or Racket lang is a multi-paradigm programming language--with an emphasis on functional programming--in the Lisp-Scheme family. Though not a popular one, Racket is considered as one of the easiest programming language. Languages such as Python, C#, Assembly, and so on are often talked about in the easy-categories; however, Racket lang is also a great choice as a starter language. What’s new in Racket 7.0? Updated Runtime This version includes a substantial change in its current runtime system and supports multiple runtime systems. New macro expander Version 7.0 replaces about ⅛ of the core v6.12 implementation with a new macro expander that bootstraps itself. The expander turns out to be about 40% of the new code needed to replace Racket’s core with Chez Scheme. Most of the other 60% is also implemented, but it is not included in this release. However, Racket-on-Chez will be ready for production use later in the v7.x series. Updates to DrRacket, the programming environment for Racket DrRacket’s “Create Executable” option for the teaching language (Beginner Student, etc.) uses --embed-dlls to create single-file, standalone ".exe"s on Windows. Improved supports within TypedRacket TypedRacket is Racket’s gradually-typed sister language which allows the incremental addition of statically-checked type annotations. TypedRacket’s support for prefab structs is significantly improved. This supports using prefab structs more polymorphically and fixes significant bugs in the current implementation. Programs which currently use predicates for prefab structs on unknown data may need to be revised since previous versions of Typed Racket allowed potentially buggy programs to type check. Check out Typed Racket RFC 1 and prefab Changes doc for more details on this change and on how to fix programs affected by it. Typed Racket also supports #:rest-star in the ->* type constructor, which allows function types to specify rest arguments with more complex patterns of types, such as the hash function. Other features in the Racket 7.0 include: The syntax (#') form supports new template subforms: ~@ for splicing and ~? for choosing between subtemplates based on whether pattern variables have “absent” value (from an ~optional pattern in syntax-parse, for example). The syntax/parse/experimental/templatelibrary, where these features originated, re-exports the new forms under old names for compatibility. On Windows, an --embed-dlls flag for raco exe creates a truly standalone, single-file ".exe" that embeds Racket’s DLLs. Interactive overlays can be added to plots produced by plot-snip. This allows constructing interactive plots or displaying additional information when the mouse hovers over the plot area. Examples of how to use this feature can be found on Alex Harsanyi’s blog racket/plot provides procedures for displaying candlestick charts for use in financial time series analysis. Added contract-equivalent?, a way to check whether two contracts are mutually stronger than each other without the exponential slowdown that two calls to contract-stronger? brings. Lazy Racket supports functions with keyword arguments. Read more about Racket 7.0 on the Racket official blog. What is the difference between functional and object-oriented programming? Putting the Function in Functional Programming Elixir Basics – Foundational Steps toward Functional Programming

Yesterday Facebook released a new JavaScript engine called Hermes under an open source MIT license. According to Facebook, this new engine will speed up start times for native Android apps built with React Native framework. https://twitter.com/reactnative/status/1149347916877901824 Facebook software engineer Marc Horowitz unveiled Hermes at the Chain React 2019 conference held yesterday in Portland, Oregon. Hermes is a new tool for developers to primarily improve app startup performance in the same way Facebook does for its apps, and to make apps more efficient on low-end smartphones. The supposed advantage of Hermes is that developers can target all three mobile platforms with a single code base; but as with any cross-platform framework, there are trade offs in terms of performance, security and flexibility. Hermes is available on GitHub for all developers to use. It has also got its own Twitter account and home page. In a demo, Horowitz showed that a React Native app with Hermes was fully loaded within half the time the same app without Hermes loaded, or about two seconds faster. Check out the video below: Horowitz emphasized on the fact that Hermes cuts the APK size (the size of the app file) to half the 41MB of a stock React Native app, and removes a quarter of the app's memory usage. In other words, with Hermes developers can get users interacting with an app faster with fewer obstacles like slow download times and constraints caused by multiple apps sharing in a limited memory resources, especially on lower-end phones. And these are exactly the phones Facebook is aiming at with Hermes, compared to the fancy high-end phones that well-paid developers typically use themselves. "As developers we tend to carry the latest flagship devices. Most users around the world don't," he said. "Commonly used Android devices have less memory and less storage than the newest phones and much less than a desktop. This is especially true outside of the United States. Mobile flash is also relatively slow, leading to high I/O latency." It's not every day a new JavaScript engine is born, but while there are plenty such engines available for browsers, like Google's V8, Mozilla's SpiderMonkey, Microsoft's Chakra, Horowitz notes Hermes is not aimed at browsers or, for example, how Node.js on the server side. "We're not trying to compete in the browser space or the server space. Hermes could in theory be for those kinds of use cases, that's never been our goal." The Register reports that Facebook has no plan to push Hermes' beyond React Native to Node.js or to turn it into the foundation of a Facebook-branded browser. This is because it's optimized for mobile apps and wouldn't offer advantages over other engines in other usage scenarios. Hermes tries to be efficient through bytecode precompilation – rather than loading JavaScript and then parsing it. Hermes employs ahead-of-time (AOT) compilation during the mobile app build process to allow for more extensive bytecode optimization. Along similar lines, the Fuchsia Dart compiler for iOS is an AOT compiler. There are other ways to squeeze more performance out of JavaScript. The V8 engine, for example, offers a capability called custom snapshots. However, this is a bit more technically demanding than using Hermes. Hermes also abandons the just in time (JIT) compiler used by other JavaScript engines to compile frequently interpreted code into machine code. In the context of React Native, the JIT doesn't do that much to ease mobile app workloads. The reason Hermes exists, as per Facebook, is to make React Native better. "Hermes allows for more optimization on mobile since developers control the build stack," said a Facebook spokesperson in an email to The Register. "For example, we implemented bytecode precompilation to improve performance and developed more efficient garbage collection to reduce memory usage." In a discussion on Hacker News, Microsoft developer Andrew Coates claims that internal testing of Hermes and React Native in conjunction with Microsoft Office for Android shows TTI using Hermes at 1.1s, compared to 1.4s for V8, and with 21.5MB runtime memory impact, compared to 30MB with V8. Hermes is mostly compatible with ES6 JavaScript. To keep the engine small, support for some language features is missing, like with statements and local mode eval(). Facebook’s spokesperson also said to The Register that they are planning to publish benchmark figures in the next week to support its performance claims. Declarative UI programming faceoff: Apple’s SwiftUI vs Google’s Flutter OpenID Foundation questions Apple’s Sign In feature, says it has security and privacy risks Material-UI v4 releases with CSS specificity, Classes boilerplate, migration to Typescript and more

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

Yesterday, at the Spark + AI summit, the team at Apache Spark announced .NET for Apache Spark, a popular open source distributed processing engine used for analytics over large data sets. It can also be used for processing real-time streams, batches of data, machine learning, and ad-hoc query. .NET fo Apache Spark for developers .NET for Apache Spark aims at making Apache Spark accessible to .NET developers across all Spark APIs. The team at Apache Spark aims to develop .NET for Apache Spark in the open (as a .NET Foundation member project) along with the Spark and .NET community for the developers. .NET for Apache Spark comes with high-performance APIs for using Spark from C# and F#. With .NET APIs, users can now access all aspects of Apache Spark including streaming, Spark SQL, DataFrames, MLLib, etc. It lets the developers reuse all the skills, code, knowledge, and libraries. The C#/ F# language that binds to Spark will be written on a new Spark interop layer that will offer easier extensibility. .NET for Apache Spark can be used on Linux, macOS, and Windows and is compliant with .NET Standard 2.0. .NET for Apache Spark performance The first preview version of .NET for Apache Spark performs well on the popular TPC-H benchmark. This benchmark consists of a suite of business-oriented queries. .NET for Apache Spark has a better performance against Python and Scala. It is also 2 times faster than Python. What more features can be expected? In the future, the team aims to simplify the documentation and samples and work towards native integration with developer tools such as Visual Studio, Visual Studio Code, Jupyter notebooks. Developers can also expect .NET support for user-defined aggregate functions and .NET idiomatic APIs for C# and F# (e.g., using LINQ for writing queries). The team is also working towards adding support for Azure Databricks, Kubernetes, etc. and making .NET for Apache Spark part of Spark Core. Few users are excited about this news and are expecting some major improvement with .NET for Spark. A user commented on HackerNews, “I've seen the announcement about .NET interior support in Apache Spark some time ago. The benchmarks are interesting and tell the story - in few cases it is faster than Python, but slower than native (for Spark) Scala/JVM. Maybe with Arrow interchange Python's performance would increase (and for other interpose that would use Array - i.e. for .Net).” Few others are confused about the transition, as they have to get their teams shifted to the new setup. Another user commented, “Indeed the real sad part is you can’t lead teams there early (premature optimization). Everybody seems to make the same rough transition on their own.” To know more about this news, check out the post by Apache Spark. Winners for the 2019 .NET Foundation Board of Directors elections are finally declared Fedora 31 will now come with Mono 5 to offer open-source .NET support ML.NET 1.0 RC releases with support for TensorFlow models and much more!

Yesterday, the Go team shared the details of what all is coming in Go 1.13, the first release that is implemented using the new proposal evaluation process. In this process, feedback is taken from the community on a small number of proposals to reach the final decision. The team also shared what proposals they have selected to implement in Go 1.14 and the next steps. At Gophercon 2017, Russ Cox, Go programming language tech lead at Google, first disclosed the plan behind the implementation of Go 2. This plan was simple: the updates will be done in increments and will have minimal to no effect on everybody else. Updates in Go 1.13 Go 1.13, which marks the first increment towards Go 2, is planned to release in early August this year. A lot of language changes have landed in this release that were shortlisted from the huge list of Go 2 proposals based on the new proposal evaluation process. These proposals are selected under the criteria that they should address a problem, have minimal disruption, and provide a clear and well-understood solution. The team selected “relatively minor and mostly uncontroversial” proposals for this version. These changes are backward-compatible as modules, Go’s new dependency management system is not the default build mode yet. Go 1.11 and Go 1.12 include preliminary support for modules that makes dependency version information explicit and easier to manage. Proposals planned to be implemented in Go 1.13 The proposals that were initially planned to be implemented in Go 1.13 were: General Unicode identifiers based on Unicode TR31: This proposes to add support for enabling programmers using non-Westen alphabets to combine characters in identifiers and export uncased identifiers. Binary integer literals and support for_ in number literals: Go comes with support for octal, hexadecimal, and standard decimal literals. However, unlike other mainstream languages like Java 7, Python 3, and Ruby, it does not have support for binary integer literals. This proposes adding support for binary integer literals as a new prefix to integer literals like 0b or 0B. Another minor update is adding support for a blank (_) as a separator in number literals to improve the readability of complex numbers. Permit signed integers as shift counts: This proposes to change the language spec such that the shift count can be a signed or unsigned integer, or any non-negative constant value that can be represented as an integer. Out of these shortlisted proposals the binary integer literals, separators for number literals, and signed integer shift counts are implemented. The general Unicode identifiers proposal was not implemented as there was no “concrete design document in place in time.“ The proposal to support binary integer literals was significantly expanded, which led to an overhauled and modernized Go’s number literal syntax. Updates in Go 1.14 After the relatively minor updates in Go 1.13, the team has plans to take it up a notch with Go 1.14. With the new major version Go 2, their overarching goal is to provide programmers improved scalability. To achieve this, the team has to tackle the three biggest hurdles: package and version management, better error handling support, and generics. The first hurdle, package and version management will be addressed by the modules feature, which is growing stronger with each release. For the other two, the team has presented draft designs at last year’s GopherCon in Denver. https://youtu.be/6wIP3rO6On8 Proposals planned to be implemented in Go 1.14 Following are the proposals that are shortlisted for Go 1.14: A built-in Go error check function, ‘try’: This proposes a new built-in function named ‘try’ for error handling. It is designed to remove the boilerplate ‘if’ statements typically associated with error handling in Go. Allow embedding overlapping interfaces: This is a backward-compatible proposal to make interface embedding more tolerant. Diagnose ‘string(int)’ conversion in ‘go vet’: This proposes to remove the explicit type conversion string(i) where ‘i’ has an integer type other than ‘rune’. The team is making this backward-incompatible change as it was introduced in the early days of Go and now has become quite confusing to comprehend. Adopt crypto principles: This proposes to implement design principles for cryptographic libraries outlined in the Cryptography Principles document. The team is now seeking community feedback on these proposals. “We are especially interested in fact-based evidence illustrating why a proposal might not work well in practice or problematic aspects we might have missed in the design. Convincing examples in support of a proposal are also very helpful,” the blog post reads. While developers are confident that Go 2 will bring a lot of exciting features and enhancements, not many are a fan of some of the proposed features, for instance, the try function. “I dislike the try implementation, one of Go's strengths for me after working with Scala is the way it promotes error handling to a first class citizen in writing code, this feels like its heading towards pushing it back to an afterthought as tends to be the case with monadic operations,” a developer commented on Hacker News. Some Twitter users also expressed their dislike towards the proposed try function: https://twitter.com/nicolasparada_/status/1144005409755357186 https://twitter.com/dullboy/status/1143934750702362624 These were some of the updates proposed for Go 1.13 and Go 1.14. To know more about this news, check out the Go Blog. Go 1.12 released with support for TLS 1.3, module support among other updates Go 1.12 Release Candidate 1 is here with improved runtime, assembler, ports and more State of Go February 2019 – Golang developments report for this month released