Tech News - Languages

Yesterday the team at Clojure released Clojure 1.10, a dynamic, general-purpose programming language. Clojure treats the code as data and has a Lisp macro system. What’s new in Clojure 1.10? Java compatibility and dependencies Java 8 is the minimum requirement for Clojure 1.10. Clojure 1.10 comes with ASM 6.2 and updates javadoc links. Conditional logic has been removed in this release. Added type hint to address reflection ambiguity in JDK 11. spec.alpha dependency has been updated to 0.2.176 core.specs.alpha dependency has been updated to 0.2.44 Error Printing In Clojure 1.10, errors are categorized into various phases such as: :read-source: It is an error thrown while reading characters at the REPL or from a source file. :macro-syntax-check: It is a syntax error found in the syntax of a macro call, either from the spec or from a macro which throws IllegalArgumentException, IllegalStateException, or ExceptionInfo. :macroexpansion: All the errors thrown during macro evaluation are termed as macroexpansion errors. :compile-syntax-check: It is a syntax error caught during compilation. :compilation: It is a non-syntax error which is caught during compilation. :execution: Any error thrown at the execution time is termed as execution error. :read-eval-result: An error thrown while reading the result of execution is categorized as read-eval-result error. :print-eval-result: An error thrown while printing the result of execution is termed as print-eval-result error.Protocol extension by metadata This release comes with a new option, :extend-via-metadata. When :extend-via-metadata is true, values can extend the protocols by adding metadata. The protocol implementations are first checked for direct definitions such as, defrecord, deftype, reify. Further,they are checked for metadata definitions, and then for external extensions such as, extend, extend-type, extend-protocol. Tap Clojure 1.10 comes with tap, a shared and globally accessible system used for distributing a series of informational or diagnostic values to a set of handler functions. It can be used as a better debug prn and for facilities like logging. The function tap> sends a value to the set of taps. The tap function may block (e.g. for streams) and would never impede calls to tap>. Indefinite blocking ly may cause tap values to drop. Read string capture mode This release comes with read+string function that not only mimics read but also captures the string that is read. It returns both the read value and the whitespace-trimmed read string. This function requires a LineNumberingPushbackReader. Prepl (alpha) Prepl, a new stream-based REPL, comes with structured output that is suitable for programmatic use. In prepl, forms are read from the reader and return data maps for the return value (if successful), output to *out* (possibly many), output to *err*(possibly many), or tap> values (possibly many). Other functions in Clojure 1.10 include, io-prepl, a prepl bound to *in* and *out*, which works with the Clojure socket server and remote-prepl, a prepl that can be connected to a remote prepl over a socket Datafy and nav The clojure.datafy function features data transformation for objects. The datafy and nav functions can be used to transform and navigate through object graphs. datafy is still in alpha stage. Major bug fixes ASM regression has been fixed in this release. In the previous release, there were issues with deprecated JDK APIs, which has been fixed. The invalid bytecode generation for static interface method calls have been fixed. Redundant key comparisons have been removed from HashCollisionNode. This release reports correct line number for uncaught ExceptionInfo in clojure.test. Many users have appreciated the efforts taken by the Clojure team for this project. According to most of the users, this release might prove to be a better foundation for developer tooling. Users are happy with the updated debug messages and bug fixes. One user commented on HackerNews, “From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do.”  Though few users still prefer occasional updates instead so that they get better APIs. Rich Hickey, the creator of Clojure language has been appreciated a lot for his efforts even by the non Clojurists. One of the users commented on HackerNews, “Rich's writing, presentations, and example of overall conceptual discipline and maturity have helped me focus on the essentials in ways that I could not overstate. I'm glad (but not surprised) to see so much appreciation for him around here, even among non-Clojurists (like myself).” Though REPLs use the ubiquitous paradigm of stdio streams and are efficient, their major downside is of mingling evaluation output with printing output (the "Print" step). Few users are linking this project with the unrepl and are confused if the design works for the projects. Clojure is stable and it doesn’t have a static type system. Also, users are not happy with the changelog. However, this release has raised a few questions among the developer community. One of the big questions here is if PREPLs would replace remote APIs someday? It would be interesting to see if that really happens with the next set of Clojure releases. Get more information about Clojure 1.10 on Clojure. ClojureCUDA 0.6.0 now supports CUDA 10 Clojure 1.10.0-beta1 is out! Clojure for Domain-specific Languages – Design Concepts with Clojure  

In a GitHub pull request last week, the NumPy community decided to remove support for Python 2.7. Python 3.4 support will also be dropped with this pull request. So now, to use NumPy 1.17 and newer versions, you will need Python 3.5 or later. NumPy has been supporting both Python versions since 2010. This move doesn't come as a surprise with the Python core team itself dropping support for Python 2 in 2020. The NumPy team had mentioned that this move comes in “Python 2 is an increasing burden on our limited resources”. The discussion to drop Python 2 support in NumPy started almost a year ago. Running pip install numpy on Python 2 will still install the last working version. But here on now, it may not contain the latest features as released for Python 3.5 or higher. However, NumPy on Python 2 will still be supported until December 31, 2019. After January 1, 2020, it may not contain the newest bug fixes. The Twitter audience sees this as a welcome move: https://twitter.com/TarasNovak/status/1073262599750459392 https://twitter.com/esc___/status/1073193736178462720 A comment on Hacker News reads: “Let's hope this move helps with the transitioning to Python 3. I'm not a Python programmer myself, but I'm tired of things getting hairy on Linux dependencies written in Python. It almost seems like I always got to have a Python 2 and a Python 3 version of some packages so my system doesn't break.” Another one reads: “I've said it before, I'll say it again. I don't care for everything-is-unicode-by-default. You can take my Python 2 when you pry it from my cold dead hands.” Some researchers who use NumPy and SciPy stick Python 2, this move from the NumPy team will help in getting everyone to work on a single version. One single supported version will sure help with the fragmentation. Often, Python developers find themselves in a situation where they have one version installed and a specific module is available/works properly in another version. Some also argue about stability, that Python 2 has greater stability and x or y feature. But the general sentiment is more supportive of adopting Python 3. Introducing numpywren, a system for linear algebra built on a serverless architecture NumPy 1.15.0 release is out! Implementing matrix operations using SciPy and NumPy  

Yesterday, the Go team released Go 1.11.3 and Go 1.10.6.  The Go team recommends all users to update to one of these releases. If you’re not sure which one to update to, choose Go 1.11.3. These releases have addressed the following security issues: cmd/go: Remote command execution during "go get -u" The go get -u  command downloads, updates, and builds source code and is not supposed to execute arbitrary code. With the help of custom domains, it’s possible to get a Git repository cloned to a folder named .git by using a vanity import path that ends with /.git. If the Git repository root contains a HEAD file, an object directory, a config file, a refsdirectory, then go get -u can be used for considering the parent directory as a repository root, and running Git commands on it. This will help in using the config file in the original Git repository root for its configuration. In case, the config file contains malicious commands, they will execute on the system running go get -u. cmd/go: Directory traversal in "go get" via curly braces in import paths The go get command downloads and builds source code. It is strictly not supposed to allow arbitrary filesystem writes. The go get command becomes vulnerable to remote code execution when it is executed with -u flag or with the import path of a malicious Go package, which contains curly braces (both { and } characters). It is only vulnerable in GOPATH mode and not in module mode. The attacker can create an arbitrary filesystem write, which can further lead to code execution. crypto/x509: CPU denial of service in chain validation Package crypto/x509 parses and also validates X.509 encoded keys and certificates. It should handle certificate chains which are provided by an attacker with reasonable resource use. This package does not limit the work performed for each chain verification and might help attackers to craft pathological inputs, further leading to a CPU denial of service. The Go TLS servers that accept client certificates and the TLS clients that verify certificates get affected. The functionality regression in "go get" when executed in GOPATH mode on an import path pattern containing "..."  is not present in the GOPATH workspace. This issue will be resolved in the next releases, Go 1.11.4 and Go 1.10.7. This update has received a mixed reaction from the users. As few users think that if the Go team should have used context. WithTimeout or even TLSHandshakeTimeout for safety on the old Go. Other users have appreciated the efforts taken by the Go team. https://twitter.com/Olivier_Poitrey/status/1073362114570416128 To know more about this release, check out the official announcement. The Golang team has started working on Go 2 proposals TypeScript 3.2 released with configuration inheritance and more Haskell is moving to GitLab due to issues with Phabricator

Python team released Python versions 3.7.2rc1 and 3.6.9 rc1 yesterday.  Python 3.7.2rc1 is the release preview of the second maintenance release of Python 3.7. Python. 3.6.8rc1 is the release preview of the eighth and last maintenance release of Python 3.6. These latest releases include the addition of new features. Key Updates in Python 3.7.2rc1 A new C API for thread-local storage has been added in Python 3.7.2rc1. A new Thread Specific Storage (TSS) API has been added to CPython which takes over the existing TLS API within the CPython interpreter while removing the existing API. Deterministic .pyc files have been added. These .pyc files are called “hash-based”. Python still uses timestamp-based invalidation by default and does not generate hash-based .pyc files at runtime. Hash-based .pyc files can be generated with py_compile or compileall. Core support added in Python 3.7.2rc1 for typing module and generic types. Customized access to module attributes is allowed, meaning you can now define __getattr__() on modules and can call it whenever a module attribute is not found. Defining __dir__() on modules is also allowed. DeprecationWarning handling has been improved. The insertion-order preservation nature of dict objects has now become an official part of the Python language spec. Key Updates in Python 3.6.8rc1 Preserving Keyword Argument order has been added in Python 3.6.9rc1, meaning that **kwargs in a function signature is now guaranteed to be an insertion-order-preserving mapping. Python 3.6.8rc1 offers simple customization of subclass creation without using a metaclass.The new __init_subclass__ classmethod gets called on the base class when a new subclass is created. A new “secrets” module has been added to the standard library that reliably generates cryptographically strong pseudo-random values suited for managing secrets like account authentication, tokens, etc. A frame evaluation API has been added to CPython that makes frame evaluation pluggable at the C level. This allows debuggers and JITs to intercept frame evaluation before Python code execution begins. Python 3.6.8rc1 offers formatted string literals or f-strings. Formatted string literals work similarly to the format strings accepted by str.format(). They comprise replacement fields that are surrounded by curly braces. The replacement fields are expressions, that are evaluated at run time, and formatted using the format() protocol. For more information, check out the official release notes for Python 3.7.2rc1 and 3.6.8rc1. Python 3.7.1 and Python 3.6.7 released IPython 7.2.0 is out! SatPy 0.10.0, python library for manipulating meteorological remote sensing data, released

Just two days back, Erlang, a functional programming language turned twenty. Erlang has been one of the most popular open source languages with compelling features like concurrent processes, memory management, scheduling, distribution, networking, etc.WhatsApp, the most popular messaging platform’s server is almost completely implemented in Erlang. Twenty years back, on 8th December 1998, Ericsson released its development environment, Erlang/OTP (Open Telecom Platform), as an open source. It was used to make the process of building telecommunications products easier with functionalities like speed, distribution, and concurrency. It also supports a number of processors and operating systems and can be easily integrated with different development languages. Erlang fosters Ericsson’s GPRS, 3, and 4G/LTE and it also powers the internet and mobile data networks. How did Erlang become open source? When Håkan Millroth, head of the Ericsson Software Architecture Lab suggested his team to try ‘open source’, Jane Walerud, an entrepreneur agreed to it and convinced the entire Ericsson management team to release the source code for the Erlang VM. Erlang was released without any publicity, marketing buzz or media coverage. Ericsson just sent an email to Erlang’s mailing list and an announcement was posted on slashdot. During the dot-com bust era, when an extreme growth in the usage and adaptation of the Internet was observed, Erlang/OTP was used in the creation of an XMPP based instant messaging server, ejabberd,developed by Alexey Shchepin. He chose Erlang over all the other languages as it was the most suitable language for implementing a Jabber server. Ejabberd 1.0 was released in December 2005 and it formed a base for many platforms like WhatsApp. Ejabberd showed a 280% increase in throughput when it was compiled to the latest version of Erlang. In May of 2005, a version of the BEAM VM also known as Erlang VM was released that proved the Erlang concurrency and programming models are ideal for multi-core architectures. In May 2006, Erlang was also used to program RabbitMQ, an Advanced Message Queuing Protocol (AMQP). Post that, Erlang has become the language of choice for most of the messaging solutions and is now the backbone of thousands of systems. In 2007, ‘Programming Erlang’ by Joe Armstrong got published by the Pragmatic Programmers. Further in June 2008, the first paper copy of Erlang Programming got publicly available. In 2011, Elixir, a functional and concurrent programming language that runs on Erlang VM was released. In August 2015, Phoenix 1.0, a framework for web applications was released. Phoenix 1.0 uses Erlang VM capabilities to create the same effect as Rails did on Ruby, by bringing making Elixir, popular. Read more about this news on Erlang’s blog post. Elixir 1.7, the programming language for Erlang virtual machine, releases Phoenix 1.4.0 is out with ‘Presence javascript API’, HTTP2 support, and more! Amazon re:Invent Day 3: Lamba Layers, Lambda Runtime API and other exciting announcements!

In a blog post, the state of Rust and WebAssembly for 2018 was discussed by the Rust-Wasm team. The Rust and WebAssembly domain working group worked to make a shared vision into a reality: “Compiling Rust to WebAssembly should be the best choice for fast, reliable code for the Web.” With the evolution of ideas, another core value was formed: “Rust and WebAssembly is here to augment your JavaScript, not replace it.” Goals were set for the joint ecosystem. #1 JavaScript interoperation with zero-cost By leveraging zero-cost abstractions Rust enables fast and expressive code. The Rust team wanted to apply this principle to the whole JS interop infrastructure. Developers can write their own boilerplate to pass DOM nodes to wasm generated by Rust but that shouldn’t be the case. Hence they created wasm-bindgen as the foundation for JavaScript interoperation with zero cost. The communication between JavaScript and WebAssembly is facilitated by wasm-bindgen. This generates glue code which developers would have had to write themselves. With the wasm-bindgen ecosystem helps developers to: Exporting rich APIs from Rust-generated wasm libraries. This makes them callable from JavaScript. Import JavaScript and Web APIs into the Rust-generated wasm. #2 Rust-Generated Wasm as an NPM library Good integration is about fitting Rust-generated WebAssembly into the JavaScript’s distribution mechanisms. A big part of that is NPM. The Rust team built a wasm-pack to creating and publishing NPM packages from Rust and WebAssembly code. Sharing Rust-generated wasm modules is now as simple as: wasm-pack publish #3 To get developers productive fast The Rust team wrote a Rust and WebAssembly book to teach all the ins and outs of WebAssembly development with Rust. It features a tutorial to build an implementation of the Conway's Game of Life and teaches you how to write tests, debugging, and diagnosing slow code paths. Getting a Rust-WebAssembly project set up initially involves a boilerplate and configuration that new users may find difficult or experienced ones may find as a waste of time. Hence the Rust team has created a variety of project templates for different use cases: wasm-pack-template to create NPM libraries with Rust and Wasm. create-wasm-app to create Web applications built on top of Rust-generated wasm NPM libraries. rust-webpack-template to create whole Web applications with Rust, WebAssembly, and the Webpack bundler. rust-parcel-template to create whole Web applications with Rust, WebAssembly, and the Parcel bundler. #4 Rust-Generated Wasm needs to be testable and debuggable wasm can’t log any panics or errors because by default as it doesn’t have any “syscall” or I/O functionality. Imports have to be manually added for that, and then instantiate the module with appropriate functions. To remedy this, and to ensure that panics are always debuggable, the Rust team created the console_error_panic_hook crate. It redirects panic messages into the browser’s devtools console. For more details on the state of the joint ecosytem in 2018, visit the Rust and WebAssembly Blog. Mozilla shares plans to bring desktop applications, games to WebAssembly and make deeper inroads for the future web Red Hat announces full support for Clang/LLVM, Go, and Rust WebAssembly – Trick or Treat?

Yesterday, Rust 1.31.0 and Rust 2018 was announced in the official blog of the programming language. Rust 1.31.0 is the first stable iteration of Rust 2018 and many features in this version are now stable. Rust 2018 Rust 2018 brings all of the work that the Rust team has been doing since 2015 to create a cohesive package. This goes beyond just language features and includes tooling, documentation, domain working groups work, and a new website. Each Rust package can be in either Rust 2015 or Rust 2018 and they work seamlessly together. Projects made in Rust 2018 can use dependencies from 2015, and a 2015 project can use 2018 dependencies. This is done so that the ecosystem doesn't split. The new features are opt-in to preserve compatibility in existing code. Non-lexical lifetimes Non-lexical lifetimes or NLL simply means that the borrow checker is now smarter, and accepts some valid code that was rejected by it previously. Module system changes People new to Rust struggle with its module system. Even if there are simple and consistent rules that define the module system, their consequences can come across as inconsistent, counterintuitive and mysterious. Hence Rust 2018 introduces a few changes to how paths work. These changes ended up simplifying the module system, and now there is better clarity as to what is going on in the module system. More lifetime elision rules Some additional elision rules for impl blocks and function definitions are added. For example: impl<'a> Reader for BufReader<'a> {    // methods go here } This can now be written like this: impl Reader for BufReader<'_> {    // methods go here } Lifetimes still need to be defined in structs. But now no longer require as much boilerplate as before. const fn There are many ways to define a function in Rust. A regular function with fn An unsafe function with unsafe fn An external function with extern fn Rust 1.31 adds a new way to qualify a function: const fn. New tools in Rust 1.31 Tools like Cargo, Rustdoc, and Rustup have been crucial in Rust since version 1.0. In Rust 2018, a new generation of tools are ready for all users— Clippy: Rust's linter. Rustfmt: A tool for formatting Rust code. IDE support: Rust is now supported in popular IDEs like Visual Studio Code, IntelliJ, Atom, Sublime Text 3, Eclipse. Tool lints "tool attributes", like #[rustfmt::skip] were stabilized in Rust 1.30. In Rust 1.31, "tool lints," like #[allow(clippy::bool_comparison)] are being stabilized. These give a namespace to lints making their tool of origin more clear. Other additions Apart from changes in the language itself, there are changes to other areas too. Documentation: "The Rust Programming Language" book has been rewritten. Domain working groups: Four new domain working groups are introduced—network services, command-line applications, WebAssembly, embedded devices. New website: There’s a new iteration of the website for Rust 2018. Library stabilizations: Some From implementations have been added to stabilize libraries. Cargo changes: In Rust 1.31 cargo will download packages in parallel using HTTP/2. Rust Survey 2018 key findings: 80% developers prefer Linux, WebAssembly growth doubles, and more Rust Beta 2018 is here GitHub Octoverse: The top programming languages of 2018

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?

The Haskell functional programming language is moving from Phabricator to GitLab. Last Saturday, Haskell Consultant Ben Gamari listed down some details about the move in a mail. It started with a proposal to move to GitLab A few weeks back, Gamari wrote to the Haskell mailing list about moving the Glasgow Haskell Compiler (GHC) development infrastructure to GitLab. The original proposal wasn’t complete enough to be used but did provide a small test instance to experiment on. The staging URL https://gitlab.staging.haskell.org is ready to use. While this is not the final version of the migration, it does have most of the features a user would expect. Trac tickets are fully imported, including attachments Continuous integration (CI) is available via CircleCI The mirrors of all boot libraries are present Users can also login using their GitHub credentials if they choose to Issues in the migration There are also a few issues listed by Gamari that needs to be worked on: Timestamps associated with ticket open and close events aren't accurate Some of the milestone changes have problems on being imported Currently, CircleCI fails when forked Trac Wiki pages aren’t imported as of now Gamari said that the listed issues have either been resolved in the import tool or are in-progress to be resolved. The goal of this staging instance is to let contributors gain experience using GitLab and identify any obstacles in the eventual migration. Developers need to note that any comments, merge requests, or issues created on the temporary instance may not be preserved. The focus is on identifying workflows that will become harder under GitLab and ways to improve on them, pending issues in importing Trac, and areas that do not have documentation. Why the move to GitLab? The did not choose GitHub as stated by Gamari in another mail: “Its feature set is simply insufficient enough to handle the needs of a larger project like GHC”. The move to GitLab is due to a number of reasons. Phacility, the company that owns Phabricator has now closed support to non paying customers As Phalicity now focuses on paying customers, open-source parts used by GHC seem half finished Phabricator tool Harbormaster causing breaking CI Their surveys indicated developers leaning towards Git rather than the PHP tool Arcanist used by Phabricator The final migration will happen in about two weeks and the date mentioned is December 18. For more details, you can follow the Haskell mailing list. What makes functional programming a viable choice for artificial intelligence projects? GitLab open sources its Web IDE in GitLab 10.7 GitLab raises $100 million, Alphabet backs it to surpass Microsoft’s 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, Google engineer Robert Griesemer published a blog post highlighting the outline of the next steps for Golang towards the Go 2 release. Google developer Russ Cox started the thought process behind Go 2 in his talk at GopherCon 2017. The talk was about the future of Go and pertaining to the changes that were talked about, the talk was informally called Go 2. A major change between the two versions is in the way design and changes are influenced. The first version only involved a small team but the second version will have much more participation from the community. The proposal process started in 2015, the Go core team will now work in the proposals for the second version of the programming language. The current status of Go 2 proposals As of November 2018, there are about 120 open issues on GitHub labeled Go 2 proposal. Most of them revolve around significant language or library changes often not compatible with Go 1. The ideas from the proposals will probably influence the language and libraries of the second version. Now there are millions of Go programmers and a large Go code body that needs to be brought together without an ecosystem split. Hence the changes done need to be less and carefully selected. To do this, the Go core team is implementing a proposal evaluation process for significant potential changes. The proposal evaluation process The purpose of the evaluation process is to collect feedback on a small number of select proposals to make a final decision. This process runs in parallel to a release cycle and has five steps. Proposal selection: The Go core team selects a few Go 2 proposals that seem good to them for acceptance. Proposal feedback: After selecting, the Go team announces the selected proposals and collects feedback from the community. This gives the large community an opportunity to make suggestions or express concerns. Implementation: The proposals are implemented based on the feedback received. The goal is to have significant changes ready to submit on the first day up an upcoming release. Implementation feedback: The Go team and community have a chance to experiment with the new features during the development cycle. This helps in getting further feedback. Final launch decision: The Go team makes the final decision on shipping each change at the end of the three-month development cycle. At this time, there is an opportunity to consider if the change delivers the expected benefits or has created any unexpected costs. When shipped, the changes become a part of the Go language. Proposal selection process and the selected proposals For a proposal to be selected, the minimum criteria are that it should: address an important issue for a large number of users have a minimal impact on other users is drafted with a clear and well-understood solution For trials a select few proposals will be implemented that are backward compatible and hence are less likely to break existing functionality. The proposals are: General Unicode identifiers based on Unicode TR31 which will allow using non-Western alphabets. Adding binary integer literals and support for_ in number literals. Not a very big problem solving change, but this brings Go up to par with other languages in this aspect. Permit signed integers as shift counts. This will clean up the code and get shift expressions better in sync with index expressions and built-in functions like cap and len. The Go team has now started with the proposal evaluation process and now the community can provide feedback. Proposals with clear, positive feedback will be taken ahead as they aim to implement changes by  February 1, 2019. The development cycle is Feb-May 2019 and the chosen features will be implemented as per the outlined process. For more details, you can visit the Go Blog. Golang just celebrated its ninth anniversary GoCity: Turn your Golang program into a 3D city Golang plans to add a core implementation of an internal language server protocol

Yesterday, the Rust Survey team published the results of their annual Rust survey of 2018. This year’s survey was launched in 14 different languages which helped in increasing the number of responses to 5991. The survey highlights that there is a slight increase in medium to large investments in Rust, most of the users prefer Linux over Windows for development, and more. Growth in the number of Rust users Rust is seeing a steady growth in the number of Rust users. Nearly 23% of these users have been using it for 3 months or less and up to a quarter of them are using it for at least 2 years. Talking about how much time it takes to get productive in Rust, 40% of Rust users said it takes less than a month of use, and over 70% felt productive in their first year of use itself. Over 22% of the Rust users do not feel productive, out of which only about 25% are in their first month of use. Larger overall investments in Rust projects Rust projects are seeing larger overall investments and trending to larger sizes. The percentage of medium to large investments in Rust has increased from 8.9% in 2016, to 16% in 2017, to 23% this year. There is also some growth in the Rust daily usage from 17.5% last year to nearly a quarter of users this year. In total, Rust weekly total usage has risen from 60.8% to 66.4%. Difficulty level of common Rust concepts Most of the Rust users consider themselves to be intermediates in terms of expertise in Rust. The users felt that Enums and Cargo are the easiest concepts to learn, followed by Iterators, Modules, and Traits, Trait Bounds, and Unsafe. The most difficult concepts are Macros, Ownership & Borrowing, and Lifetimes. Usage Patterns of Rust tools Same as last year, users are preferring the current stable release of Rust. There is a slight increase in the number of the Nightly compiler users, which is now over 56% (up from 51.6% of last year). Users are opting Nightly for accessing 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm. The percentage of users who see a breakage during a routine compiler update remains the same as last year (7.4%). These breakages generally required minor fixes, though some reported having moderate or major fixes to upgrade to the next stable compiler. 90% of the users voted rustup as their first choice for installing Rust. Linux distros is the second option with only 17% of Rust installs. Tools like rustfmt and rustdoc got lots of positive support, following these is the clippy tool. The IDE support tools Rust Language Server and racer also had positive support but unfortunately, of the tools surveyed, generated a few more dislike votes and comments. The bindgen tool has relatively small userbase. Preferred development platforms of Rust users While there is some increase in Windows usage from 31% last year to 34% this year, Linux platform continues to be popular among Rust developers with 80% of users opting it. While there is not much change from the last year for other target platforms, WebAssembly is an exception. It has shown nearly doubled up growth from last year’s 13% to this year’s 24%. In editors, VSCode has bested Vim, the front-runner in editors for two years, which grew from 33.8% of Rust developers to 44.4% this year. Increase in commercial use of Rust Rust’s part-time usage at the workplace has increased from 16.6% to 21.2%. Its full-time commercial has doubled from 4.4% to 8.9%. In total, its commercial use has grown from 21% to just over 30% of Rust users. Though there is an increase in the commercial use, over a third of Rust users aren’t sure their companies will invest in Rust. To know more in detail, read the annual Rust Survey 2018. Rust Beta 2018 is here 3 ways to break your Rust code into modules Red Hat announces full support for Clang/LLVM, Go, and Rust

An announcement post yesterday said that Rust 2018 beta is now in the final phase before release. A new beta has just been released with updates. After bug fixes, the final release will take place on December 6. In comparison to the Rust 2018 Edition Preview 2, the new Rust 1.31.0 beta includes all of the features stabilized in v1.31.0 207 and many bug fixes. Those new features are as follows. Changes in Rust Beta The new lifetime elision rules now allow eliding lifetimes in functions and impl headers. Lifetimes are still needed to be defined in structs. const functions can now be defined and used. These const functions right now are a strict minimal subset of the const fn RFC. Tool lints can now be used, which allow scoping lints from external tools by using attributes. With this release, the #[no_mangle] and #[export_name] attributes can be located anywhere in a crate. Previously they could only be located in exported functions. Parentheses can now be used in pattern matches. The compiler change includes updating musl to 1.1.20. There are some library changes and API stabilizations. Now, cargo will download crates in parallel using HTTP/2 protocol. The packages in Cargo.toml can also be renamed now. You can know more about these changes on GitHub. Changes in tooling Rust Beta 2018 also includes a number of improvements in the area of tooling. Rustfmt is now at version 1.0. RLS and Clippy will no longer be installed via “preview” components after a rustup update. The developers have listed two focus areas to find the bugs, namely the module system implementation and the RLS. Work for next release In Rust Preview 2, two variants for the module system were evaluated—“anchored paths” vs “uniform paths”. This evaluation continues in this beta release. This means that the compiler accepts only code that both variants would accept. You can read the announcement post for more details. Rust 2018 RC1 now released with Raw identifiers, better path clarity, and other changes GitHub Octoverse: The top programming languages of 2018 Red Hat announces full support for Clang/LLVM, Go, and Rust

Last week, Google brought the popular coding competitions Code Jam, HashCode and Kick Start together on a single website. This brand new UI will make the navigation better to make it user friendly. The user profile will now show notifications which will make the user experience better. Code Jam Google’s global coding competition, Code Jam, gives an opportunity to programmers around the world to solve tricky algorithmic puzzles. The first round includes three sub rounds. Next, the top 1,500 participants from each sub-round then get a chance to compete for a spot in round 2. Top 1,000 contestants are chosen out of them and they get an opportunity to move to the third round. Top 25 contestants will get selected from the third round and they will compete for the finals. The winners get the championship title and $15,000. HashCode HashCode is a team-based programming challenge organized by Google for students and professionals around the world. After registering for the contest, the participants will get an access to the Judge System. The Judge System is an online platform where one can form the team, join a hub, practice, and compete during the rounds. One can choose their team and programming language and the HashCode team assigns an engineering problem to the teams by live streaming on Youtube. The teams can compete either from a local hub or any another location of their choice. The selected teams will compete for the final round at Google’s office. Kick Start Kick Start, also a global online coding competition, consists of a variety of algorithmic challenges designed by Google engineers. Participants can either participate in one of the online rounds or in all of them. The top participants will get a chance to be interviewed at Google. The best part about KickStart is that it is open to all participants and there is no pre-qualification needed. If you are competing in a coding competition for the first time, then KickStart is the best option. What can you expect with this unified interface? Some good competition and some amazing insights coming from each of the rounds. Personalized certificate of completion. A chance to practice coding and experience new challenges A lot of opportunities To stay updated with the registration dates and details, one can sign up on Google’s coding competition’s official page. To know more about the competitions, check out Google’s blog. Google hints shutting down Google News over EU’s implementation of Article 11 or the “link tax” Recode Decode #GoogleWalkout interview shows why data and evidence don’t always lead to right decisions in even the world’s most data-driven company Google Dart 2.1 released with improved performance and usability

Yesterday, the JetBrains community announced IntelliJ IDEA 2018.3, this year’s third major update. The IntelliJ IDEA 2018.3 is a massive new update that delivers Java 12 support, Multiline TODO comments, GitHub Pull Requests, Git submodules, Accessibility improvements, and more. Major updates in the IntelliJ IDEA 2018.3 Java Updates Support for Java 12: The 2018.3 version adds an initial support for the upcoming Java 12. Users can preview the Raw String Literals (JEP 326) in the IDE. Quickly spot duplicates: Users can now quickly spot duplicates in more complicated cases using this IDE. Java Stream API improvements: Redundant sorted calls made before the subsequent min call are now easily detected. New data-flow-based inspection: The new inspection known as ‘Condition is covered by further condition’ detects situations where the first condition is unnecessary as it’s covered by the second one. The new IDE provides a quick-fix to remove such redundant conditions. Detection of redundant usages of the @SuppressWarning annotation: The IDE now identifies situations where a suppressed inspection no longer addresses any warnings in the associated method body, class, or statement. Editor Updates Issues in code are highlighted: The IDE highlights the first and all subsequent TODO comment lines in the editor and displays them in the TODO tool window. New indentation status bar: A new indentation status bar displays the size of the indent in the current file. Improvements in the EditorConfig support: You can create a scope to disable code formatting from being done on specific files and folders. Go to the ‘Formatter Control’ tab in Preferences / Settings | Editor | Code Style. Syntax highlighting and code completion are now available for EditorConfig files. Version Control Updates Initial support for GitHub Pull Requests:  With this users can now view PRs in their IDE. Support for Git submodules: update your project, commit changes, view diffs, and resolve conflicts. New GitHub Pull Requests tool window: With this tool window, users can preview all the pull requests in your GitHub repository. Advanced navigation in VCS Log: Users can use the Forward and Back navigation actions while they are in the VCS Log after they navigate from the commit hashes to the commit in the VCS Log tab, or after they use the Go to hash/branch/tag action. Simply use the left and right arrow keys to navigate to the child or parent commit. Preview differences in the File History tab: Diff Preview is now available in the File History tab of the Version Control tool window. Kotlin Updates Kotlin 1.3 support: IntelliJ IDEA can help you migrate Kotlin project to Kotlin 1.3 and perform all the required changes in obsolete code to make it compliant with the latest state of the libraries. Enhancements in multiplatform project support: In Kotlin 1.3, the model of multiplatform projects has been completely reworked in order to improve expressiveness and flexibility, and to make sharing common code easier. IntelliJ IDEA provides a set of project examples that cover the most common use cases. New Kotlin Inspections & Quick-fixes: Since the release of IntelliJ IDEA 2018.2, the Kotlin plugin has got over 30 new inspections, quick-fixes, and intentions that helps write a code much more effectively. Spring & Spring Boot Updates Spring Boot 2.1 support: IntelliJ IDEA 2018.3 fully supports Spring Boot 2.1. Configuration values annotated with @DataSize are validated using the default @DataSizeUnit if specified. Spring Initializr improvements: While creating a project using Spring Initializr, the IDE will suggest installing or enabling appropriate plugins to ensure that support for all selected technologies is present. Better JPA and Spring Data support for Kotlin: Now the IDE can automatically inject JPQL into query strings, providing completion for entity names and parameters. Users can write Spring Data interfaces in Kotlin, and IntelliJ IDEA will understand the entities used. The IDE provides smart completion for method names and quick-fixes for parameters. Maven Updates Users can now easily delegate all their build and run actions to Maven. They simply have to go to Preferences (Settings) | Build, Execution, Deployment | Build Tools | Maven | Runner and select the new Delegate IDE build/run actions to maven option. JVM Debugger Updates Attach to Java processes that were started without a debug agent:  After attaching to a process, users will be able to view the current thread’s state and variable values, and use the memory view. If users want to attach the debugger to their local process, they can use the handy new Attach Debugger action, which is available in the Run Tool Window Async stack traces in remote JVMs: IntelliJ IDEA 2018.3 now supports async stack traces in remote JVMs. To start using the agent remotely: copy /lib/rt/debugger-agent.jar to the remote machine. add -javaagent:debugger-agent.jar to the remote JVM options. Action to remove all breakpoints: IntelliJ IDEA 2018.3 comes with handy new actions that remove all the breakpoints in a project, or all the breakpoints in the file. JavaScript & TypeScript Updates Improved Angular support: This includes much more accurate code completion and Go to definition for variables, pipes and async pipes, and template reference variables. Autoimports in JavaScript: IntelliJ IDEA can now automatically add imports for symbols from the project’s dependencies, in JavaScript files. This works as long as there’s a TypeScript definition file inside the package, or the package contains sources written as ES module. Support for Node.js worker threads: Users can now debug Node.js workers in IntelliJ IDEA. Users should be cautious of using Node.js 10.12 or above and the experimental-worker flag. The IDE provides code completion for the worker threads’ API. Improved flexibility with ESLint and TSLint: Users can override severity levels from the linter’s configuration file and see all problems from the linter as errors or warnings. Kubernetes Update Support for Helm resource files: The IDE now resolves the Helm resource template files and provides with editing support, which includes code completion, rename refactoring, and inspections and quick-fixes. Navigation in Helm resource files: The IDE lets users navigate from a value’s usage to its declaration in the chart’s values.yaml file. Helm template result preview: The IDE can now preview the result of the Helm template rendering in the diff. Helm dependency update: A new Helm Dependency Update action is available to download the external tgz dependencies (or update the existing ones) and display them in the project tree. Database Updates Added support for Cassandra database: With this release, the team has added support for the NoSQL database, Cassandra. Improvements in SQL code completion: Now code completion works for: non-aggregated fields in GROUP BY, all the columns are listed in SELECT, MERGE, and INSERT INTO table variable, named parameters of stored procedures, numeric fields in SUM() and AVG(), FILTER (WHERE) clause, and field types in SQLite. Introduction to table alias: One can now use the Introduce table alias action to create an alias directly on the table, and this alias will automatically replace usages of the table’s name. Single connection mode: In IntelliJ IDEA 2018.3 users can view any temporary objects in the database tree. Also, it’s possible to use the same transaction in different consoles. To know more about these and other updates in detail, visit the JetBrains blog. IntelliJ IDEA 2018.3 Early Access Program is now open! What’s new in IntelliJ IDEA 2018.2 How to set up the Scala Plugin in IntelliJ IDE [Tutorial]