Tech News - Languages

Today, Daniel Rosenwasser, the Program Manager of TypeScript, released a roadmap to be followed for TypeScript starting from January 2019 to June 2019. This roadmap outlines the priorities that the team will be focussing on, over the next 6 months, which will serve as a set of guidelines to accomplish the listed goals by June 2019. These goals (as listed on GitHub) include: Types on every desk, for every JS developer Using strong tooling to increase productivity Improved Approachability and UX More Community engagement Better Infrastructure and engineering systems In order to achieve these goals, the Typescript team will focus on tweaking the following domains: #1 Language design and innovation Under this domain, the team will focus on the core ‘type’ system. They plan to enable popular JS patterns in a type-safe way, while also proving relationships between types. The latter simply means generalizing patterns between type operators and encoding them in type relationships. They also plan to implement ECMAScript features with stricter settings. In terms of Committee representation, their goals include prioritizing forward compatibility with proposals/features adopted in the earlier stages of developing TS. They also want to be involved in other features like Class fields (public and private), decorators, ES/CJS module interop, and much more to ensure that ECMAScript grows to ‘make a developers' life easier’. #2 Developer productivity tools and integration The team plans to introduce ‘quick fixes’ that will be proactive in nature. This includes a class of code modifications and fixes that are applicable, which will be useful for teaching users about language features and patterns, making it more approachable to work with TypeScript/JavaScript. Proactive fixes also imply that TypeScript can analyze code and can surface suggestions and code changes for improvements rather than just fix an error. This is in contrary to most of the current quick fixes that are reactive in nature and are created and triggered after a user has seen a definite error. They also plan on focussing on more targeted workflows like ‘migration’. They will come up with ways to ease migration to TypeScript and typed JavaScript to improve the process of adding types. In the field of ‘Linting’, the team noticed architectural issues with the way TSLint rules operate that impacted performance. They will be working towards fixing these issues. Since ESLint already has the more-performant architecture, the TS team will be focusing on leveraging ESLint rather than duplicating work. For scenarios that ESLint currently doesn't cover, they will be sending contributions to bring ESLint's TypeScript support to parity with TSLint. To build co-located TypeScript projects, the team will be making improvements such as functionality for automatically swapping projects in and out to save memory. They will also investigate the emit-time regressions seen in the last few versions of TS. Finally, they plan to investigate surfacing language service operations on the command line. #3 Education and UX The team says that the documentation provided for TypeScript needs to be improved for a more seamless learning experience. They will be working on a new version of the handbook with  three different parts: Tailored introductions for the core handbook The core handbook for everyone Reference pages (eg. appendices) They believe the segmentation of this documentation will help developers from all backgrounds--right from complete novices to experienced developers--to learn TypeScript without any hassle. They will also be improving their error UX to make it more ‘approachable’ for inexperienced users. Their website will also be undergoing an upgrade along with the examples mentioned on the same. #4 Community investment TypeScript's 'DefinitelyTyped' is the 10th most popular open source project on GitHub. The team will be focussing on weekly PR rotations--where members of the TS team review external PRs to DefinitelyTyped--and DefinitelyTyped's surrounding infrastructure such as the types publisher, dtslint, and dt-mergebot. They also plan to ease the process of external contributions to the documentation and investigate improving rich editing experiences. This year, users can also expect more public talks, meetups and blog posts on TypeScript. #5 Team Infrastructure The team will be focussing on faster builds by converting them to avoid bootstrapping themselves outside of CI, adding/migrating lint rules, and much more. This will, in turn, improve TS stability, productivity, and ease of contribution. Besides this, they also plan on providing internal guidance on TypeScript-first API designs, assisting internal partner teams with best practices for projects and addressing major Microsoft-internal build regressions. You can head over to TypeScript’s GitHub page for more insights on this announcement. npm JavaScript predictions for 2019: React, GraphQL, and TypeScript are three technologies to learn TypeScript 3.2 released with configuration inheritance and more Vue.js 3.0 is ditching JavaScript for TypeScript. What else is new?    

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

Yesterday, Oracle announced the general availability of Java SE 13 (JDK 13) and that its binaries are expected to be available for download today. In addition to improved performance, stability, and security, this release comes with two preview features, switch expressions and text blocks. This announcement coincides with the commencement of Oracle’s co-located OpenWorld and Code One conferences happening from September 16-17 2019 at San Francisco. Oracle’s director of Java SE Product Management, Sharat Chander, wrote in the announcement, “Oracle offers Java 13 for enterprises and developers. JDK 13 will receive a minimum of two updates, per the Oracle CPU schedule, before being followed by Oracle JDK 14, which is due out in March 2020, with early access builds already available.” This release is licensed under the GNU General Public License v2 with the Classpath Exception (GPLv2+CPE). For those who are using Oracle JDK release as part of an Oracle product or service, it is available under a commercial license. Read also: Oracle releases open-source and commercial licenses for Java 11 and later What’s new in JDK 13 JDK 13 includes the implementation of the following Java Enhancement Proposals (JEPs): Dynamic class-data sharing archives (JEP 350) JEP 350 improves the usability of application class-data sharing to allow the dynamic archiving of classes once the execution of a Java application is completed. The archived classes will consist of all loaded application classes and library classes that are not present in the default, base-layer CDS archive. Uncommit unused memory (JEP 351) Previously, the z garbage collector did not uncommit and returned memory to the operating system, even if it was left unused for a long time. With JEP 351 implemented in JDK 13, the z garbage collector will return unused heap memory to the operating system. Read also: Getting started with Z Garbage Collector (ZGC) in Java 11 [Tutorial] Reimplement the Legacy Socket API (JEP 353) In JDK 13, the underlying implementation used by the ‘java.net.Socket’ and ‘java.net.ServerSocket APIs’ is replaced by “a simpler and more modern implementation that is easy to maintain and debug,” as per JEP 353. This new implementation aims to make adapting to user-mode threads or fibers, that is currently being explored in Project Loom, much easier. Switch expressions preview (JEP 354) The switch expressions feature proposed in JEP 354 allows using ‘switch’ as both a statement or an expression. Developers will now be able to use both the traditional ‘case ... : labels’ (with fall through) or new ‘case ... -> labels’ (with no fall through). This preview feature in JDK 13 aims to simplify everyday coding and prepare the way for the use of pattern matching (JEP 305) in a switch. Text blocks preview (JEP 355) The text blocks preview feature proposed in JEP 355 makes it easy to express strings that take up several source code lines. This preview feature aims to improve both “the readability and the writeability of a broad class of Java programs to have a linguistic mechanism for denoting strings more literally than a string literal.” Check out the official announcement by Oracle to know what else has landed in JDK 13. Other news in programming Microsoft introduces Static TypeScript, as an alternative to embedded interpreters, for programming MCU-based devices Golang 1.13 module mirror, index, and Checksum database are now production-ready Why Perl 6 is considering a name change?

Yesterday, the Eclipse Foundation announced the release of the Jakarta EE 8 full platform, web profile specifications, and related Technology Compatibility Kits (TCKs). This marks the completion of Java EE’s transition to an open and vendor-neutral evolution process. Explaining the vision behind this release, Mike Milinkovich, executive director of the Eclipse Foundation said, “There are tens of thousands of companies with strategic investments in Java EE and over 10 million Java developers globally. The finalization of the Jakarta EE 8 specifications means that the transition of Java EE to our new open, vendor-neutral, and community-based process has been completed, and paves the way for an entirely new era in Java innovation for enterprise and cloud workloads.” Back in 1999, Sun Microsystems developed Java EE under the name Java 2 Enterprise Edition (J2EE), which was rebranded as Java Platform, Enterprise Edition (Java EE) in 2006. When in 2010 Oracle acquired Sun Microsystems, Java EE’s governance and oversight also moved to Oracle. The development of Java EE’s technical specifications was managed under the Java Community Process (JCP), which was tightly vendor-led effort. In order to make Java EE more open, Oracle made the Eclipse Foundation the new steward of enterprise Java. Read also: Eclipse foundation releases updates on its Jakarta EE Rights to Java trademarks Updates in Jakarta EE 8 Jakarta EE 8 has shipped with the same set of technical specifications as Java EE 8, which means developers are not required to make any changes to their Java EE 8 applications or their use of existing APIs. In this release, the team has focused on updating the process used to determine new specs for Jakarta EE that will replace JCP. This new process is called the Jakarta EE Specification Process (JESP), which will be used by the Jakarta EE Working Group for further development of Jakarta EE. It is based on the Eclipse Foundation Specification Process (EFSP) with a few changes. Rhuan Rocha, a Java EE developer, wrote in the announcement, “The goals of JESP is being a process as lightweight as possible, with a design closer to open source development and with code-first development in mind. With this, this process promotes a new culture that focuses on experimentation to evolve these specification based on experiences gained with experimentation.” A key change in this process is that there is no Spec Lead now who had special intellectual property rights under the JCP. In an interview with JAXenter, Milinkovich explained how this process differs from JCP, “The Jakarta EE Specification Process is a level playing field in which all parties are equal, and collaboration is a must. Some of the other significant differences include a code-first approach, rather than a focus on specifications as the starting point. You can also expect a more fully open, collaborative approach to generating specifications, with every decision made collectively by the community.” Along with the release of Jakarta EE 8 specifications, the Eclipse Foundation also announced the certification of Eclipse GlassFish 5.1 as an open-source compatible implementation of the Jakarta EE 8 Platform. To know more in detail, check out the official announcement by the Eclipse Foundation. Other news in programming Is Scala 3.0 a new language altogether? Martin Odersky, its designer, says “yes and no” Core Python team confirms sunsetting Python 2 on January 1, 2020 Go 1.13 releases with error wrapping, TLS 1.3 enabled by default, improved number literals, and more

Yesterday, the Rust team announced the release of Rust 1.34. This release introduces alternative cargo registries, includes support for ‘?’ operator in documentation tests, stabilized TryFrom and TryInto, and more. Support for alternative cargo registries Rust provides a public crate registry called crates.io where developers can publish crates with the cargo publish command. However, as this crate registry is not for people maintaining proprietary code, they are forced to use git or path dependencies. This release brings support for alternate cargo registries, which coexists with crates.io. So, users will now be able to write software that depends on crates from both crates.io and their custom registry. Support for the ‘?’ operator in documentation tests It was proposed in RFC 1937 to add support for the ‘?’ operator in the main() function, #[test] functions, and doctests allowing them to return Option or Result with error values.  This ensured a non-zero exit code in the case of the main() function and a test failure in the case of the tests. Support for the main() and #[test] functions were already implemented in previous versions. However, in the case of documentation tests, support for ‘?’ was limited to doctests that have an explicit main() function. In this release, the team has implemented full support for ‘?’ operator in doctests. Stabilized TryFrom and TryInto The TryFrom and TryInto traits that were proposed in an RFC back in 2016 are finally stabilized in this release to allow fallible type conversions. A ‘Infallible’ type is added for conversions that cannot fail such as u8 to u32. In future versions, the team plans to convert Infallible to an alias for the (!) never type. Library stabilizations This release comes with an expanded set of stable atomic integer types with signed and unsigned variants from 8 to 64 bits available. In the previous versions, non-zero unsigned integer types, for example, NonZeroU8 were stabilized. With this release, signed versions are also stabilized. The ‘iter::from_fn’ and ‘iter::successors’ functions are also stabilized. To know more about the updates in Rust 1.34, check out its official announcement. Chris Dickinson on how to implement Git in Rust The npm engineering team shares why Rust was the best choice for addressing CPU-bound bottlenecks Rust 1.33.0 released with improvements to Const fn, pinning, and more!  

Yesterday, reports from The Register confirmed that the Javascript Package registry NMP Inc. and the 3 former employees who were fired, agreed on a settlement.  NPM which stands for Node Package Manager, is the company behind the widely used NPM JavaScript package repository. In March, the company laid off 5 employees in a unprofessional and unethical manner. In April, 3 out of 5 former staffers – Graham Carlson, Audrey Eschright, and Frédéric Harper – had formally accused NPM Inc of union busting in a complaint to the US National Labor Relations Board. https://twitter.com/bram_parsons/status/1146230097617178625 The deal was settled after the third round of negotiations between the two parties as per The Register. The filing posted on the NLRB website, administrative law judge Gerald Etchingham said he had received a letter from one of the attorneys involved in the dispute that both sides had agreed to settle. The terms of the deal were not disclosed but as per the NLRB settlements, such cases usually involve a pay back, job restoration or additional compensation. However, it is highly unlikely that none of the former employees will agree for job restore and will not return to npm. Other than this, NPM Inc is also required to share a letter with current employees accepting the ways in which it violated the laws. But there are no reports of this action yet from Npm inc. https://twitter.com/techworkersco/status/1146255087968239616 Audrey Eschright, one of the plaintiffs  complained on Twitter about the company's behaviour and former rejections to settle on claims. "I'm amazed that NPM has rejected their latest opportunity to settle the NLRB charges and wants to take it to court," she wrote. "Doing so continues the retaliation I and my fellow claimants experienced. We're giving up our own time, making rushed travel plans, and putting in a lot of effort because we believe our rights as workers are that important." According to Eschright, NPM Inc refused to settle because the CEO has taken the legal challenge personally. "Twice their lawyers have spent hours to negotiate an agreement with the NLRB, only to withdraw their offer," she elaborated on Twitter. "The only reason we've heard has been about Bryan Bogensberger's hurt feelings." The Register also mentioned that last week NPM Inc had tried to push back a hearing to be held on 8th July citing the reason that management was traveling for extensive fund raising. But NLRB denied the request and said that the reason is not justified.  NLRB also mentioned that NPM Inc "ignores the seriousness of these cases, which involve three nip-in-the-bud terminations at the onset of an organizing drive." It is indeed true that NPM Inc ignores the seriousness of this case but also oversees the fact that npm registry coordinates the distribution of hundreds of thousands of modules used by some 11 million JavaScript developers around the world. The management of NPM Inc is making irrational decisions and behaving notoriously, due to which the code for the npm command-line interface (CLI) suffers from neglect, unfixed bugs piling up and pull requests languishing.  https://twitter.com/npmstatus/status/1146055266057646080 On Monday, there were reports of Npm 6.9.1 bug which was caused due to .git folder present in the published tarball. The Community architect at the time, Kat Marchán had to release npm 6.9.2 to fix the issue. Shortly after, Marchán, who was a CLI and Community Architect at npm has also quit the company. Marchán made this announcement yesterday on Twitter, adding that she is no longer a maintainer on npm CLI or its components.  https://twitter.com/maybekatz/status/1146208849206005760 Another ex-npm employee noted on Marchán’s resignation, that every modern web framework depends on npm, and npm is inseparable from Kat’s passionate brilliance. https://twitter.com/cowperthwait/status/1146209348135161856 NPM Inc. now not only needs to fix bugs but majorly it also needs to fix its relationship and reputation among the Javascript community. Update on 20th September - NPM Inc. CEO resigns Reports from news sources came about NPM CEO, Bryan Bogensberger to resign effective immediately in order to pursue new opportunities. NPM's Board of directors have commenced a search for a new CEO. The company's leadership will be managed collaboratively by a team comprised of senior npm executives. "I am proud of the complete transformation we have been able to make in such a short period of time," said Bogensberger. "I wish this completely revamped, passionate team monumental success in the years to come!" Before joining npm, Inc., Bogensberger spent three years as CEO and co-founder of Inktank, a leading provider of scale-out, open source storage systems that was acquired by Red Hat, Inc. for $175 million in 2014. He also has served as vice president of business strategy at DreamHost, vice president of marketing at Joyent, and CEO and co-founder of Reasonablysmart, which Joyent acquired in 2009. To know more, check out PR Newswire website. Is the Npm 6.9.1 bug a symptom of the organization’s cultural problems? Surprise NPM layoffs raise questions about the company culture  

RacketCon 2019 happened last month from July 13 to 14 bringing together the Racket community to discuss ideas and future plans for the Racket programming language. Matthew Flatt, one of the core developers, graced the stage to give his talk: State of Racket. In his talk, he spoke about the growing community, performance improvements, and much more. He also touched upon his recommendation to change the surface syntax of Racket2, which has sparked a lot of discussion in the Racket community. https://www.youtube.com/watch?v=dnz6y5U0tFs&t=390 Later in July, Greg Hendershott, who has contributed Racket projects like Rackjure and Travis-Racket and has driven a lot of community participation, expressed his concern about this change in a blog post. “I’m concerned the change won’t help grow the community; instead hurt it,“ he added. He further shared that he will shift his focus towards working on other programming languages, which implies that he is stepping down as a Racket contributor. Matthew Flatt recommends surface syntax change for removing technical barriers to entry There is no official proposal about this change yet, but Flatt has discussed it a couple of times. According to Flatt’s recommendation, Racket 2’s ‘lispy’ s-expressions should be changed to something which is not a barrier of entry to new users. He suggests to get rid or reduce the use of parentheses and bring infix operators, which means the operator sign will be written in between the operands, for instance, a + b.  “More significantly, parentheses are certainly an obstacle for some potential users of Racket. Given the fact of that obstacle, it's my opinion that we should try to remove or reduce the obstacle,“ Flatt writes in a mailing list. Racket is a general-purpose, multi-paradigm programming language based on the Scheme dialect of Lisp. It is also an ecosystem for language-oriented programming. Flatt further explained his rationale behind suggesting this change that the current syntax is not only a hindrance to potential users of Racket as a programming language but also to those who want to use it as “a programming-language programming language”. He adds, “The idea of language-oriented programming (LOP) doesn't apply only to languages with parentheses, and we need to demonstrate that.” With this change, he hopes to make Racket2 more familiar and easier-to-accept for users outside the Racket community. Some Racket developers believe changing s-expressions based syntax is not “desirable” Many developers in the Racket community share a similar sentiment as Greg Hendershott. A user on Hacker News added, “Getting rid of s expressions without it being part of a more cohesive improvement (like better supporting a new type system or something) just for mainstream appeal seems like an odd choice to me.” Another user added, “A syntax without s-expressions is not an innovative feature. For me, it's not even desirable, not at all. When I'm using non-Lispy languages like Rust, Ada, Nim, and currently a lot of Go, that's despite their annoying syntactic idiosyncrasies. All of those quirky little curly braces and special symbols to save a few keystrokes. I'd much prefer if all of these languages used s-expressions. That syntax is so simple that it makes you focus on the semantics.” While others are more neutral about this suggested change. “To me, Flatt's proposal for Racket2 smells more like adding tools to better facilitate infix languages than deprecating S-expressions. Given Racket's pedagogical mission, it looks more like a move toward migrating the HtDP series of languages (Beginning Student, Intermediate Student, Intermediate Student with Lambda, and Advanced Student) to infix syntax than anything else. Not really the end of the world or a big change to the larger Racket community. Just another extension of an ecosystem that remains s-expression based despite Algol and Datalog shipping in the box,” a user expressed his opinion. To know more about this change, check out the discussion on Racket’s mailing list. Also, you can share your solutions on Racket2 RFCs. Racket 7.3 releases with improved Racket-on-Chez, refactored IO system, and more Racket 7.2, a descendant of Scheme and Lisp, is now out! Racket v7.0 is out with overhauled internals, updates to DrRacket, TypedRacket among others

Last month, the npm engineering team in a white paper shared why they chose Rust to rewrite their authorization service. If you are not already aware, npm is the largest package manager that offers both an open source and enterprise registry. The npm registry boasts of about 1.3 billion package downloads per day. Looking at the huge user base, it is not a surprise that the npm engineering team has to regularly keep a check on any area that causes performance problems. Though most of the network-bound operations were pretty efficient, while looking at the authorization service, the team saw a CPU-bound task that was causing a performance bottleneck. They decided to rewrite its “legacy JavaScript implementation” in Rust to make it modern and performant. Why the npm team chose Rust? C, C++, and Java were rejected by the team as C++ or C requires expertise in memory management and Java requires the deployment of JVM and associated libraries. They were then left with two options as the alternate programming languages: Go and Rust. To narrow down on one programming language that was best suited for their authorization service, the team rewrote the service in Node.js, Go, and Rust. The Node.js rewrite was acting as a baseline to evaluate Go or Rust. While rewriting in Node.js took just an hour, given the team’s expertise in JavaScript, the performance was very similar to the legacy implementation. The team finished the Go rewrite in two days but ruled it out because it did not provide a good dependency management solution. “The prospect of installing dependencies globally and sharing versions across any Go project (the standard in Go at the time they performed this evaluation) was unappealing,” says the white paper. Though the Rust rewrite took the team about a week, they were very impressed by the dependency management Rust offers. The team noted that Rust’s strategy is very much inspired by npm’s strategy. For instance, its Cargo command-line tool is similar to the npm command-line tool. All in all, the team chose Rust because not only it matched their JavaScript-inspired expectations, it also gave better developer experience. The deployment process of the new service was also pretty straightforward, and even after deployment, the team rarely encountered any operational issues. The team also states that one of the main reasons for choosing Rust was its helpful community. “When the engineers encountered problems, the Rust community was helpful and friendly in answering questions. This enabled the team to reimplement the service and deploy the Rust version to production.” What were the downsides of choosing Rust? The team did find the language a little bit difficult to grasp at first. The team shared in the white paper, “The design of the language front-loads decisions about memory usage to ensure memory safety in a different way than other common programming languages.” Rewriting the service in Rust came with an extra burden of maintaining two separate solutions for monitoring, logging, and alerting for the existing JavaScript stack and the new Rust stack. Given that it is quite a new language, Rust currently also lacks industry-standard libraries and best practices for these solutions. Read the white paper shared by npm for more details. Mozilla engineer shares the implications of rewriting browser internals in Rust Mozilla shares key takeaways from the Design Tools survey Mozilla partners with Scroll to understand consumer attitudes for an ad-free experience on the web

In the annual Go user survey, the three top requests made by users for Go version 2 were better package management, error handling and the inclusion of generics. Following these requests, the Go 2 draft designs were shared yesterday to include error handling, error values, and adding generics. Note that these are not official proposals. The features, error handling and generics are in step 2 according to the Go release cycle, shown as follows. Source: Go Blog Yesterday, Google developer Russ Cox, gave a talk on design drafts for Golang 2. Go 2 draft designs were also previewed at Gophercon 2018. In his talk, he mentions that the current boilerplate contains too much code for error checks and that the error reporting is not precise enough. For example, an error while using os.Open in which the name of the file which cannot be opened, isn’t mentioned. As proper error reporting only adds to the code, most programmers don’t really bother with this despite knowing that such a practice may create confusion. The new idea, therefore, aims to add a check expression to shorten the checks while keeping them explicit. Cox also stresses on adding experience reports. These reports are difficult but necessary to implement new features. Experience reports turn abstract problems into concrete ones and are needed for changes to be implemented in Golang. They serve as a test case for evaluating a proposed solution and its effects on real-life use-cases. Regarding the inclusion of Generics, Cox mentions: “I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones.” Go 2 is not going to be a single release, but a sequence of releases adding features as and when they are ready. The approach is to first make features backward compatible to Go 1. Minor changes could be seen in Go 1 in a year or so. If there are no backward incompatible changes, Go 1.20 may be just declared as Go 2. The conversation for Go 2 has started, and there is a call for community help and contribution to converting the drafts into official proposals. Visit the Go page and the GitHub repository for more details. Why Golang is the fastest growing language on GitHub Golang 1.11 is here with modules and experimental WebAssembly port among other updates GoMobile: GoLang’s Foray into the Mobile World

Perlin Networks, a scalable DAG-based distributed ledger protocol, introduced a new cross-platform WebAssembly VM named Life. This WebAssembly VM is secure, fast, written in Go and is built specifically for decentralized applications. WebAssembly is a high-level instruction set which enables developers to easily design computationally heavy programs that can securely run on web browsers at an improved speed. Apart from designing programs for the browsers, this instruction set can also be used to train ML models, host databases, or even host blogs/online retail stores 24/7. This is the reason why Perlin networks used it in their project, Life. Projects can easily run WebAssembly code anywhere by simply integrating the Life tool into their applications. Features of Life Life is Fast It uses a wide range of optimization techniques and is faster than all other WebAssembly implementations tested (go-interpreter/wagon, paritytech/wasmi). Life is Correct It implements WebAssembly execution semantics and passes most of the official test suite. Life is Secure User code executed is fully sandboxed. A WebAssembly module's access to resources (instruction cycles, memory usage) may easily be controlled to the very finest detail. Life is Pure This VM does not rely on any native dependencies, and may easily be cross-compiled for running WebAssembly modules on practically any platform such as Windows, Linux, Mac, Android, iOS, and so on. Life is Practical One can make full use of the minimal nature of WebAssembly to write code once and run anywhere. With Life, one can completely customize how WebAssembly module imports are resolved and integrated. A complete control over the execution lifecycle of the WebAssembly modules is also possible. To know more about the WebAssembly based Life VM, visit its GitHub page. Grain: A new functional programming language that compiles to Webassembly WebAssembly comes to Qt. Now you can deploy your next Qt app in browser

Jetbrains have released a new version of their Kotlin/Native technology. With Kotlin/Native, you can compile Kotlin to native binaries that run without any virtual machine. It can also be used when a developer needs to produce a reasonably-sized self-contained program not requiring an additional runtime. Kotlin/Native is now available in version 0.8 with the focus on safer concurrent programming, extending the stdlib functionality, and better iOS development support. The version also hosts numerous bug-fixes and performance optimizations. Let us take a look into each one in detail: Better concurrency support The version 0.8 improves concurrency support with the addition of shared immutable state and improved atomic values and references. Previously, Kotlin/Native applications kept the singleton object state local to a particular thread of execution. This helped in keeping the state of singleton objects on different threads non-synchronized. Now, the version 0.8 allows freezing on singleton objects. With this, developers now have a shared immutable state. A file will be read once per process execution, and is available to any thread or worker. Once published, the object is frozen, and cannot be modified anymore. Library improvements in Kotlin/Native Kotlin/Native has added performance improvements to the existing libraries. The standard library (kotlin.*) is standardized with other platforms using expect/actual mechanism and mostly matches other Kotlin flavors. The standard random number generator and collection shuffling functions are now available, eliminating the need of platform-specific APIs to obtain random numbers. Other JetBrains-provided libraries, like kotlinx.coroutines, kotlinx.serialization, and Ktor HTTP client will get experimental Kotlin/Native support. Developers can now write an iOS app and Android application sharing the same REST API-related logic. iOS support improvements The version 0.8 fixes bugs that prevent publishing iOS apps to AppStore and solves framework initialization problems. It also adds support for 32-bit ARM iOS, so that older devices can be used with Kotlin/Native as well. Binaries can be downloaded for macOS, Linux, and Windows. Visit the GitHub release page for additional information. Forget C and Java. Learn Kotlin: the next universal programming language Getting started with Kotlin programming 4 operator overloading techniques in Kotlin you need to know

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

PyCon Conference 2018, held between May 9 -17 at Cleveland, United States, is one of the largest annual gatherings in the Python programming community. Every year features a range of important announcements and discussions, many of which could have a huge impact on the future of Python. This year featured discussions on everything from data science to cryptocurrencies. Let’s take a look at some of the highlights. Quantum Computing Quantum computers are turning into reality, 30 years after they were first theorized. Companies such as IBM, Google, Intel, and Microsoft have all jumped into the quantum computing pool by announcing their own quantum devices. Although Quantum computing is still at a very early stage, Python is slowly becoming a de facto language for programming quantum computers due to its vast ecosystem of libraries. Dr. Ravi Chityala, a Senior Engineer at Elekta Inc, gave an impressive talk on quantum computing while highlighting several caveats that distinguish a traditional and quantum computer. He also demonstrated how to program a quantum computer on stage with Python. Check out the complete presentation here. Blockchain and Cryptocurrencies Blockchain and cryptocurrencies are all the rage right now. Cryptocurrencies such as Bitcoin had attracted a lot of attention in the past one year, mostly from people who were trying to make a quick buck. But this trends seems to be settling down. People are shifting their focus to understanding the technology behind cryptocurrencies. This is where Blockchain comes into the picture. What’s important to developers and businesses is how Blockchain can be applied. The lack of knowledge about how Blockchain works is a barrier that stops many  people entering and exploring the blockchain and cryptocurrency world. The session “Getting Started with Blockchains and Cryptocurrencies in Python” at PyCon conducted by Amirali Sanatinia, aimed to solve this problem by helping them understand the nuts and bolts of Blockchain and embark their journey on this revolutionary technology. Django 2.0 Unchained Django is one of the most popular web development frameworks for Python. Last December the Django team released version 2 of the popular server-side framework. Since this was one of the major releases, it was no surprise that Django was a hot topic of discussion at PyCon 2018. Harry Percival, author of Test-Driven Development with Python, presented a couple of tutorials specifically for Python testers. His tutorial was an introduction to doing Test-Driven Development (TDD) with Django.He shed some light on how automated software testing has moved from being a niche interest to an important new way of thinking about how to optimise automation testing. Serverless Python Serverless is the latest phase in the evolution of cloud development; it has recently exploded in terms of popularity. Going serverless lets developers to focus on their core product instead of worrying about managing and operating servers or runtimes, either in the cloud or on-premises. This reduced overhead helps them to achieve the required scale without the overhead of running and managing the fleet of servers. Since Python is one of the few languages supported by AWS Lambda, developers can leverage it to build fast and cost-effective solutions. In PyCon 2018 we saw some exciting sessions which highlighted the latest developments in Serverless computing. James Saryerwinnie’s tutorial on Building serverless applications with AWS Chalice, sparked the interest of professional developers, while Michael Herman’s tutorial on Going Serverless with OpenFaaS, Kubernetes, and Python was explored how to build and deploy a full-stack application that uses Flask (client-facing app) along with OpenFaaS to handle background processes. While the list of sessions is long we can only cover so much. One of the most important reasons for the dominating success of Python’s popularity is it’s vibrant community and PyCon is a shining example of that. It truly symbolises how liked minded people come together and share the knowledge to make the software development world a better place to live. You can catch up on all the sessions, tutorials, and events at PyCon 2018 at their official website and their Youtube vlog. Should you move to Python 3? 7 Python experts’ opinions How to write high quality code in Python: 15+ tips for data scientists and researchers Why is Python so good for AI and Machine Learning? 5 Python Experts Explain    

Java is preparing to support pattern matching, part of which is revamping the switch statement. The changes are going to allow the switch statement to be used as both statements and as an expression. The changes to the switch statement will simplify everyday coding. It will also pave the way for the use of pattern matching in switch. The current Java switch statement is similar to the ones in languages such as C and C++. It supports fall-through semantics by default. This traditional control flow is often useful for writing low-level code but is error-prone in switch statements used in higher-level code. Brian Goetz, architect at Oracle has proposed to add a new simplified form, with new "case L ->" switch labels in addition to traditional switch blocks. On label match, only the statement or expression to the right of an arrow label is executed. For example, consider the following method: static void howMany(int k) {    switch (k) {        case 1 -> System.out.println("one");        case 2 -> System.out.println("two");        case 3 -> System.out.println("many");    } } On calling the function on these values: howMany(1); howMany(2); howMany(3); This is the output: one two many A new form of switch label, written "case L ->" is proposed to be added. This is an effort to imply that only the code to the right of the label is to be executed if the label is matched. Like a switch statement, a switch expression can also use a traditional switch block with "case L:" switch labels. Most switch expressions have only one expression to the right of the "case L ->" switch label. When a full block is needed, the break statement is extended to take an argument. The cases of a switch expression must contain a matching switch label for any possible value. In practice, this means that a default clause is required. An enum switch expression covers all known cases. In this case, a default clause can be inserted by the compiler indicating that the enum definition has changed between compile-time and runtime. This is done manually by developers today, but having the compiler insert is less intrusive. Also, a switch expression must execute normally with a value or throw an exception. This has a number of consequences like the compiler checking every switch label. Another consequence is that the control statements like break, return and continue, not being able to jump through a switch expression. For more information visit the official OpenJDK post. No more free Java SE 8 updates for commercial use after January 2019 Dagger 2.17, a dependency injection framework for Java and Android, is now out! Build Java EE containers using Docker [Tutorial]

This Saturday, the Golang team released the State of Go February 2019 outlining the developments in the programming language and showing its current state. Since Golang 1.11, changes have been made to the standard library, tooling, and the community. Changes in the standard library html/template The behavior when an interface is typed to an implicit escaper function is changed. It was previously <nil> and is now ignored. Changes under bufio, NewReader The UnreadRune and UnreadByte methods from Reader will return an error if they are called after Peek. new ReplaceAll function There is a new ReplaceAll function where the value passed can be bytes or strings. Changes under builtin: maps printed sorted To print a map sorted by keys, developers can just print the map. However, note that iteration will be done randomly. TLS 1.3 Using TLS 1.3 in Go helps by causing one fewer round trip, securing only cipher suites, and provides support in all major browsers. Tooling changes The following commands now work: go run pkg go run dir Functions can now be run in the debugger. The godoc CLI is now deprecated. The go vet tool is deprecated in Go 1.12. It detects wrapped fmt.Printf errors. modules modules is an alternative to GOPATH. It has integrated versioning and package distribution. runtime/trace Now there are custom events to runtime traces. webassembly Go can now compile to WebAssembly (wasm files) Ports You need Go 1.11 and later for OpenBSD 6.4 arm64 runtime is now faster Windows/arm now has support for Raspberry Pi3 These were a select few important updates from the presentation, for more details you can view The State of Go: Feb 2019. The Golang team has started working on Go 2 proposals Golang just celebrated its ninth anniversary GoCity: Turn your Golang program into a 3D city