Tech News - Programming

On Monday, .NET engineering team announced the latest monthly release of their cross-platform, open source machine learning framework for .NET developers, ML.NET 0.6. Some of the exciting features in this release include new API for building and using machine learning models, performance improvements, and much more. Improvements in the ML.NET 0.6 A new LearningPipeline API for building ML model The new API is more flexible and enables new tasks and code workflow that weren’t possible with the previous LearningPipeline API. The team further plans to deprecate the current LearningPipeline API. This new API is designed to support a wider set of scenarios. It closely follows ML principles and naming from other popular ML related frameworks like Apache Spark and Scikit-Learn. Know more about the new ML.NET API, visit the Microsoft blog. Ability to get predictions from pre-trained ONNX Models ONNX, an open and interoperable model format enables using models trained in one framework (such as scikit-learn, TensorFlow, xgboost, and so on) and use them in another (ML.NET). ML.NET 0.6 includes support for getting predictions from ONNX models. This is done by using a new transformer and runtime for scoring ONNX models. There are a large variety of ONNX models created and trained in multiple frameworks that can export models to ONNX format. Those models can be used for tasks like image classification, emotion recognition, and object detection. The ONNX transformer in ML.NET provides some data to an existing ONNX model and gets the score (prediction) from it. Performance improvements In the ML.NET 0.6 release, there are made several performance improvements in making single predictions from a trained model. Two improvements include: Moving the legacy LearningPipeline API to the new Estimators API. Optimizing the performance of PredictionFunction in the new API. Following are some comparisons of the LearningPipeline with the improved PredictionFunction in the new Estimators API: Predictions on Iris data: 3,272x speedup (29x speedup with the Estimators API, with a further 112x speedup with improvements to PredictionFunction). Predictions on Sentiment data: 198x speedup (22.8x speedup with the Estimators API, with a further 8.68x speedup with improvements to PredictionFunction). This model contains a text featurizer, so it is not surprising to see a smaller gain. Predictions on Breast Cancer data: 6,541x speedup (59.7x speedup with the Estimators API, with a further 109x speedup with improvements to PredictionFunction). Improvements in Type system In this ML.NET version, the Dv type system has been replaced with .NET’s standard type system. This makes ML.NET easy to use. ML.NET previously had its own type system, which helped it deal with missing values (a common case in ML). This type system required users to work with types like DvText, DvBool, DvInt4, etc. One effect of this change is, only floats and doubles have missing values which are represented by NaN. Due to the improved approach to dependency injection, users can also deploy ML.NET in additional scenarios using .NET app models such as Azure Functions easily without convoluted workarounds. To know more about other improvements in the ML.NET 0.6 visit the Microsoft Blog. Microsoft open sources Infer.NET, it’s popular model-based machine learning framework Neural Network Intelligence: Microsoft’s open source automated machine learning toolkit .NET Core 3.0 and .NET Framework 4.8 more details announced

People started using htop when the top just didn’t provide enough information. Now there is NVTOP, a tool that looks similar to htop but displays the process information loaded on your NVIDIA GPU. It works on Linux systems and displays detailed information about processes, memory used, which GPU and also displays the total GPU and memory usage. The first version of this tool was released in July last year. The latest change made the process list and command options scrollable. Some of the features of NVTOP are: Sorting by column To Select / Ignore a specific GPU by ID To kill selected process Monochrome option Yes, it has multi GPU support and can display the running processes from all of your GPUs. The information printed out looks like the following, and is similar to something htop would display. Source: GitHub There is also a manual page to give some guidance in using NVTOP. It can be accessed with this command: man nvtop There are OS specific installation steps on GitHub for Ubuntu/Debian, Fedora/RedHat/CentOS, OpenSUSE, and Arch Linux. Requirements There are two libraries needed to build and run NVTOP: The NVIDIA Management Library (NVML) for querying GPU information. The ncurses library for the user interface and make it colorful. Supported GPUs The NVTOP tool works only for NVIDIA GPUs and runs on Linux systems. One of the dependencies is the NVML library which does not support some queries from GPUs before the Kepler microarchitecture. That is anything before GeForce 600 series, GeForce 700 series, or GeForce 800M wouldn’t likely work. For AMD users, there is a tool called radeontop. The tool is provided under the GPLV3 license. For more details, head on to the NVTOP GitHub repository. NVIDIA leads the AI hardware race. But which of its GPUs should you use for deep learning? NVIDIA announces pre-orders for the Jetson Xavier Developer Kit, an AI chip for autonomous machines, at $2,499 NVIDIA open sources its material definition language, MDL SDK

Yesterday GitHub introduced ‘Template repository’ using which you can share boilerplate code and directory structure across projects easily. This is similar to the idea of ‘Boilr’ and ‘Cookiecutter’. https://twitter.com/github/status/1136671651540738048 How to create a GitHub template repository? As per its name, ‘Template repository’ enable developers to mark a repository as a template, which they can use later for creating new repositories containing all of the template repository’s files and folders. You can create a new template repository or mark an existing one as a template with admin permissions. Just navigate to the Settings page and then click on the ‘Template repository’ checkbox. Once the template repository is created anyone who has access to it will be able to generate a new repository with same directory structure and files via ‘Use this template’ button. Source: GitHub All the templates that you own, have access to, or have used in a previous project will also be available to you when creating a new repository through ‘Choose a template’ drop-down. Every template repository will have a new URL ‘/generate’ endpoint that will allow you to distribute your template more efficiently. You just need to link your template users directly to this endpoint. Source: GitHub Templating is similar to cloning a repository, except it does not retain the history of the repository unlike cloning and gives users a clean new project with an initial commit. Though this function is still pretty basic, as GitHub will add more functionality in the future, it will be useful for junior developers and beginners to help them get started. Here’s what a Hacker News user believes we can do with this feature: “This is a part of something which could become a very powerful pattern: community-wide templates which include many best practices in a single commit: - Pre-commit hooks for linting/formatting and unit tests. - Basic CI pipeline configuration with at least build, test and release/deploy phases. - Package installation configuration for the frameworks you want. - Container/VM configuration for the languages you want to enable cross-platform and future-proof development. - Documentation to get started with it all.” Read the official announcement by GitHub for more details. Github Sponsors: Could corporate strategy eat FOSS culture for dinner? GitHub Satellite 2019 focuses on community, security, and enterprise Atlassian Bitbucket, GitHub, and GitLab take collective steps against the Git ransomware attack

Node.JS is a popular backend widely for web development despite some of its flaws. For embedded systems, now there is low.js, a Node.js port with far lower system requirements. In low.js you can program JavaScript applications by utilizing the full Node.js API. You can run these on regular computers and also on embedded devices, which are based on the $3 ESP32 microcontroller. The JavaScript V8 engine at the center of Node.js is replaced with Duktape. Duktape is an embeddable ECMAScript E5/E5.1 engine with a compact footprint. Some parts of the Node.js system library are rewritten for more compact footprint and use more native code. low.js currently uses under 2 MB of disk space with a minimum requirement of around 1.5 MB of RAM for the ESP32 version. low.js features low.js is good for hobbyists and people interested in electronics. It allows using Node.JS scripts on smaller devices like routers which are based on Linux or uClinux without using much of the resources. This is great for scripting especially if they communicate over the internet. The neonious one is a microcontroller board based on low.js for ESP32, which can be programmed in JavaScript ES 6 with the Node API. It includes Wifi, Ethernet, additional flash and an extra I/O controller. The lower systems requirements in low.js allow you to run it comfortably on the ESP32-WROVER module. The ESP32-WROVER costs under $3 for large orders and is a very cost effective solution for IoT devices requiring a microcontroller and Wifi. low.js for ESP32 also adds the additional benefit of fast software development and maintenance. Specialized software developers are not needed for the microcontroller software. How to install? The community edition of low.js can be run on POSIX based systems including Linux, uClinux, and Mac OS X. It is available on Github and currently ./configure is not present. You might need some programming skills and knowledge to get low.js up and running on your systems. The commands are as follows: git clone https://github.com/neonious/lowjs cd lowjs git submodule update --init --recursive make low.js for ESP32 is the same as the community edition, but adapted for the ESP32 microcontroller. This version is not open source and is pre-flashed on the neonious one. For more information and documentation visit the low.js website. Deno, an attempt to fix Node.js flaws, is rewritten in Rust Node.js announces security updates for all their active release lines for August 2018 Deploying Node.js apps on Google App Engine is now easy

Mozilla is building a bridge between Rust and JavaScript. The bridge - Wasm-bindgen - allows Rust to interact with Web Assembly modules and JavaScript. One of Mozilla's aims is to turn Rust into a language for web development; building a link to WebAssembly is perhaps the most straightforward way for it to run on the web. But this doesn't mean Mozilla wants Rust to replace JavaScript - far from it. The plan is instead for Rust to be a language that runs alongside JavaScript on the backend. Read more about Mozilla's plan here. What is wasm-bindgen? It's worth reading this from the Mozilla blog to see the logic behind wasm-bidgen and how it's going to work: "Today the WebAssembly specification only defines four types: two integer types and two floating-point types. Most of the time, however, JS and Rust developers are working with much richer types! For example, JS developers often interact with document to add or modify HTML nodes, while Rust developers work with types like Result for error handling, and almost all programmers work with strings. Being limited only to the types that WebAssembly provides today would be far too restrictive, and this is where wasm-bindgen comes into the picture. The goal of wasm-bindgen is to provide a bridge between the types of JS and Rust. It allows JS to call a Rust API with a string, or a Rust function to catch a JS exception. wasm-bindgen erases the impedance mismatch between WebAssembly and JavaScript, ensuring that JavaScript can invoke WebAssembly functions efficiently and without boilerplate, and that WebAssembly can do the same with JavaScript functions." This is exciting as it is a valuable step in expanding the capabilities of Rust. But the thinking behind wasm-bindgen will also help to further drive the adoption of web assembly. While the focus is, of course, on Rust at the moment, there's a possibility that wasm-bindgen could eventually be used with other languages, such as C and C++. This might take some time, owever. Download wasm-bindgen from GitHub.

Oracle owned Java will no longer provide free public updates of Java SE 8 for commercial use after January 2019. This move is a part of their long term support (LTS) plan. However, for individual personal use the public updates for Oracle Java SE 8 will be available at least till December 2020. Borrowing ideas from Linux releases, Oracle Java releases will now follow LTS. The bi yearly updates will now have minor updates. One of the releases being termed as LTS and Oracle will provide long term support for it (3 years). Other releases will cease getting support when the next version is released. If you are using Java for personal use individually, you will have the same access to Oracle Java SE 8 updates till end of 2020. In most cases, the Java-based applications run on your PCs are licensed by a company other than Oracle. For example, games developed by gaming companies. You won’t have access to public updates beyond the date mentioned, it depends on the gaming company on how they plan to provide application support. Developers are recommended to view Oracle’s release roadmap for Java SE 8 and other versions. Accordingly, you can take action to support your applications. The next LTS version, Java 11 is set to roll out in September 2018. Here is the Oracle Java SE Support Roadmap. Release GA Date Premier Support Until Notification Extended Support Until Sustaining Support 6 December 2006 December 2015 December 2018 Indefinite 7 July 2011 July 2019 July 2022 Indefinite 8 March 2014 March 2022 March 2025 Indefinite 9 (non‑LTS) September 2017 March 2018 Not Available Indefinite 10 (18.3^)(non‑LTS) March 2018 September 2018 Not Available Indefinite 11 (18.9^ LTS) September 2018 September 2023 September 2026 Indefinite 12 (19.3^ non‑LTS) March 2019 September 2019 Not Available Indefinite The roadmap for web deployment and Java FX is different and is listed on their website. This video explains the LTS release model for Java, for more information, visit the official update. Mark Reinhold on the evolution of Java platform and OpenJDK Build Java EE containers using Docker [Tutorial] 5 Things you need to know about Java 10

Grain is a strongly-typed functional programming language built for the modern web by leveraging the brilliant work done by the WebAssembly project. Unlike other languages used on the web today (like TypeScript or Elm), that compile into JavaScript, Grain doesn’t compile into JavaScript but compiles all the way down to WebAssembly, supported by a tiny JavaScript runtime to give it access to web features that WebAssembly doesn’t support yet. It was designed with the purpose to specifically serve web developers. Following are the language features: No runtime type errors Grain does not need any kind of type annotations. All the pieces of Grain code that developers write is thoroughly sifted for type errors. Developers do not have to deal with runtime exceptions and thus achieving full type safety with none of the fuss. Being functional, but flexible Grain is geared towards functional programming, but understands the web isn't as pure as we would like it to be. It enables one to easily write what's appropriate for the scenario. Embracing new web standards Grain is built on top of WebAssembly, a brand-new technology that represents a paradigm shift in web development. WebAssembly is nothing but a bytecode format which is executed in a web browser. This allows an application to be deployed to a device with a compliant web browser having to go through any explicit installation steps. TypeScript 3.0 is finally released with ‘improved errors’, editor productivity and more Elm and TypeScript – Static typing on the Frontend Tools in TypeScript

Yesterday, the team at Go announced the results of their user survey for the year 2018. 5,883 users from 103 different countries participated in the survey. Key highlights from the Go User Survey 2018 According to the report, for the first time, half of the survey respondents said that they are currently using Go as part of their daily routine. It seems this year proved to be even better for Go as the graph saw a significant increase in the number of respondents who develop their projects in Go as part of their jobs and also use Go outside of their work responsibilities. Also, a majority of survey respondents said that Go is their most-preferred programming language. Here are some other findings: API/RPC services and CLI tools are the commonly used tools by Go users. VS Code and GoLand have become the most popular code editors among survey respondents. Most Go developers use more than one primary OS for development where Linux and macOS are popular. Automation tasks were declared as the fast-growing area for Go. Web development still remains the most common domain but DevOps has shown the highest year-over-year growth and is also the second most common domain now. Survey respondents have been shifting from on-premise Go deployments to containers and serverless cloud deployments. To simplify the survey report, the team at Go broke the responses down into three groups: The ones who are using Go both in and outside of work The ones who use Go professionally but not outside of work The ones who only use Go outside of their job responsibilities According to the survey, nearly half (46% of respondents) write Go code professionally as well as during their free time because the language appeals to developers who do not view software engineering only as a day job. According to the survey, 85% of respondents would prefer to use Go for their next project. Would you recommend Go to a friend? This year, the team had added a question, "How likely are you to recommend Go to a friend or colleague?" for calculating Net Promoter Score. This score measures the number of "promoters" a product has than "detractors" and it ranges from -100 to 100. A positive value would suggest most people are likely to recommend using a product, while negative values will suggest, most people wouldn’t recommend using it. The latest score (2018) is 61, where 68% are promoters - 7% are detractors. How satisfied are developers with Go? The team also asked many questions about developer satisfaction with Go, in the survey. Majority survey respondents indicated a high level of satisfaction which is consistent with prior year results. Around 89% of the respondents said that they are happy with Go and  66% felt that it is working well for their team. These metrics showed an increase in 2017 and they mostly remained stable this year. The downside About half of the survey respondents work on existing projects that are written in other languages, and ⅓ work on a team or project that prefer a language other than Go. The reason highlighted by the respondents for this is the missing language features and libraries. The team identified the biggest challenges faced by developers while using Go with the help of their machine learning tools. The top three challenges highlighted by the team as per the survey are: Package management is one of the major challenges. A response from the survey reads,“keeping up with vendoring, dependency / packet [sic] management / vendoring is not unified.” There are major differences from more familiar programming languages. A response from the survey reads, “Syntax close to C-languages with slightly different semantics makes me look up references somewhat more than I'd like", Another respondent says, "My coworkers who come from non-Go backgrounds are trying to use Go as a version of their previous language but with channels and Goroutines." Lack of generics is another problem. Another response from the survey reads, “Lack of generics makes it difficult to persuade people who have not tried Go that they would find it efficient. Hard to build richer abstractions (want generics)” Go community Go blog, Reddit's r/golang, Twitter, and Hacker News remain the primary sources for Go news. This year, 55% of survey respondents said they are interested in contributing towards the Go community, though it is slightly lesser than last year (59%). The standard library and official Go tools require interacting with the core Go team which could be one of the reasons for the dip in the percentage. Another reason is the dip in the percentage of participants who are willing to take up the Go project leadership. It was 30% last year and it has become 25% this year. This year only 46% of respondents are confident about taking the leadership of Go, it was 54% last year. You can read the complete results of the survey on Golang’s blog post. Update: The title of this article was amended on 4.1.2019. GitHub releases Vulcanizer, a new Golang Library for operating Elasticsearch Google Podcasts is transcribing full podcast episodes for improving search results State of Go February 2019 – Golang developments report for this month released  

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  

This year, Netflix decided to make Spring Boot as their core Java framework, while leveraging the community’s contributions via Spring Cloud Netflix. The team at Netflix started working towards fully operating in the cloud in 2007. It also built several cloud infrastructure libraries and systems  including, Ribbon, an Inter Process Communication (IPC) library for load balancing, Eureka, an AWS service registry for service discovery, and Hystrix, latency and fault tolerance library for fault tolerance. Spring Cloud Netflix provides Netflix OSS integrations for Spring Boot apps with the help of autoconfiguration and binding to the Spring Environment.  It was updated to version 1.0. in 2015. The idea behind Spring Cloud was to bring the Netflix OSS components using Spring Boot instead of Netflix internal solutions. It has now become the preferred way for the community to adopt Netflix’s Open Source software. It features Eureka, Ribbon, and Hystrix. Why did Netflix opt for Spring Boot framework? In the early 2010s, the requirements for Netflix cloud infrastructure were efficiency, reliability, scalability, and security. Since there were no other suitable alternatives, the team at Netflix created solutions in-house. By adopting the Spring Boot framework, Netflix has managed to meet all of these requirements as it provides great experiences such as: Data access with spring-data, Complex security management with spring-security, and Integration with cloud providers with spring-cloud-aws. Spring framework also features proven and long lasting abstractions and APIs. The Spring team has also provided quality implementations from abstractions and APIs. This abstract-and-implement methodology also matches well with Netflix’ principle of being “highly aligned, loosely coupled”. “We plan to leverage the strong abstractions within Spring to further modularize and evolve the Netflix infrastructure. Where there is existing strong community direction such as the upcoming Spring Cloud Load Balancer , we intend to leverage these to replace aging Netflix software. ” - Netflix Read more about this news on Netflix Tech blog. Netflix’s culture is too transparent to be functional, reports the WSJ Tech News Today: Facebook’s SUMO challenge; Netflix AVA; inmates code; Japan’s AI, blockchain uses How Netflix migrated from a monolithic to a microservice architecture [Video]  

Yesterday, on the first day of Microsoft Build 2019, the team behind .NET Core announced that .NET Core 3.0 will be .NET 5, which will also be the next big release in the .NET family. Now there will be just one .NET going forward, and users will be able to use it to target  Linux, macOS, Windows, iOS, Android, tvOS, watchOS and WebAssembly and much more. .NET Core team will also introduce new .NET APIs, runtime capabilities and language features as part of .NET 5 along with the first preview, which is expected in November 2020. .NET 5 takes .NET Core and the best of Mono, runtime for .NET Core, to create a single platform that you can use for all your modern .NET code. This release will be supported with future updates to Visual Studio 2019, Visual Studio Code and Visual Studio for Mac. What is expected in .NET 5? Switch build in runtimes .NET Core has two main runtimes, namely, Mono which is the original cross-platform implementation of .NET and CoreCLR which is primarily targeted at supporting cloud applications, including the largest services at Microsoft. Both runtimes have a lot of similarities, so, the team has decided to make CoreCLR and Mono drop-in replacements for one another. The team plans to make it easier for users to choose between the different runtime options. .NET 5 applications In this release, all the .NET 5 applications will be using the CoreFX framework which will work smoothly with Xamarin and client-side Blazor workloads. These .NET 5 applications will be buildable with the .NET CLI, which will ensure that users have common command-line tooling across projects. Naming The team thought of simplifying the naming as there is only one .NET going forward, so there is no need of clarifying term like “Core”. According to the team, .NET 5 is a shorter name and also communicates that it has uniform capabilities and behaviors. Others ways in which .NET 5 project will improve are: This release will produce a single .NET runtime and framework which has a uniform runtime behaviour and developer experiences and can be used everywhere. This release will also expand the capabilities of .NET by reflecting the best of .NET Core, .NET Framework, Xamarin and Mono. It will also help in building projects out of a single code-base that developers can work on and expand together. Also, the code and project files will look and feel the same no matter which type of app is getting built. Users will continue to get access to the same runtime, API and language capabilities with each app. Users will now have more choice for runtime experiences. This release will come with Java interoperability for all the platforms. In this release, Objective-C and Swift interoperability will be supported on multiple operating systems. What won’t change? NET Core will continue to be open source and community-oriented on GitHub. It will still have cross-platform implementation. This release will also support platform-specific capabilities, such as Windows Forms and WPF on Windows, etc. It will support side-by-side installation and provide high performance. It will also support small project files (SDK-style) and command-line interface (CLI). A glimpse at the future roadmap Image source: Microsoft The blog reads, “The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have a broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions. We see a bright future ahead in which you can use the same.” To know more about this news, check out Microsoft’s blog post. Fedora 31 will now come with Mono 5 to offer open-source .NET support .NET 4.5 Parallel Extensions – Async .NET 4.5 Extension Methods on IQueryable  

At Microsoft Ignite 2019, Microsoft announced that Jupyter Notebooks will now allow users to run .NET code with the new .NET Jupyter Notebooks. Try .NET has grown to support more interactive experiences across the web with runnable code snippets, interactive documentation generator for .NET Core with dotnet try global tool. The same codebase is taken to the next level by announcing C# and F# in Jupyter notebooks. What’s new in .NET Jupyter Notebook By default, the .NET notebook experience enables users to display useful information about an object in table format. .NET notebooks also by default, ship with several helper methods for writing HTML; from basic helpers that enable users to write out a string as HTML or output Javascript to more complex HTML with PocketView. .NET Notebooks are a perfect match for ML .NET .NET notebooks bring interesting options for ML.NET, like exploring and documenting model training experiments, data distribution exploration, data cleaning, plotting data charts, and learning. To leverage ML.NET in Jupyter notebooks, users can check out the blog post Using ML.NET in Jupyter notebooks with several online samples. Create charts using Xplot Charts are rendered using Xplot.Plotly. As soon as users import XPlot.Plotly namespace into their notebooks(using Xplot.Ploty;), they can begin creating rich data visualizations in .NET. Source: Microsoft.com .NET for Apache Spark With .NET for Apache Spark, .NET developers have two options for running .NET for Apache Spark queries in notebooks: Azure Synapse Analytics Notebooks and Azure HDInsight Spark + Jupyter Notebooks. Both the experiences allow developers to write and run quick ad-hoc queries in addition to developing complete, end-to-end big data scenarios, such as reading in data, transforming it, and visualizing it. To learn how to get started with .NET for Apache Spark, visit the GitHub repo. Many users are excited to try out the new .NET Jupyter Notebooks. A user on Hacker News commented, “This is great news. Jupyter has become my default tool for prototyping code. I keep trying other platforms that should theoretically have the same features, but I just find Jupyter much more pleasant to use.” Another user commented, “I love .NET and I love Jupyter. I don't know how well they will combine though. I feel like the lack of Pandas and flexible typing of Python will make it a lot less useful.” To know more about this announcement in detail, Scott Hanselman’s post on his website. Introducing Voila that turns your Jupyter notebooks to standalone web applications JupyterHub 1.0 releases with named servers, support for TLS encryption and more .NET Framework API Porting Project concludes with .NET Core 3.0

LLVM team released LLVM 8.0, earlier this week. LLVM is a collection of tools that help develop compiler front ends and back ends. LLVM is written in C++ and has been designed for compile-time, link-time, run-time, and "idle-time" optimization of programs that are written in arbitrary programming languages. LLVM 8.0 explores known issues, major improvements and other changes in the subprojects of LLVM. There were certain issues in LLVM 8.0.0 that could not be fixed earlier (before this release). For instance, clang is getting miscompiled by trunk GCC, and “asan-dynamic” is not able to work on FreeBSD. Other than the issues, there is a long list of changes that have been made to LLVM 8.0.0. Non-comprehensive changes to LLVM 8.0.0 llvm-cov tool can export lcov trace files with the help of the -format=lcov option of the export command. The add_llvm_loadable_module CMake macro has been deprecated. The add_llvm_library macro with the MODULE argument can now help provide the same functionality. For MinGW, references to data variables that are to be imported from a dll can be now accessed via a stub. This will further allow the linker to convert it to a dllimport if needed. Support has been added for labels as offsets in .reloc directive. Windows support for libFuzzer (x86_64) has also been added. Other Changes LLVM IR:  The Function attribute named speculative_load_hardening has been introduced. This will indicate that Speculative Load Hardening should be enabled for the function body. JIT APIs: ORC (On Request Compilation) JIT APIs will now support concurrent compilation. The existing (non-concurrent) ORC layer classes, as well as the related APIs, have been deprecated. These have been renamed with a “Legacy” prefix (e.g. LegacyIRCompileLayer). All the deprecated classes will be removed in LLVM 9. AArch64 Target: Support has been added for Speculative Load Hardening. Also, initial support added for the Tiny code model, where code and the statically defined symbols should remain within 1MB. MIPS Target: Support forGlobalISel instruction selection framework has been improved. ORC JIT will now offer support for MIPS and MIPS64 architectures. There’s also newly added support for MIPS N32 AB. PowerPC Target: This has now been switched to non-PIC default in LLVM 8.0.0. Darwin support has also been deprecated. Also, Out-of-Order scheduling has been enabled for P9. SystemZ Target: These include various code-gen improvements related to improved auto-vectorization, inlining, as well as the instruction scheduling. Other than these, changes have also been made to X86 target, WebAssembly Target, Nios2 target, and LLDB. For a complete list of changes, check out the official LLVM 8.0.0 release notes. LLVM 7.0.0 released with improved optimization and new tools for monitoring LLVM will be relicensing under Apache 2.0 start of next year LLVM officially migrating to GitHub from Apache SVN

In October last year, it was reported that LLVM (Low-Level Virtual Machine) is moving from Apache Subversion (SVN) to GitHub. Now the migration is complete and LLVM is available on GitHub. This transition was long under discussion and is now officially complete. LLVM is a toolkit for creating compilers, optimizers, and runtime environments. This migration comes in place as continuous integration is sometimes broken in LLVM because the SVN server was down. They migrated to GitHub for services lacking in SVN such as better 24/7 stability, disk space, code browsing, forking etc. GitHub is also used by most of the LLVM community. There already were unofficial mirrors on GitHub before this official migration. Last week, James Y Knight from the LLVM team wrote to a mailing list: “The new official monorepo is published to LLVM's GitHub organization, at: https://github.com/llvm/llvm-project. At this point, the repository should be considered stable -- there won't be any more rewrites which invalidate commit hashes (barring some _REALLY_ good reason...)” Along with LLVM, this monorepo also hosts Clang, LLD, Compiler-RT, and other LLVM sub-projects. Commits are being made to the LLVM GitHub repository even at the time of writing and the repo currently has about 200 stars. Updated workflow documents and instructions on migrating user work that is in-progress are being drafted and will be available soon. This move was initiated after positive responses from LLVM community members to migrate to GitHub. If you want to be up to date with more details, you can follow the LLVM mailing list. LLVM will be relicensing under Apache 2.0 start of next year A libre GPU effort based on RISC-V, Rust, LLVM and Vulkan by the developer of an earth-friendly computer LLVM 7.0.0 released with improved optimization and new tools for monitoring

Microsoft is ever striving to make its products run better. They can add yet another accomplishment to their list as Microsoft’s cloud service search engine, Bing is now running fully on .NET Core 2.1, as announced by the .NET engineering team in their blog yesterday. .NET Core is the slimmed down and cross-platform version of Microsoft’s .NET managed common language runtime. Since Bing runs on thousands of servers spanning many data centers across the globe, .NET Core will serve as the perfect platform for it to function on. Why did Bing migrate to .NET Core 2.1? Bing has always run on the .NET Framework, but has been able to move to .NET Core 2.1 after some recent API additions. Let’s take a look at the main reasons for Bing.com’s migration to .NET Core. 1. Performance i.e. serving latency .NET Core 2.1 has led to an improvement in performance in virtually all areas of the runtime and libraries. The internal server latency over the last few months shows a striking 34% improvement. Check out the graph for a clear picture!     Souce: blog.msdn.microsoft.com The following changes in .NET Core 2.1 are the reasons why the workload and performance has greatly improved- #1 Vectorization of string.Equals & string.IndexOf/LastIndexOf HTML rendering and manipulation are string-heavy workloads. Vectorization of String comparisons and indexing operations (major components of string slicing) is the biggest contributor to the performance improvement. You can find more information on this on the github page for  Vectorization of string.Equals and string.IndexOf/LastIndexOf #2 Devirtualization Support for EqualityComparer<T>.Default One of .NET core’s major software components is a heavy user of Dictionary<int/long, V>, which indirectly benefits from the intrinsic recognition work that was done in the JIT to make Dictionary<K, V> amenable to that optimization.  Head over to the github page for more clarity on why this feature empowers .NET Core 2.1 #3 Software Write Watch for Concurrent GC This led to a reduction in CPU usage. The implementation relies on a JIT Write Barrier, which instinctively increases the cost of a reference store, but that cost is amortized and not noticed in the workload. #4 Methods with calli are now inline-able ldftn + calli  are used in lieu of delegates (which incur an object allocation) in performance-critical pieces of code where there is a need to call a managed method indirectly. This change allowed method bodies with a calli instruction to be eligible for inlining. The github page provides more insight on this subject. #5 Improve performance of string.IndexOfAny for 2 & 3 char searches A common operation in a front-end stack is search for ‘:’, ‘/’, ‘/’ in a string to delimit portions of a URL. Check out this special-casing improvement that was beneficial throughout the codebase on the github page. 2. Runtime Agility The ability to have an xcopy version of the runtime inside their application denotes that they can adopt newer versions of the runtime at a much faster pace. The Continuous integration (CI) pipeline is run with .NET Core’s daily CI and it builds testing functionality and performance all the way through the release. 3. ReadyToRun Images Managed applications usually can have poor startup performance as methods first have to be JIT compiled to machine code. .NET Framework has a precompilation technology, NGEN. On .NET Core, the crossgen tool allows the code to be precompiled as a pre-deployment step, such as in the build lab, and the images deployed to production are Ready To Run! This feature was not supported on the previous  .NET implementation. The .NET Core team is striving to provide Bing.com users fast results. The latest software and technologies used by their developers will ensure that .NET Core will not fail Bing.com! Read the detailed overview of the article on Microsoft's blog. Say hello to FASTER: a new key-value store for large state management by Microsoft Microsoft Azure’s new governance DApp: An enterprise blockchain without mining .NET Core completes move to the new compiler – RyuJIT