Tech News - Programming

On Wednesday, the team behind Racket released Racket 7.2. Racket is a general-purpose, multi-paradigm programming language based on Scheme and Lisp that emphasizes on functional programming. Racket’s core is built on a lot of C code, 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. Racket on Chez Scheme (Racket CS) implementation has reached the almost complete status with all functionalities in place. Sharing the status of Racket CS, the blog post reads, “DrRacket CS works fully, the main Racket CS distribution can build itself, and 99.95% of the core Racket test suite passes”. Though the code runs fine, still some work needs to be done to ensure end-to-end performance to make Racket CS the default implementation of Racket. The following updates apply to both the implementations of Racket: Contract system:  The contract system, which guards one part of a program from another, now supports collapsible contracts. This will prevent repeated wrappers in certain pathological situations. Quickscript: Quickscript is a tool for DrRacket which allows you to quickly and easily extend DrRacket features. This scripting tool now comes bundled with the standard distribution. Web server configuration: The built-in configuration used for serving static files is updated to recognize the “.mjs” extension for JavaScript modules. The data/enumerate library: The library now supports an additional form of subtraction via but-not/e. The racklog library: A number of improvements are done such as fixing the logic variable binding, logic variables containing predicates being applicable, and the introduction of an %andmap higher-order predicate. Read the official announcement at Racket’s website. Racket v7.0 is out with overhauled internals, updates to DrRacket, TypedRacket among others Pharo 7.0 released with 64-bit support, a new build process and more PayPal replaces Flow with TypeScript as their type checker for every new web app

EuroPython Society (EPS) announced a new grant program yesterday for ‘Python core developers’ in place for the future EuroPython conferences, named “Guido Van Rossum Core Developer Grant”. The program has been named after Guido Van Rossum, Python Chief, in recognition of his dedication towards leading the team for almost 20 years, before he stepped down from his position as the ‘Benevolent dictator for life’ (BDFL), back in July last year. It has been designed to honor the ‘Python core developers’ who work in a small group, and work countless hours (even in free time), often coming close to burnout as not many new core developers join the team. Under the developer grant program, all core Python developers will be awarded a free entry to the future EuroPython conferences, starting with EuroPython 2019 in Basel, Switzerland, that takes place between 9th to 14th July every year. This, in turn, will help grow the team and will give them a place to meet, where they can demonstrate their work and invite new developers. Who are ‘Python Core Developers’? As far as eligibility is concerned, EPS states that developers falling under the term “Python Core Developer” are eligible. Python core developers are those who have been granted the commit rights to the CPython repository. Even if you give up the commit rights or go inactive, you still keep the status of a ‘Python core developer’. EPS has also provided the links to “Github Python core group members”, Python-Dev Guide Log, and Python Dev Guide Experts Index, where you can check your eligibility for the grant program. However, in case you are not listed on one of these but have contributed to the CPython repository, you can provide links to those patches to the Society. Also, EPS mentions that it reserves all the rights to remove the grant eligibility (despite him/her falling under the above-mentioned lists) of a developer in case he/she acts ‘without good faith’ or goes against the EPS Code of Conduct. “We all love Python..(and) believe it is important to give something back to the main team of developers who have contributed lots of their time and energy to make Python happen: the Python Core Developers”, states EPS. For complete information, check out the official Core Developer Grant website. “With Python, you can create self-explanatory, concise, and engaging data visuals, and present insights that impact your business” – Tim Großmann and Mario Döbler [Interview] Python serious about diversity, dumps offensive ‘master’, ‘slave’ terms in its documentation Top 7 Python programming books you need to read

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

This Tuesday, Microsoft announced .NET Core 3 Preview 2 with new features in .NET Core 3 and C# 8. C# 8 The eighth iteration of C# is a major release and includes many new features. Declarations Statements don’t need to be indented now. Switch expressions C# 8 comes with switch expressions in which you can use the new syntax. Terser syntax returns a value as it is an expression. It’s fully integrated with pattern matching. Async streams The compiler and framework libraries should match correctly for async streams to work. You will need .NET Core 3.0 Preview 2 and Visual Studio 2019 Preview 2. Alternatively, you can also use the C# extension for Visual Studio Code. Floating point improvements in IEEE The goal is to expose all operations that are needed and they are behaviorally compliant with the IEEE spec. A fast in-box JSON Writer & JSON document Two new objects were added—System.Text.Json.Utf8JsonWriter and System.Text.Json.JsonDocument. Utf8JsonWriter The Utf8JsonWriter enables a high-performance, non-cached way to write UTF-8 encoded JSON text from common .NET types. JsonDocument System.Text.Json.JsonDocument is also added built on top of the Utf8JsonReader. JsonDocument provides enables parsing JSON data and builds a read-only Document Object Model (DOM). It can be queried to support enumeration and random access. Assembly Unloadability Assembly unloadability is a new ability of AssemblyLoaderContext. It is transparent and exposed with only a few new APIs. A loader context to be unloaded with this. This releases all of the memory for static fields, instantiated types, and the assembly itself. Visual Studio support Using .NET Core 3 for development requires using Visual Studio 2019. WPF and Windows Forms templates were added to the New Project Dialog for easier access via the command line. These were a select few updates from the new .NET Core 3 Preview 2, for a complete list of changes, visit the Microsoft Blog. Microsoft Connect(); 2018: .NET foundation open membership, .NET Core 2.2, .NET Core 3 Preview 1 released, WPF, WinUI, Windows forms open sourced What to expect in ASP.NET Core 3.0 .NET Core 3.0 and .NET Framework 4.8 more details announced

On Monday, the team at Anaconda released a new version of Conda, an open source package management and environment management system that runs on Windows, macOS, and Linux. Conda 4.6.0 comes with support for more shells, better interoperability, improved Conda search and more. https://twitter.com/anacondainc/status/1089970114143965185 What’s new in Conda 4.6.0 Support for more shells Conda 4.6.0 comes with extensive initialization support so that more shells can use the conda activate command. It also comes with added support for PowerShell. This release comes with “conda init” functionality which gets Conda working quickly and less disruptively on a wide variety of shells such as zsh, bash, csh, fish, xonsh, and more. Improving interoperability with pip Conda 4.6.0 comes with added preview support for better interoperability. This release uses pip-installed packages to satisfy dependencies. It is possible to remove pip-installed software and replace them with Conda packages when appropriate.   Note: This feature is disabled by default right now because it can significantly impact Conda’s performance.  If you’d like to try it, you can set this condarc setting: conda config --set pip_interop_enabled True Activation of a single environment This release provides an ideal situation where a single environment can be active at any given time. Conda search gets better License and license_family have been added to MatchSpec for conda search. Enhanced fish shell This release features autocompletion for conda env to the fish shell. Major improvements This release comes with clean output for conda <COMMAND> --help and conda config --describe. In Conda 4.6.0, https://repo.anaconda.com/pkgs/pro has been removed from the default value for defaults. Reference to 'system' channel has been removed from this release. This release comes with http error body to debug information. Creating env name with space is no more supported. This release supports MatchSpec syntax in environment.yml files. With this release, the name of 'condacmd' dir has been changed to 'condabin'. It is now possible to disable timestamp prioritization when not needed. In this release, repodata has been cached as UTF-8 for handling unicode characters. Performance of Conda 4.6.0 has been improved to cache hash value on PackageRecord Major Changes In this release, 'conda env attach' and 'conda env upload' have been removed. This release comes with deprecation warnings for 'conda.cli.activate', 'conda.compat', and 'conda.install'. Env name with colon is now supported. In Conda 4.6.0, the default value of max_shlvl has been changed to 0. Non-user facing changes With OO inheritance, activate.py has been cleaned up. The pep8 project has been renamed to pycodestyle. This release comes with copyright headers. Bug fixes In the previous releases, the verify step of conda used to hang for a long time while installing a corrupted package. This has been fixed. In this release, the progress bar uses stderr instead of stdout. It is now possible to pin a list of packages by adding a file named ‘pinned’ to the conda-meta directory with a list of the packages that the user don’t want to update. To know more about Conda 4.6.0, check out the official announcement. Anaconda 5.3.0 released, takes advantage of Python’s Speed and feature improvements Share projects and environment on Anaconda cloud [Tutorial] Visualizing data in R and Python using Anaconda [Tutorial]  

The developer community surely owes respect to the innovation of ‘View Source’ as it had made things much easier for the coders. Well, David Heinemeier Hansson, the developer of Ruby on Rails have made a move to make programmers’ life easy by announcing that Rails 6 will be shipping source maps by default in production. Source maps help developers view code as it was written by the creator with comments, understandable variable names, and all the other help that makes it possible for programmers to understand the code. It is sent to users over the wire when users have the dev tools open in their browser. Source maps, so far, have been seen merely as a local development tool and not something that will be shipped to production. Live debugging would make things easier for the developers. According to the post by David Heinemeier Hansson, all the JavaScript that runs Basecamp 3 under Webpack now has source maps. David Heinemeier Hansson said, “We’re still looking into what it’ll take to get source maps for the parts that were written for the asset pipeline using Sprockets, but all our Stimulus controllers are compiled and bundled using Webpack, and now they’re easy to read and learn from.” David Heinemeier Hansson is also a partner at the web-based software development firm Basecamp. He said that 90% of all the code that runs Basecamp, is open source in the form of Ruby on Rails, Turbolinks, Stimulus. He further added, “I like to think of Basecamp as a teaching hospital. The care of our users is our first priority, but it’s not the only one. We also take care of the staff running the place, and we try to teach and spread everything we learn. Pledging to protect View Source fits right in with that.” Sam Saffron, the co-founder at Discourse said, “I just wanted to voice my support for bringing this back by @dhh . We have been using source maps at Discourse now for 4 or so years, including maps for both JS and SCSS in production, default on.” According to him one of the important reasons to enable source maps in production is that often JS frameworks have "production" and "development" modes. Sam Saffron said, “I have seen many cases over the years where a particular issue only happens in production and does not happen in development. Being able to debug properly in production is a huge life saver. Source maps are not the panacea as they still have some limitations around local var unmangling and other edge cases, but they are 100 times better than working through obfuscated minified code with magic formatting enabled.” According to Sam, there is one performance concern that is the cost of precompilation. The cost was minimal at Discourse but the cost for a large number of source maps is unpredictable. Users had discussed this issue on the GitHub thread, two years ago. According to most of them the precompile build times will be reduced. A user commented on Github, “well-generated source maps can actually make it very easy to rip off someone else's source.” Another comment reads, “Source maps are super useful for error reporting, as well as for analyzing bundle size from dependencies. Whether one chooses to deploy them or not is their choice, but producing them is useful.” Ruby on Rails 6.0 Beta 1 brings new frameworks, multiple DBs, and parallel testing GitHub addresses technical debt, now runs on Rails 5.2.1 Introducing Web Application Development in Rails

On Saturday, the team at Bison announced the stable release of Bison 3.3, a general-purpose parser generator. Bison 3.3 comes with yyrhs and yyphrs tables, major bug fixes, parsers and much more. What’s new in Bison 3.3 DJGPP support This release comes with support for DJGPP (DJ’s GNU Programming Platform) in Bison, which was unmaintained and untested since a few years. Generation of fix-its for IDEs/Editors Bison 3.3 features a new option called ‘ffixit’ which helps Bison in generating machine-readable editing instructions to fix issues. It helps in updating deprecated directives and removing duplicates. Symbol declaration The symbol declaration syntax was overhauled in previous releases. In Bison 3.3, the symbol ‘%nterm’, is now an officially supported feature. Bison is now relocatable Users can now make Bison relocatable by passing '--enable-relocatable' to ‘configure’. Users can move or copy the relocatable program to a different location on the file system which can also be used through mount points for network sharing. With this release, it is now possible to make symbolic links to the installed and moved programs and invoke them through the symbolic link. Renaming variable names In Bison 3.3, few variables, mostly related to parsers in Java, have been renamed for consistency. Following is a list of such variables:   Abstract -> api.parser.abstract Annotations -> api.parser.annotations Extends -> api.parser.extends Final -> api.parser.final Implements -> api.parser.implements Parser_class_name -> api.parser.class Public -> api.parser.public Strictfp -> api.parser.strictfp %expect and %expect-rr modifiers on individual rules Users can now document and check which rules participate in shift/reduce and reduce/reduce conflicts. Users can use %expect-rr in a rule for reduce/reduce conflicts in GLR parsers. C++ Parsers This release comes with C++ parsers that feature symbol constructors and use noexcept/constexpr. This release also features GLR parsers in C++ that support the syntax_error exceptions. C++ token constructors Variants and token constructors are enabled in this release. In addition to the type-safe named token constructors (make_ID, make_INT, etc.), this release features constructors for symbol_type. C++: Syntax error exceptions in GLR In this version of Bison, the glr.cc skeleton now supports syntax_error exceptions thrown from user actions or from the scanner. More POSIX Yacc compatibility warnings With this release, directives are now reported with -y or -Wyacc.   yyrhs and yyphrs tables Since none of the Bison skeletons used the ‘yyrhs’ and ‘yyphrs’ tables, they were removed in 2008.  But these tables are back again as some users expressed interest in being able to use them in their own skeletons. Deprecated directives The %error-verbose directive is deprecated in favor of '%define parse.error verbose' with warnings issued.The '%name-prefix "xx"' directive is deprecated in favor of '%define api.prefix {xx}' with warnings issued. Deprecated features The new release replaces deprecated features with their modern spelling. The grammar files have been updated. Option -u/--updates results in a cleaner grammar file. Major bug fixes The previous versions of Bison used to report a single RR conflict instead of two. This bug was the oldest one in Bison, it is at least 31 years old, but it has been fixed now. Earlier, passing invalid arguments to %nterm, for instance, character literals, used to result in unclear error messages. This release highlights clear error messages. Users are skeptical about the fact that a bug can live on for so long and gets addressed after years. One of the users commented on HackerNews, “In a thousand years time will archeologists study us through the bugs left behind in Linux 1300.05 and windows (30)95?” Some of the users don’t seem to be happy with the UX of Bison. A comment on HackerNews reads, “A big part of why tools move away from Bison and ANTLR isn’t performance, but UX (especially error reporting).” Others are happy with this news and think that Bison makes parsing easy. One of the comments read, “Congrats though! I love it when these tried-and-true tools continue to perform and improve!” To know more about this Bison 3.3, check out the release notes. GNU Bison 3.2 got rolled out GNU ed 1.15 released! Bash 5.0 is here with new features and improvements

Last week, the team at Google asked the Supreme Court of the United States to review their copyright dispute with Oracle over the use of software interfaces. Unless the Supreme Court interferes, the industry will be stuck by the court’s decision, which states that the software interfaces used in creating new programs are not allowed under copyright law. Software interfaces let computer programs interact with each other and push innovations by letting developers build technologies for different platforms. This is going to have a great impact on innovation across the computer industry. Voices from business, technology, academia, and the nonprofit sector have spoken out about the devastating impacts of this case. The questions raised by Google to the Supreme Court are as follows: Whether copyright protection extends to a software interface? Whether, as the jury found, petitioner’s use of a software interface in the context of creating a new computer program constitutes fair use? Google writes, “We support software developers’ ability to develop the applications we all have come to use every day, and we hope that the Supreme Court will give this case the serious and careful consideration it deserves.”   According to the petition, “the Federal Circuit concluded that the merger doctrine does not restrict copyright protection for computer code necessary for interoperability as long as the original author could have written the code in more than one way.” In 2008, Android was released and it helped developers overcome the challenges of limited memory, smaller processors, and short battery life. Android was built by following the practice of reusing software interfaces which provide sets of commands that make it easy to implement common functionality. Android came with a transformative platform while letting Java programmers use their existing skills to create new applications. The team at Sun Microsystems was happy with the release of Android and said, “It had strapped another set of rockets to the [Java] community’s momentum.” After acquiring Java in 2010, Oracle sued Google for using the software interfaces. Oracle’s lawsuit for the right to control software interfaces might affect the community of developers who have invested in learning the free and open Java language. Initially, a court ruled that the software interfaces, in this case, are not copyrightable, but that decision got overruled. A unanimous jury then pointed out that Google’s use of the interfaces was a legal fair use, but that decision got overruled. According to the official blog post by Google, the U.S. Constitution has authorized copyrights to “promote the progress of science and useful arts,” not to impede creativity or promote lock-in of software platforms. The petition reads, “Under Section 102(b), copyright protection does not extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such [original] work.” Though according to a blog post by Electronic Frontier Foundation, EFF is in the support of Google and will be supporting the company’s petition. Even in May 2013, EFF filed an amicus brief on behalf of many computer scientists to Federal Circuit with the opinion that APIs should not be subject to copyright. This news has become a matter concern for many. In a statement to Ars, James Grimmelmann, a copyright scholar at Cornell University and former software developer, said, "The Federal Circuit's decision threatens the continued vitality of software innovation." It seems even CCIA (Computer and Communications Industry Association) is in support of Google. CCIA writes, "It is hard to see why programmers who have learned the Java APIs should remain captives of Oracle because of an investment in learning made by the programmers and not by Oracle." Users are agitated by this news and they are not welcoming the idea of restricting the use of interfaces. This news has created a lot of buzz in the developer communities and most of the developers are worried. One of the comments on HackerNews reads, “A reminder that what the law says, and what is a good idea, is not necessarily the same thing. The courts rule on the first point. Given that Oracle has prevailed in court on this before, one has to at least entertain the possibility that our law really allows for API to be copyrighted.” Another comment reads, “If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few rent seekers profiting.” Few users are with this new move. A comment reads, “It was not ... intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason.) It was not transformative in the sense of a new platform either, since other Java smartphones predated Android.” Some of the users are with the court and think this battle is about what’s legal and illegal. Another comment reads, “What I'm saying is that all the people who are trying to make the "but it's bad!" argument are missing the point of the courts. Courts are not there to determine whether it's good or bad, only whether it's legal or illegal.” According to some users, Google could have called its resizable array as android.data.ResizableArray<E> but it named it java.util.ArrayList<E> and also copied the method signatures. But the matter of concern for the developers is what if other companies also end up filing such cases. And what if Google is the next one to do so? One of the users commented, “Does anyone believe Google will not be doing the exact same thing with its (moribund) technologies in, say, 5-10 years?” To know more, check out Google’s blog post. Why Google kills its own products Google and Ellen MacArthur Foundation with support from McKinsey & Company talk about the impact of Artificial Intelligence on circular economy Google is secretly urging National Labor Relations Board to overturn protection for activist workers, Bloomberg reports

Last week, Julia 1.1.0 was released with some new features, performance improvements, and small changes in behavior. The following is a list of some of the changes in this new version of Julia: Better exception handling and root cause analysis is now possible due to the exception stack maintained on each task. This can be accessed using the experimental function Base.catch_stack. Binary ~ can now be dotted, as in x .~ y. Previously, parser inputs ending with a comma were sometimes parsed as tuples depending on whitespace. Now, they are consistently treated as incomplete. Spaces in broadcast call syntax, e.g. f. (x).  are now disallowed. Using the same name for both a local variable and a static parameter is an error instead of a warning. When a script that runs in interactive mode (-i) throws an error, the REPL now starts after the error is displayed. This is a change to the REPL that previously only started if the script completed without error. 7zip  has been upgraded from version 16.04 to 18.05, OpenBLAS has been upgraded from 0.3.2 to 0.3.3. Busybox is no longer bundled with Julia on Windows. Support for LLVM < 6.0 has been dropped and LLVM has been upgraded to 6.0.1 Pkg upgraded to version 1.1. one(i::CartesianIndex) should be replaced with oneunit(i::CartesianIndex) The internal array Base.Grisu.DIGITS stands deprecated; to get an appropriate task-local buffer and pass it to grisu(), use Base.Grisu.getbuf().  Base._default_type(T) has been removed. Calls to it should be replaced with just the argument T. You can head over to GitHub for a complete list of the changes in Julia v1.1. Julia for machine learning. Will the new language pick up pace? Introducing Jupytext: Jupyter notebooks as Markdown documents, Julia, Python or R scripts Kata Containers 1.5 released with Firecracker support, integration improvements and IBM Z series support  

Apple announced Swift 5 for their Xcode 10.2 compiler. Swift in Xcode 10.2 beta brings a couple of new features like smaller app sizes when testing, new library, compiler features, and more. The application binary interface (ABI) is stable in Swift 5. Smaller app size App sizes on Swift 5 in Xcode 10.2 beta can be smaller now when deployed for testing. This is true when using TestFlight or when thinning an app for local distribution. Smaller app sizes are possible as Swift apps don’t include dynamically linked libraries for the Swift standard library anymore. Moreover, Swift SDK overlays for devices running iOS 12.2, watchOS 5.2, and tvOS 12.2. Apple calls this concept ‘App thinning’. New features in Swift 5 A new attribute named @dynamicCallable allows dynamic language interoperability. Key paths support the identity keypath \.self. You can no longer write functions that take variadic arguments. Now you can change the enumeration case to ‘take an array explicitly and pass an array in.’ A try? block with an Optional type does not return a nested optional, instead of flattening the resulting option Literal types are modified so that expressions don’t overflow the default integer literal where the type is Int. String interpolation is now simpler, has better performance and efficiency. Changes in the Swift standard library The DictionaryLiteral type is now KeyValuePairs Swift strings bridged into Objective-C code can now return a non-nil value in certain cases The Sequence protocol is now disassociated from SubSequence. Native encoding in the string structure is now UTF-8 instead of UTF-16. What’s new in Swift package manager? When using Swift 5, targets can now declare commonly used build settings that are target-specific. In the Swift 5 Package.swift tools-version, packages can customize minimum deployment target settings. Top level packages can override dependency URLs The --enable-code-coverage flag helps other tools to use code coverage data generated by a tool Support for Swift 3 Package.swift tools-version has been dropped Larger packages are handled better by the package manager Package resolution for incompatible dependency versions are forced to fail A new --repl option in swift run launches the Swift REPL. This supports importing library targets of a package. Swift compiler Exclusive memory access is imposed at runtime by default. Swift 3 is removed. In Swift 5, switches on enumerations declared in Objective-C/system frameworks have to handle unknown cases For Swift modules, default arguments are printed in SourceKit-generated interfaces Support for Optional types is now added in unowned and unowned(unsafe) variables To know more details and bug fixes, visit the release notes. Swift is now available on Fedora 28 ABI stability may finally come in Swift 5.0 Swift 4.2 releases with language, library and package manager updates!

Yesterday, Maël Nison, maintainer at Yarn, opened a GitHub thread on the Yarn repository describing the roadmap for the next major Yarn release. The roadmap (codenamed Berry) contains significant changes that are planned for Yarn's design. Nison reinstates that Yarn’s philosophy will continue to be the same based around three important principles. Developing Javascript projects in Yarn should have totally predictable and reproducible behavior. Developing Javascript projects should be easy. Contributing to the Yarn ecosystem should be simple. Long-term and Short-term goals for Yarn in 2019 Yarn will be rewritten in TypeScript. The entire codebase will be ported from Flow to TypeScript. This is done to help third-party contributors to help to maintain Yarn. Yarn will become a development-first tool. This means Package managers will no longer work as tools for running on your production servers. Yarn will become an API first and CLI second. Its internal components will be split into modular entities Yarn will be designed in a way that each component of Yarn’s pipeline can be switched to adapt to different install targets. Yarn will now be a package manager platform as much as a package manager. Overall compatibility will be preserved when possible. The caveat: installs will now use Plug'n'Play by default. Major changes and new features The lockfile format will become a strict subset of YAML. Yarn will drop support for both Node 4 and Node 6. The log system will be renovated with implementation of diagnostic error codes from Typescript. Some features currently in the core will be moved into contrib plugins. The cache file format will switch from Tar to Zip, which offer better features in terms of random access. Nested workspaces will be supported out of the box. Running Yarn ./packages/my-package add foo will run Yarn add foo into my-package. There will be a new resolution protocol, workspaces:, which allows developers to force the package manager to link one of the packages against a workspace. Yarn constraints is a new command which will allow developers to enforce constraints across workspaces. The Yarn link command will now persist its changes into the package.json files Berry will ship with a portable posix-like light shell that'll be used by default. Scripts will be able to put their arguments anywhere in the command-line (and repeat them if needed) using $@. Cache will become fully atomic, with multiple Yarn instances running concurrently on the same cache without risking corrupting the data. Developers are generally positive about this release specially pointing out the change of moving from Flow to Typescript. A hacker news user states, “Finally one of the biggest news is the switch from Flow to Typescript. I think it's now clear that Facebook is admitting defeat with Flow; it brought a lot of good in the scene but Typescript is a lot more popular and gets overall much better support. Uniting the JS ecosystem around Typescript will be such a big deal.” Another comment reads, “The codebase will be ported from Flow to TypeScript. We hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript.” A new repository will be set up in early February. Post which Berry will be accessible by running yarn policies set-version berry within a project. Hadoop 3.2.0 released with support for node attributes in YARN, Hadoop submarine and more Starting with YARN Basics Introducing ReX.js v1.0.0 a companion library for RegEx written in TypeScript

Today, the Go team announced the release of Go 1.11.5 and Go 1.10.8. This version addresses a recently reported security issue. Go team recommends all users to update to one of these releases. For users who are unsure of which one to choose, the team recommends Go 1.11.5. The DoS vulnerability in the crypto/elliptic implementations of the P-521 and P-384 elliptic curves may let an attacker craft inputs that consume excessive amounts of CPU. These inputs might be delivered via TLS handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private key is reused more than once, the attack can also lead to key recovery. There is an issue in the release tooling due to which go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two unnecessary directories in the root of the archive, "gocache" and "tmp". The team members say that these issues are harmless and safe to remove. They have also mentioned commands that can be used to extract only the necessary “go” directory from the archives. These commands would create a Go tree in /usr/local/go. tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz go tar -C /usr/local -xzf go1.10.8.linux-amd64.tar.gz go To know more about these releases in detail, visit Go’s official mailing thread. Go Programming Control Flow Introduction to Creational Patterns using Go Programming Essential Tools for Go Programming

Yesterday, the team at Gitlab released GitLab 11.7, an application for the DevOps lifecycle that helps the developer teams work together efficiently to secure their code. GitLab 11.7 comes with features like multi-level child epics, API integration with Kubernetes, cross-project pipeline and more. What’s new in GitLab 11.7 Managing releases with GitLab 11.7 This version of GitLab eliminates the need for manual collection of source code, build output, or metadata associated with a released version of the source code. GitLab 11.7 comes with releases in GitLab Core which helps users to have release snapshots that include the source code and related artifacts. Multi-level child epics for work breakdown structures This release comes with multi-level child epics in GitLab portfolio management which allow users to create multi-level work breakdown structures. It also helps in managing complex projects and work plans. This structure builds a direct connection between planning and actionable issues. Users can now have an epic containing both issues and epics. Streamlining JavaScript development with NPM registries This release also delivers NPM registries in GitLab Premium that provides a standard and secure way to share and version control NPM packages across projects. Users can then share a package-naming convention for utilizing libraries in any Node.js project and NPM. Remediating vulnerabilities GitLab 11.7 helps users to remediate vulnerabilities in the apps and suggest a solution for Node.js projects managed with Yarn. Users can download a patch file, and apply it to their repo using the git apply command. They can then push changes back to their repository and the security dashboard will then confirm if the vulnerability is gone. This process is easy and reduces the time required to deploy a solution. API integration with Kubernetes This release comes with API support to Kubernetes integration. All the actions that are available in the GUI currently, such as listing, adding, and deleting a Kubernetes cluster are now accessible with the help of the API. Developers can use this feature to fold in cluster creation as part of their workflow. Cross-project pipeline With this release, it is now possible to expand upstream or downstream cross-project pipelines from the pipeline view. Users can view the pipelines across projects. Search filter box for issue board navigation This release comes with a search filter that makes navigation much easier. Users can simply type a few characters in the search filter box to narrow down to the issue board they are interested in. Project list redesign Project list UI is redesigned in GitLab 11.7 and mainly focuses on readability and summary of the project’s activity. Import issues CSV This release makes transitions easier. Users can now import issues into GitLab while managing their existing work. This feature works with Jira or any other issue tracking system that can generate a CSV export. Support catch-all email mailboxes This release supports sub-addressing and catch-all email mailboxes with a new email format that allows more email servers to be used with GitLab, including Microsoft Exchange and Google Groups. Include CI/CD files from other projects and templates With this release, users can now include their snippets of configuration from other projects and predefined templates. This release also includes snippets for specific jobs, like sast or dependency_scanning, so users can use them instead of copying and pasting the current definition. GitLab Runner 11.7 The team at GitLab also released GitLab Runner 11.7 yesterday. It is an open source project that is used to run CI/CD jobs and send the results back to GitLab. Major improvements In GitLab 11.7, the performance of viewing merge requests has been improved by caching syntax highlighted discussion diffs. Push performance has been improved by skipping pre-commit validations that have passed on other branches. Redundant counts in snippets search have been removed. This release comes with Mattermost 5.6, an open source Slack-alternative that includes interactive message dialogs, new admin tools, Ukrainian language support, etc. Users are generally happy with GitLab 11.7 release. One of the users who has been using GitLab for quite some time now is waiting for MR[0]. They commented on Hacker News, “I'm impatiently waiting for this MR [0] that will allow dependant containers to also talk to each other. It's the last missing piece for my ideal CI setup.” To which, GitLab’s product manager for Verify (CI) replied, “Thanks for bringing this up I hadn't seen your contribution! I think this is a great idea. I know the technical team has been overwhelmed with community contributions as of late - which is a good problem to have but one that we're still solving. I'm going to try and shepherd this one along myself.” Some users think if GitLab can pull off the npm registry well, then this might prove to be the beginning of a universal package management server built into Gitlab. One of the comments reads, “Gitlab API is amazingly simple and flexible, can be used efficiently from the terminal to list CI jobs, your issues, edit them.” Users are also comparing GitLab with GitHub, where some users are supporting GitHub. One user commented, “GitLab’s current homepage hides their actual site (the repositories) and makes it hard as a developer to actually get started compared to Github.” Another user commented, “We've started using Gitlab where I work and it's so much better than GitHub.” Users are also facing issues with memory optimization. One of the comments reads, “I like GitLab but noticed my Docker container running it is steadily requiring more memory to run smoothly. It’s sitting at 12GB right now, which is a little too high for my taste. I wish there were ways to reduce this.” Introducing GitLab Serverless to deploy cloud-agnostic serverless functions and applications GitLab 11.5 released with group security and operations-focused dashboard, control access to GitLab pages GitLab 11.4 is here with merge request reviews and many more features

Today, Microsoft announced the general availability of TypeScript 3.3 RC in a blog post. This version does not contain any major or breaking changes. Better behavior while calling union types When there is a union type A | B, TypeScript now allows users to access all of the properties common to both A and B. For example, the intersection of members. You can get a property from a union type only if it’s known to be present in every union type. When every type has only one signature with identical parameters, things work. Such a restriction was too much and have errors in some areas. So, in TypeScript 3.3, the following code as shown in the blog will work: type Fruit = "apple" | "orange"; type Color = "red" | "orange"; type FruitEater = (fruit: Fruit) => number;     // eats and ranks the fruit type ColorConsumer = (color: Color) => string;  // consumes and describes the colors declare let f: FruitEater | ColorConsumer; f("orange"); // It works! Returns a 'number | string'. f("apple");  // error - Argument of type '"apple"' is not assignable to parameter of type '"orange"'. f("red");    // error - Argument of type '"red"' is not assignable to parameter of type '"orange"'. The parameters of the above signatures are ‘intersected’ to create a new signature. When the impossible intersections are gone, what remains is "orange" & "orange" which is just "orange". That is not to say there are no restrictions. The new behavior is active only when only one type in the union has multiple overloads and a generic signature. The forEach method will now be callable, but there may be some issues under noImplicitAny. The --build mode’s --watch flag leverages incremental file watching as well in TypeScript 3.3. This can result in significantly faster builds with --build --watch. Reportedly, there was over 50% reduced build times. Future of ESLint support in TypeScript Announcing ‘TypeScript Roadmap’ for January 2019- June 2019 Introducing ReX.js v1.0.0 a companion library for RegEx written in TypeScript

The release of Pharo 7.0 was announced in a blog post yesterday. The seventh major release of the object-oriented programming language, Pharo 7.0 is the most important release yet. We look at the major features in Pharo 7.0. Pharo 7.0 comes in 64-bit versions for Linux and OSX. The performance and stability have improved. The 64-bit versions are stable for Linux and OSX. For Windows, the 64-bit version is still in the preview stage. Pharo 7.0 includes the new version of the PharoLauncher. It is a very useful tool to manage distributions you are working with. The new Pharo build comes with a completely new build process that supports its full bootstrap from sources. This new build process will enable the production to some images. The git client for Pharo, Iceberg has also been significantly improved. Iceberg is now the default CMS. Calypso replaces Nautilus as the new system Pharo browser in Pharo 7.0. Calypso brings improved remote working and enhanced browsing capabilities. IoT is now an important part of Pharo. Installing PharoThings provides an impressive amount of tools to develop applications in small devices. The unified foreign function interface (UnifiedFFI) is improved significantly for compatibility with 64-bit Windows. UnifiedFFI is used for interfacing with the outside world in Pharo. The Pharo blog post says: "Pharo 70’s new infrastructure and process set the stage for a new generation of version. The visibility of GitHub combined with the powerful tools that have been validated with more than one year of beta testing is massively pay off.” About 2142 issues have been closed in this release. There were more than 75 people contributing to the success of Pharo 7.0’s main image. These were the highlights of the new features in Pharo, for more details, you can view the release notes. Future of ESLint support in TypeScript Rust 1.32 released with a print debugger and other changes Elixir 1.8 released with new features and infrastructure improvements