Tech News - Languages

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

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

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

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

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

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

Yesterday, Kent C. Dodds, a JavaScript engineer at PayPal, shared in a post that now every app created at PayPal uses TypeScript by default replacing its previous type checker, Flow.  He also shared why it took them so much time to migrate to TypeScript and what are the drawbacks of using Flow which TypeScript solves. Dodds works on a toolkit called paypal-scripts, which is a package of all the tools common to PayPal applications and published modules. It was created to replace the huge list of devDependencies in the package.json and all the config files with a single entry in the devDependencies. Keeping all the tools and config in a single package, also made updating very easier. Now, this paypal-scripts module is also merged with their base GitHub repo named “sample-app”, to ensure that every new application will get their start with modern technology and tools. These applications will also be statically typed with TypeScript and tested with Jest. It took Dodds so long to adopt TypeScript because he was hesitant towards leaving Babel and ESLint. He was using these tools for several years and enjoyed building custom plugins for both. Also, earlier, TypeScript users faced some challenges when using Babel and ESLint. A common theme was that Babel users found it difficult to set up TypeScript. The linting experience also needed some improvement, so the TypeScript team started working on improving TypeScript’s compatibility for ESLint. This meant for Dodds that he did not have to give up these tools to adopt TypeScript, and that is why he decided to replace Flow with TypeScript. Dodds mentions that the regular unreliability of Flow made him take this decision. Explaining the challenges, he wrote, “The editor plugins only sometimes worked (full disclosure, I never tried Nuclide and maybe my life would’ve been different if I had, but I tried Flow in Atom and VSCode) and I would get issues like the one all the time. It was incredibly frustrating because I could never trust my type checker. There were other issues as well.” Read more in detail on Kent C. Dodds’ post: Why every new web app at PayPal starts with TypeScript. Future of ESLint support in TypeScript The Angular 7.2.1 CLI release fixes a webpack-dev-server vulnerability, supports TypeScript 3.2 and Angular 7.2.0-rc.0 Announcing ‘TypeScript Roadmap’ for January 2019- June 2019

In a blog post, the ESLint team talks about the future of ESLint on TypeScript. Earlier, the TypeScript team talked about their future and including ESLint into their repository to improve compatibility between the two. Based on the feedback from the TypeScript community, it was discovered that the linting experience was not that good in TypeScript. They then announced support for both ESLint and TSLint. The former worked well with TypeScript while TSLint would cause duplicate work and induce some breaking changes. Also, some lint rules were not present in TSLint. Hence the focus has been on incorporating ESLint. Many members from the ESLint team have been working to improve its compatibility with TypeScript. The focus of this earlier work was on the TypeScript parser and typescript-eslint-parser. Other than that there were efforts also on eslint-plugin-typescript which was maintained by individual team members. The Typescript parser will become an important part in the integration of the two and the ESLint teams want to ensure its proper maintenance. The typescript-eslint project A key contributor working on ESLint compatibility in TypeScript, James Henry started the typescript-eslint project as a centralized repository. It contains all things pertaining to TypeScript ESLint compatibility and will be housing TypeScript parser, eslint-plugin-typescript, and other utilities that aid in the TypeScript ESLint integration. However, the ESLint team itself won’t be formally a part of this project but seem to be supportive of Henry’s efforts. ESLint’s future in TypeScript The ESLint official team will no longer maintain the typescript-eslint-parser. The repository is now archived and there will be no future released of typescript-eslint-parser in npm. Users who are using typescript-eslint-parser are advised to switch to @typescript-eslint/parser. The typescript-eslint repository will be updated for any new developments on ESLint support in TypeScript. Announcing ‘TypeScript Roadmap’ for January 2019- June 2019 TypeScript 3.2 released with configuration inheritance and more Introducing ReX.js v1.0.0 a companion library for RegEx written in TypeScript

Yesterday, the Rust team announced the release of Rust 1.32 in a blog post. The new version of the Rust programming language brings improvements to the quality of life, switches to the default allocator, and makes more functions const. Addition of the dbg macro in Rust 1.32 If you are a “print debugger”, you must have wanted to print out some value while working on code. Using something like println!("{:?}", x); isn’t fast enough. It is also a bit too much just to simply show the value of x. Also, there is no context here, if there are several println! statements, it is hard to distinguish between them. Rust now has a new package called dbg specifically for this purpose: fn main() {    let x = 5;       dbg!(x); } On running the above code, you will get: [src/main.rs:4] x = 5 In the output, you will see the file, line number, name, and value. While println! prints to the standard output, the dbg! function prints to the stderr. dbg! even works in more complex circumstances like factorial, iterations, etc. jemalloc is removed in Rust 1.32 In Rust’s initial years, it had a large Erlang type runtime. The developers then chose jemalloc instead of the system allocator for better performance. Over time, most of this runtime was removed except jemalloc. jemalloc was kept for users who would still need it. While it has great performance in most cases, it was not always the case. It adds 300kb to every Rust binary and has other issues. The core developers also thought it was strange that a systems language does not default to the system allocator. Hence Rust 1.28 had shipped with a global allocator. The work for using a system allocator is now finished and it can be used for all Rust programs now. jemalloc can still be used if you want to, via a crate in the Cargo.toml. Module improvements The last two Rust releases had some performance improvements to the module system. Rust 1.32 comes with something called “uniform paths” which allows import path statements to be resolved the same way as non-import paths. This was previously invalid. Efforts to revise the system module is now complete and the following code will now work. enum Color { Red, Green, Blue } use Color::*; Macro improvements A new literal string matcher is added. It matches against literals of any type. This includes string literals, numeric literals, and char literals. In Rust 2018 edition, macro_rules can also use ? to match 0 or 1 repetitions of the pattern. Library changes Other than the dbg! library, 19 functions were made cont. Now, all integral numeric primitives give conversion functions to and from byte-arrays that have specified endianness. There are six functions named as: to_<endian>_bytes and from_<endian>_bytes, in which <endian> is one of the following: ne - native endianness le - little endian be - big endian Cargo now has cargo_c as an alias for cargo_check and now usernames in registry URLs are allowed. These were the highlights of the changes in Rust 1.32, for a complete list of changes and fixes, visit the release notes. How has Rust and WebAssembly evolved in 2018 Rust Survey 2018 key findings: 80% developers prefer Linux, WebAssembly growth doubles, and more Red Hat announces full support for Clang/LLVM, Go, and Rust

In a blog post yesterday, Elixir 1.8 was announced. It comes with a variety of infrastructure level improvements, faster compilation time, common patterns, and added features around introspection of the system. Elixir is a functional general-purpose programming language that runs on top of the Erlang virtual machine. Custom struct inspections with Elixir 1.8 Elixir 1.8 has a derivable implementation of the Inspect protocol. This makes it simpler to filter data from existing data structures whenever they are inspected. If there is a user struct containing security and privacy sensitive information inspecting a user via inspect(user), will include all fields. This can cause information like emails and encrypted passwords to appear in logs or error reports. Defining a custom implementation of the Inspect protocol avoided this behavior. Elixir v1.8 makes it easier by allowing users to derive the Inspect protocol. Due to this, all user structs will be printed while all remaining fields are collapsed. Passing @derive {Inspect, except: [...]} will keep all fields by default and exclude only some. Custom time zone database support Elixir v1.8 defines a Calendar.TimeZoneDatabase behaviour that allows developers to add their own time zone databases. An explicit contract for time zone behaviours are defined, as a result, Elixir can now extend the DateTime API. This allows addition of functions like DateTime.shift_zone/3. The default time zone database in Elixir is Calendar.UTCOnlyTimeZoneDatabase which can only handle UTC. In other Calendar related improvements, Date.day_of_year/1, Date.quarter_of_year/1, Date.year_of_era/1, and Date.day_of_era/1 are added. Speedy compilation and performance improvements Improvements to the compiler have been made over 2018 which makes Elixir v1.8 compile code about 5% faster. The Elixir compiler also emits more efficient code used for range checks in guards, charlists with interpolation, and when working with records via the Record module. EEx templates are also optimized and emit more compact code which also runs faster. Better instrumentation and ownership with $callers The Task module is a way to spawn light-weight processes to perform concurrent work. When a new process is spawned, Elixir annotates the parent process via the $ancestors key. Instrumentation tools can use this information to track the relationship between events occurring within multiple processes. But many times tracking only $ancestors is not sufficient. Developers are recommended to start tasks under a supervisor, as it gives more visibility and control of task termination when a node shuts down. The relationship between code and the task is tracked via the $callers key present in the process dictionary. This aligns well with the existing $ancestors key. In Elixir 1.8 when a task is spawned directly from code without a supervisor, the parent process of the code will be listed under $ancestors and $callers. This feature allows instrumentation and monitoring tools to better track and relate the events in the system. This can also be used by the Ecto Sandbox which enables developers to run concurrent test against the database. It uses transactions and an ownership mechanism in which each process explicitly gets a connection assigned to it These were the major changes, for full list of improvements and bug fixes, you can take a look at release notes. Elixir Basics – Foundational Steps toward Functional Programming Erlang turns 20: Tracing the journey from Ericsson to Whatsapp Python governance vote results are here: The steering council model is the winner

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?    

Adding to the list of Python-like programming languages is Coconut that allows developers write simple and elegant functional code, while using the familiar Python environment and libraries. It is basically a superset of Python that adds on top of Python syntax and is inspired by programming languages like Haskell, CoffeeScript, F#, and patterns.py. The language is written by Evan Hubinger, an undergraduate student studying mathematics and computer science at Harvey Mudd College. Why Coconut was developed? Writing functional programs in Python can be challenging at times. While Python does allow developers to write high-order functions, it lacks concise syntax for lambdas, boilerplate-less pattern matching, etc. One Hacker News user mentioned, “It's capable of functional programming in the sense that functions are first class values that you can pass around, but it is infamously hostile to functional programming. For example, Python still doesn't have multiline lambdas, and the justifications for why always boil down to it being "unpythonic".” This is what Coconut tries to solve by bringing tools of modern functional programming. It provides a clean -> operator replacing Python’s lambda statements. It supports pipeline-style programming, partial application, pattern-matching, destructuring assignment, parallel programming, and more. To provide optional static type-checking you can integrate Coconut with MyPy, which is an optional static type checker for Python. But, it is not purely functional that allows programmers to choose whatever programming style they are comfortable with. As it is a variant of Python, developers who have experience in working on Python will not have much difficulty in learning it. Coconut code are compiled to Python code. Developers can access the Coconut compiler through its command-line utility, which also comes with an interpreter to enable real-time compilation. Additionally, it also supports the use of IPython/Jupyter notebooks. What are the Python version it supports? It supports these Python versions: >= 2.6 on the 2.x branch or >= 3.2 on the 3.x branch. To make Coconut built-ins universal across Python versions, it automatically overwrites Python 2 built-ins with their Python 3 counterparts. It also overwrites some Python 3 built-ins for optimization and enhancement purposes. If developers want to access the original Python versions of any overwritten built-ins, they can retrieve the old built-in by prefixing them with py_. pandas will drop support for Python 2 this month with pandas 0.24 Qt for Python 5.12 released with PySide2, Qt GUI and more Google researchers introduce JAX: A TensorFlow-like framework for generating high-performance code from Python and NumPy machine learning programs

Scratch 3.0 was released yesterday. Scratch is an environment aimed to teach basic programming logic to kids with blocks and cartoon-ish characters and scenes. Yesterday, Scratch 3.0 officially became a part of the Scratch online community. Scratch 3.0 new features There are various new sprites, backgrounds, and sounds for users to play with. A new extension library lets users add new sets of blocks that connect to hardware and software components to do more tasks with Scratch A new sound editor New programming blocks Support for tablets, hence the blocks in Scratch 3.0 are bigger Users can add collections of extra blocks the developers call ‘extensions’ Among existing blocks new ones are added for sound effects, operators to make string operations easier, new pen blocks and a new glide block to move a sprite. The paint editor has a new layout that increases the visibility of tools and options, an eraser tool, more color options, better control over vector points, more controls for ordering layers, and new gradient controls. With the sound editor in Scratch 3.0, you can now record sounds, trim audio with more ease, and explore new sound effects. General reactions to Scratch Comments from Hacker news are positive for Scratch: “Scratch is pretty great, and at least 3 of my kids constantly ask if they can play Scratch.” “Scratch (and similar programming environments) is a very successful way to introduce children to programming and I hope that it continues to do so.” Any of your old projects can be found at https://scratch.mit.edu/mystuff/. You can check out Scratch at the MIT website. Ruby 2.6.0 released with a new JIT compiler Python governance vote results are here: The steering council model is the winner NumPy drops Python 2 support. Now you need Python 3.5 or later.

Ruby 2.6.0 was released yesterday and brings a new JIT compiler. The new version also has the RubyVM::AbstractSyntaxTree module. The new JIT compiler in Ruby 2.6.0 Ruby 2.6.0 comes with an early implementation of a Just-In-Time (JIT) compiler. The JIT compiler was introduced in Ruby to improve the performance of programs made with Ruby. Traditional JIT compilers operate in-process but Ruby’s JIT compiler gives out C code to the disk and generates a common C compiler to create native code. To enable the JIT compiler, you just need to specify --jit either on the command line or in the $RUBYOPT environment variable. Using --jit-verbose=1 will cause the JIT compiler to print additional information. The JIT compiler will work only when Ruby is built by GCC, Clang, or Microsoft Visual C++. Any of these compilers need to be available at runtime. On Optcarrot, a CPU intensive benchmark, Ruby 2.6 has 1.7x faster performance compared to Ruby 2.5. The JIT compiler, however, is still experimental and workloads like Rails might not benefit from for now. The RubyVM::AbstractSyntaxTree module Ruby 2.6 brings the RubyVM::AbstractSyntaxTree module and the team does not guarantee any future compatibility of this module. The module has a parse method, which parses the given string as Ruby code and returns the Abstract Syntax Tree (AST) nodes in the code. The given file is opened and parsed by the parse_file method as Ruby code, this returns AST nodes. A RubyVM::AbstractSyntaxTree::Node class—another experimental feature—is also introduced in Ruby 2.6.0. Developers can get source location and children nodes from the Node objects. To know more about other new features and improvements in detail, visit the Ruby 2.6.0 release notes. 8 programming languages to learn in 2019 Clojure 1.10 released with Prepl, improved error reporting and Java compatibility NumPy drops Python 2 support. Now you need Python 3.5 or later.

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]