Tech News - Languages

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

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

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]  

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

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

Three days ago, the team behind Python announced the release of Python 3.9.0a1, which is the first out of the six planned alpha releases of Python 3.9. The final stable version of Python 3.9 is slated to release in May 2020. An alpha release indicates that developers can start testing the new features and check for bug fixes but are not recommended to use it in production. Last month, the previous stable version, Python 3.8 was released with features like walrus operator, positional-only parameters support for Vectorcall. Read More: Core Python team confirms sunsetting Python 2 on January 1, 2020 Let’s look at some of the raw features that you can be expected in the upcoming Python 3.9 version. Some improvements introduced in Python 3.9.0a1 Language Changes The __import__() function which is invoked by the import statement will now raise ImportError instead of ValueError. In the previous versions, the latter used to occur when a relative import went past its top-level package. Starting from Python 3.9.0a1, the absolute path of the script filename will be specified on the command line: the __file__ attribute of the __main__ module. The sys.argv[0] and sys.path[0] will become an absolute path rather than a relative path. Also, the traceback will now display the absolute path for __main__ module frames in this case. The encoding and errors arguments in the debug build and development mode will now be checked in the string encoding and decoding operations. Improved Modules ast: It is added in the indent option to dump() and produces a multi-line indented output. asyncio: It can now use coroutine which is a generalized form of subroutines. Subroutines enter and exit at only two different points, while coroutines can be entered, exited, and resumed at many points. Moreover, asyncio.run() is updated to use the new coroutine. New functions like curses.get_escdelay(), curses.set_escdelay(), curses.get_tabsize(), and curses.set_tabsize() and constants F_OFD_GETLK, F_OFD_SETLK and F_OFD_SETLKW is included in Python 3.9.0a1. Few Python users have already started testing the Python 3.9.0a1 release. https://twitter.com/codewithanthony/status/1197559895744110592 The next alpha release for Python 3.9 is scheduled for 16th December 2019. To know more about Python 3.9.0a1, check out the official documentation. Introducing Spleeter, a Tensorflow based python library that extracts voice and sound from any music track Severity issues raised for Python 2 Debian packages for not supporting Python 3 Introducing OpenDrop, an open-source implementation of Apple AirDrop written in Python Poetry, a Python dependency management and packaging tool, releases v1 beta 1 with URL dependency PyPy will continue to support Python 2.7, even as major Python projects migrate to Python 3

Last week, Joe Watkins, a PHP developer, shared that PHP 8 will support the Just-in-Time (JIT) compilation. This decision was the result of voting among the PHP core developers for supporting JIT in PHP 8 and also in PHP 7.4 as an experimental feature. If you don’t know what JIT is, it is a compiling strategy in which a program is compiled on the fly into a form that’s usually faster, typically the host CPU’s native instruction set. To do this the JIT compiler has access to dynamic runtime information whereas a standard compiler doesn’t. How PHP programs are compiled? PHP comes with a virtual machine named the Zend VM. The human-readable scripts are compiled into instructions, which are called opcodes that are understandable to the virtual machine. Opcodes are low-level, and hence faster to translate to machine code as compared to the original PHP code. This stage of execution is called compile time. These opcodes are then executed by the Zend VM in the runtime stage. JIT is being implemented as an almost independent part of OPcache, an extension to cache the opcodes so that compilation happens only when it is required. In PHP, JIT will treat the instructions generated for the Zend VM as the intermediate representation. It will then generate an architecture dependent machine code so that the host of your code is no longer the Zend VM, but the CPU directly. Why JIT is introduced in PHP? PHP hits the brick wall Many improvements have been done to PHP since its 7.0 version including optimizations for HashTable, specializations in the Zend VM for certain opcodes, specializations in the compiler for certain sequences, and many more. After so many improvements, now PHP has reached the extent of its ability to be improved any further. PHP for non-Web scenarios Adding support for JIT in PHP will allow its use in scenarios for which it is not even considered today, i.e., in other non-web, CPU-intensive scenarios, where the performance benefits will be very substantial. Faster innovation and more secure implementations With JIT support, the team will be able to develop built-in functions in PHP instead of C without any huge performance penalty. This will make PHP less susceptible to memory management, overflows, and other similar issues associated with C-based development. We can expect the release of PHP 7.4 later this year, which will debut JIT in PHP.  Though there is no official announcement about the release schedule of PHP 8, many are speculating its release in late 2021. Read Joe Watkins’ announcement on his blog. PEAR’s (PHP Extension and Application Repository) web server disabled due to a security breach Symfony leaves PHP-FIG, the framework interoperability group Google App Engine standard environment (beta) now includes PHP 7.2

On Tuesday, Facebook mandates Visual Studio Code, the source code editor developed by Microsoft, as their default development environment. Additionally, they also stated that the company will work with Microsoft to expand the remote development extension for Visual Studio Code so that engineers can do large-scale remote development. As per the official announcement page, Facebook engineers have written millions of lines of codes and there is no mandated development environment. Till now Facebook developers used Vim or Emacs  and the development environment was disjointed. And certain developers also used Nuclide, an integrated development environment developed by Facebook. But in late 2018, they announced to their internal engineers that they would move Nuclide to Visual Studio Code. They have also done plenty of development work to migrate the current Nuclide functionality, along with new features to Visual Studio Code and currently it is used extensively across the company in beta. Why Visual Studio Code? The Visual Studio Code is a very popular development tool, with great support from Microsoft and the open source community. It runs on macOS, Windows, and Linux, and has a robust and well-defined extension API that enables to continue building the important capabilities required for the large-scale development done at Facebook. The company believes that it is a platform on which they can safely bet their development platform future. They have also partnered with Microsoft for remote development. At present, Facebook engineers install Visual Studio Code on a local PC, but the actual development is done directly on the development server in the data center. Therefore, it aims to improve efficiency and productivity by making the code on the server accessible in a seamless and high-performance manner. The company believes that using remote extensions will provide many benefits like: Work with larger, faster, or more specialized hardware than what’s available on local machine Create tailored, dedicated environments for each project’s specific dependencies, without worrying about errors due to mixed or conflicting configurations Support the flexibility of being able to quickly switch between multiple running development environments without impacting local resources or tool performance Facebook mandates Visual Studio Code as an integrated development environment which can be used internally, specifically, because Facebook uses various programming languages. It also uses Mercurial as the source control infrastructure, it will work on the development of extensions to allow direct source control operations within Visual Studio Code. Facebook states, “VS Code is now an established part of Facebook’s development future. In teaming with Microsoft, we’re looking forward to being part of the community that helps Visual Studio Code continue to be a world class development tool.” On Hacker News, developers are discussing various issues related to remote development extensions in VS Code, one of them is it is not open-source and Facebook should take efforts to make it an open project. One comment reads, “Just an FYI for people - The Remote Development extensions are not open source. I'd hope if Facebook were joining efforts, they'd do so on a more open project. 1: https://code.visualstudio.com/docs/remote/faq#_why-arent-the... 2: https://github.com/microsoft/vscode/wiki/Differences-between... 3: https://github.com/VSCodium/vscodium/issues/240 (aka, on-the-wire DRM to make sure the remote components only talk to a licensed VS Code build from Microsoft) MS edited the licensing terms many moons ago, to prepare for VS Code in browser using these remote extensions/apis that no one else can use)- https://github.com/microsoft/vscode/issues/48279 Finally, this is the thread where you will see regular users being negatively impacted by the DRM (a closed source, non-statically linked proprietary binary downloaded at runtime) that implements this proprietary-ness: https://github.com/microsoft/vscode-remote-release/issues/10... (of course, also with enough details to potentially patch around this issue if you were so inclined). Further, MS acknowledged that statically linking would help in May, and yet it appears to still be an issue. I just hope they don't come after Eclipse Theia…” Microsoft releases Cascadia Code version 1909.16, the latest monospaced font for Windows Terminal and Visual Studio Code 12 Visual Studio Code extensions that Node.js developers will love [Sponsored by Microsoft] 5 developers explain why they use Visual Studio Code [Sponsored by Microsoft] 5 useful Visual Studio Code extensions for Angular developers Facebook releases PyTorch 1.3 with named tensors, PyTorch Mobile, 8-bit model quantization, and more

The switch from Python 2 to Python 3 has been rocky and all signs point to Python 3 pulling firmly into the lead. Python 3 is broadly compatible with several libraries and there's an encouraging rate of adoption by cloud providers for application support too as Python 2 reaches its EOL in 2020. But there are still plenty of efforts to keep Python 2 alive in one form or another. The default implementation of Python is open source, so it can easily be forked and maintained separately. Currently all major open source Python packages support Python 3.x and Python 2.7. Last year Python team updated users that Python 2.7 maintenance will stop in 2020. Originally, there was no official date but in March 2018, the team announced the date to be January 1, 2020. https://twitter.com/ThePSF/status/1160839590967685121 This means that the maintainers of Python 2 will stop supporting it even for security patches. There are many institutions and codebases who have not yet ported their code from Python 2 to Python 3. Hence, Python volunteers have created resources to help publicize and educate, but there's still more work that needs to be done. For which the Python Software Foundation has contracted with Changeset Consulting, to help communicate about the sunsetting of Python 2. The high-level goal for Changeset's involvement is to help users through the end of the transition, help with communication so volunteers are not overwhelmed, and help update public-facing assets so core developers are not overwhelmed. This will also require all the major Python projects to migrate to Python 3 and above. However, PyPy confirmed last week that they do not plan to deprecate Python 2.7 support as long as PyPy exists, according to the official Twitter statement. https://twitter.com/pypyproject/status/1160209907079176192 Apart from this, PyPy runtime is popular among developers due to its built-in JIT which provides major speed boosts to Python code. Pypy has long favored Python 2 over Python 3. This favoritism isn't solely because the first versions of PyPy were Python 2 implementations and Python 3 has only recently entered the picture. It's also due to a key part of PyPy's ecosystem, RPython which is a dynamic language implementation framework has its foundation in Python 2. This is not likely to change, according to PyPy's official FAQ. The page states, “the Python 2 version of PyPy will be around 'forever', i.e. as long as PyPy itself is around.” According to Pypy’s official announcement it will support Python 3 while continuing to support Python 2.7 version. Last year when Python rolled out the announcement that Python 2 will officially end in 2020, users on Hacker News discussed about the most popular packages being compatible with Python 3 while millions of people in the industry still work on Python 2.7. One of the users comments read, “most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm not kidding) our software (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of people in the industry is 2.7. And we are a tiny focused industry. So I'm sure there are many other industries like us which are 2.7 that you never heard of. That's why "most popular" mean nothing once you take how Python is used as a whole. We don't use any of this web/Internet/network "popular" packages. I'm not saying Python shouldn't move on. I'm just trying to argue against this "most popular packages" while millions of us, even if you don't know it, use none of those. GNU Radio 3.8.0.0 releases with new dependencies, Python 2 and 3 compatibility, and much more! NumPy 1.17.0 is here, officially drops Python 2.7 support pushing forward Python 3 adoption Python 3.8 new features: the walrus operator, positional-only parameters, and much more

Project Valhalla is an OpenJDK project started in 2014 in an experimental stage. It is headed by Oracle Java language architect Brian Goetz and supported by the HotSpot group. The project was created for introducing value-based optimizations to JDK 10 and above. The goal of Project Valhalla is explore and support development of advanced Java VM and language features like, value types, generic specialization, and variable handles. The Project Valhalla members met last week at Burlington MA to discuss in detail about the current project status and future plans. Goetz notes that it was a very productive meeting with members either attending the venue in person or connecting via calls. After over four years of the project, the members decided to meet as it seemed like a good time to assess the project. Goetz states: “And, like all worthwhile projects, we hadn't realized quite how much we had bitten off.  (This is good, because if we had, we'd probably have given up.)” This meeting indicates the initiation of Phase III project Valhalla. Phase I focused on language and libraries. Trying to figure out what exactly a clean migration to value types and specialized generics would look like. This included steps to migrate core APIs like Collections and Streams, and understanding the limitations of the current VM. This enabled a vision for the VM that was needed. Phase I produced three prototypes, Models 1-3. The exploration areas of these models included specialization mechanics (M1), handling of wildcards (M2) and classfile representations for specialization and erasure (M3). At this point, the list of VM requirements became too long and they had to take a different approach. Phase II took on the problem from the VM up, with two additional rounds of prototypes namely MVT and LW1. LW1 was a risky experiment; sharing the L-carrier and a* bytecodes between references and values while not losing performance. If this could be achieved, many of the problems from Phase I could go away.  This was successful and now they have a richer base for further work. The next target is L2, which will capture the choices made so far, provide a useful testbed for doing library experiments, and set the stage for tackle remaining open questions between now and L10.  L10 is the target for a first preview, which eventually should support value types and erased generics over values. For more information, you can read the mail on Project Valhalla mailing list. JDK 12 is all set for public release in March 2019 State of OpenJDK: Past, Present and Future with Oracle No more free Java SE 8 updates for commercial use after January 2019

On Monday, the CEO and Co-founder of Dark, Ellen Chisa, announced the project had raised $3.5 million in funding in a Medium post. Dark is a holistic project that includes a programming language (Darklang), an editor and an infrastructure. The value of this, according to Chisa, is simple: "developers can code without thinking about infrastructure, and have near-instant deployment, which we’re calling deployless." Along with Chisa, Dark is led by CTO, Paul Biggar, who is also the founder of CircleCI, the CI/CD pioneering company. The seed funding is led by Cervin Ventures, in participation with Boldstart, Data Collective, Harrison Metal, Xfactor, Backstage, Nextview, Promus, Correlation, 122 West and Yubari. What are the key features of the Dark programming language? One of the most interesting features in Dark is that deployments take a mere 50 milliseconds. Fast. Chisa says that currently the best teams can manage deployments around 5–10 minutes, but many take considerably longer, sometimes hours. But Dark was designed to change this. It's purpose-built, Chisa seems to suggest, for continuous delivery. “In Dark, you’re getting the benefit of your editor knowing how the language works. So you get really great autocomplete, and your infrastructure is set up for you as soon as you’ve written any code because we know exactly what is required.” She says there are three main benefits to Dark’s approach: An automated infrastructure No need to worry about a deployment pipeline ("As soon as you write any piece of backend code in Dark, it is already hosted for you,” she explains.) Tracing capabilities are built into your code. "Because you’re using our infrastructure, you have traces available in your editor as soon as you’ve written any code. There's undoubtedly a clear sense - whatever users think of the end result - that everything has been engineered with an incredibly clear vision. Dark has been deployed on SaaS platform and project tracking tools Chisa highlights how some customers have already shipped entire products on Dark. Chase Olivieri, who built Altitude, a subscription SaaS providing personalized flight deals, using Drark is cited by Chisa, saying that "as a bootstrapper, Dark has allowed me to move fast and build Altitude without having to worry about infrastructure, scaling, or server management." Downside of Dark is programmers have to learn a new language Speaking to TechCrunch, Chisa admitted their was a downside to Dark - you have to learn a new language. "I think the biggest downside of Dark is definitely that you’re learning a new language, and using a different editor when you might be used to something else, but we think you get a lot more benefit out of having the three parts working together." Chisa acknowledged that it will require evangelizing the methodology to programmers, who may be used to employing a particular set of tools to write their programs. But according to her the biggest selling point is that it will remove the complexity around deployment by bringing an integrated level of automation to the process. Is Darklang basically like AWS Lambda? The community on Hacker News compares Dark with AWS Lambda, with many pessimistic about its prospects. In particular they are skeptical about the efficiency gains Chisa describes. "It only sounds maybe 1 step removed from where aws [sic] lambda’s are now," said one user. "You fiddle with the code in the lambda IDE, and submit for deployment. Is this really that much different?” Dark’s Co-founder, Paul Biggar responded to this in the thread. “Dark founder here. Yes, completely agree with this. To a certain extent, Dark is aimed at being what lambda/serverless should have been." He continues by writing: "The thing that frustrates me about Lambda (and really all of AWS) is that we're just dealing with a bit of code and bit of data. Even in 1999 when I had just started coding I could write something that runs every 10 minutes. But now it's super challenging. Why is it so hard to take a request, munge it, send it somewhere, and then respond to it. That should be trivial! (and in Dark, it is)" The team has planned to roll out the product publicly in September. To find out more more about Dark, read the team's blog posts including What is Dark, How Dark is a functional language, and How Dark allows deploys in 50ms. The V programming language is now open source – is it too good to be true? “Why was Rust chosen for Libra?”, US Congressman questions Facebook on Libra security design choices Rust’s original creator, Graydon Hoare on the current state of system programming and safety