Tech News - Languages

Yesterday, at the ongoing Code BEAM SF event, the formation of Erlang Ecosystem Foundation (EFF) was announced. Its founding members, Jose Valim, Peer Stritzinger, Fred Hebert, Miriam Pena, and Francesco Cesarini spoke about its journey, importance, and goals. The proposal for creating EEF was submitted last year in December to foster the Erlang and Elixir ecosystem. https://twitter.com/CodeBEAMio/status/1101310225804476416 Code BEAM SF, formerly known as Erlang & Elixir Factory, is a two-day event commenced on Feb 28. This conference brings together the best minds in the Erlang and Elixir communities to discuss the future of these technologies. The purpose of the Erlang Ecosystem Foundation EEF is a non-profit organization for driving the further development and adoption of Erlang, Elixir, LFE, and other technologies based on BEAM, the Erlang virtual machine. Backed by companies like Cisco, Erlang solutions, Ericsson, and others, this foundation aims to grow and support a diverse community around the Erlang and Elixir Ecosystem. This foundation will encourage the development of technologies and open source projects based on BEAM languages. “Our goal is to increase the adoption of this sophisticated platform among forward-thinking organizations. With member-supported Working Groups actively contributing to libraries, tools, and documentation used regularly by individuals and companies relying on the stability and versatility of the ecosystem, we actively invest in critical pieces of technical infrastructure to support our users in their efforts to build the next generation of advanced, reliable, real-time applications,” says the official EEF website. EEF will also be responsible for sponsoring the working groups to help them solve the challenges users of BEAM technology might be facing, particularly in areas such as documentation, interoperability, and performance. To know more about Erlang Ecosystem Foundation in detail, visit its official website. Erlang turns 20: Tracing the journey from Ericsson to Whatsapp Elixir 1.7, the programming language for Erlang virtual machine, releases Introducing Mint, a new HTTP client for Elixir

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  

Last year, the steering council model was elected for Python governance. Now the results for the steering council election, January 2019 are out in PEP 8100. First some background about the steering council model: “Authored by Nathaniel J. Smith, and Donald Stufft, this proposal involves a model for Python governance based on a steering council. The council has vast authority, which they intend to use as rarely as possible, instead, they plan to use this power to establish standard processes. The steering council committee consists of five people. A general philosophy is followed—it’s better to split up large changes into a series of small changes to be reviewed independently. As opposed to trying to do everything in one PEP, the focus is on providing a minimal and solid foundation for future governance decisions. This PEP was accepted on December 17, 2018.” The goals of the model are to be: Boring, stick to the basics and not experiment Simplistic enough for a minimum viable product Comprehensive to avoid confusion Flexible and light-weight Of the 96 eligible voters, only 69 had cast ballots. The nomination period for the election was from January 7, 2019 to January 20, 2019. The voting period was from January 21, 2019 to February 4, 2019. The results are in and the top five candidates are: Barry Warsaw Brett Cannon Carol Willing Guido van Rossum Nick Coghlan Now, these five individuals are a part of the steering council for Python governance. The council will make decisions on PEPs. They will also work on maintaining the stability, quality of the Python language and interpreter. Python governance vote results are here: The steering council model is the winner NYU and AWS introduce Deep Graph Library (DGL), a python package to build neural network graphs Introducing RustPython, a Python 3 interpreter written in Rust

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

We recently asked whether Dart programming was dead, but news of its death might well have been exaggerated. Version 2 of the programming language has just been released, with a range of updates and changes that should cement its popularity with admirers and win new users too. With Dart playing a big part in Google's much-anticipated Flutter and Fuchsia projects, there's a possibility that version 2.0 represents a brand new chapter in Dart's life. News of a Dart 'reboot' first emerged in February 2018. Anders Thorhauge Sandholm said at the time that “with Dart 2, we’ve dramatically strengthened and streamlined the type system, cleaned up the syntax, and rebuilt much of the developer tool chain from the ground up to make mobile and web development more enjoyable and productive.” It would appear that six months later the team have finally delivered on their promise. They'll be hoping it makes a positive impact on the language's wider adoption. What's new in Dart 2.0? There's a whole host of changes that Dart developers will love, all of which can be found in the changelog on GitHub. Most notable is a stronger typed system, which includes runtime checks that will capture errors more effectively, and, for those developers working on Flutter, you can now create an instance of a class without using the "new" keyword. Among other updates, other key changes to Dart include: "Functions marked async now run synchronously until the first await statement. Previously, they would return to the event loop once at the top of the function body before any code runs." "Constants in the core libraries have been renamed from SCREAMING_CAPS to lowerCamelCase." "...New methods have been added to core library classes. If you implement the interfaces of these classes, you will need to implement the new methods." All the changes you'll find in Dart 2.0 amount to the same thing: improving the developer experience and making the code more readable. The obvious context to all this 'reboot' is that Google is betting on the growth of Flutter and Fuchsia over the next few years. With these improvements, it's possible that we'll begin to see Dart's fortunes changing. CodeMentor may have called Dart the 'worst programming language to learn in 2018' at the start of the year, but it will be interesting to see if it's popularity has grown by the time we hit 2019. You can download Dart 2.0.0 for Windows, Mac, and Linux here.

Yesterday, PyPy 7.0 was announced in a blog post. It is a triple release for different Python versions. PyPy is a compliant Python interpreter which can be considered a replacement for CPython 2.7, 3.5, and 3.6. It’s faster due to the integrated tracing JIT compiler. The release supports x86 machines with common OSes, PPC64, and s390x running Linux. Since the ARM buildbots are out of service currently, binaries for ARM architecture will not be released. PyPy 7.0 includes the following interpreters. PyPy2.7 is an interpreter with support for syntax and features of Python 2.7 which will lose official support next year. PyPy3.5, supports the stable Python 3.5 PyPy3.6-alpha which is the first official PyPy release supporting 3.6 features. All of the three interpreters share a similar codebase allowing this triple release. Until packages can be distributed downstream, wheel (whl) packages are available for some common packages. GC hooks has been improved. It’s now possible to manage the GC by using a combination of gc.disable and gc.collect_step manually. The cffi module included in PyPy has been updated to version 1.12. The cppyy backend is also updated to version 1.4. For a JIT friendly experience, use the new versions to wrap your C and C++ code. PyPy 7.0 is fully compatible with the previous version. Several issues and bugs raised by the PyPy community have been addressed. PyPy3 and Windows PyPy3.5 releases are not yet up to quality to be used in production. There are open issues and the compatibility is not complete. The utf8 branch to change the internal representation of unicode to utf8 will be added in one of the future releases. Python Software foundation and JetBrains’ Python Developers Survey 2018 Python steering council election results are out for January 2019 Introducing RustPython, a Python 3 interpreter written in Rust

Yesterday, Bob Davis, Senior Product Manager at Red Hat announced that Clang/LLVM, Go, and Rust will now enter “Full Support Phase”. The support lifecycle is changed after the General Availability (GA) of Clang/LLVM 6.0, Go 1.10, and Rust 1.29. Previously, these languages and tools were in “Technology Preview” status. They were provided for users to test their functionality and provide feedback. This was during the development process and there was no full supported under the Red Hat Subscription Level Agreements. They were not guaranteed to be functionally complete and were not intended for live production use. GA means that these products have now officially entered a phase to receive full support. Their website states that: “During the Full Support Phase, qualified Critical and Important Security errata advisories (RHSAs) and Urgent and Selected High Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.” On availability, support for new hardware and some enhanced software functionality may also be provided at the sole discretion of Red Hat. These are generally in minor releases. The minor releases will focus only on resolving defects/bugs. New installation images of the minor releases will be provided during this full support phase. As these packages are evolving fast, the support lifecycle will also have short intervals. This means that there will be quarterly updates to Rust, and updates every 6 months to LLVM and Golang. The support for them will be different than the usual long-term support LTS approach. For LLVM, Rust, and Go only the most recent build will be maintained. If an older version has a bug, the most recent build will be updated to fix it. If a bug is present in the current build, it will be addressed in the next scheduled build. That will be the next schedules minor release. For more details, visit the Red Hat Blog. The LLVM project is ditching SVN for GitHub. The migration to Github has begun. Golang just celebrated its ninth anniversary Rust 1.30 releases with procedural macros and improvements to the module system

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

Yesterday, the Rust team announced next version release of their systems programming language, Rust 1.29. Users using the previous versions of Rust installed via rustup, can easily get this latest version by a simple command: $ rustup update stable This Rust 1.29 release has lesser features. This is because the 1.29 cycle was spent preparing for the upcoming releases, Rust 1.30 and 1.31 that will have a lot more features in them. What’s new in Rust 1.29? This stable release of Rust has two most important improvements to Cargo, Rust’s package manager. The new improvements include cargo fix can automatically fix your code that has warnings cargo clippy is a bunch of lints to catch common mistakes and improve your Rust code cargo fix Rust 1.29 includes a new subcommand for Cargo known as cargo fix. This is the initial release of cargo fix that fixes a small number of warnings in the compiler. The compiler has an API for this, and it only suggests fixing lints that the team says, recommends correct code. Over time, cargo fix can be expanded based on user suggestions to automatically fix more warnings. cargo clippy Clippy has a large number of additional warnings that users can run against their Rust code. Users can now check out a preview of cargo clippy through Rustup, by the following command: $ rustup component add clippy-preview Clippy has not yet reached 1.0. However, its lints may change. The Rust team will release a clippy component once it has stabilized. Users can’t use clippy with cargo-fix yet, really. This is still in work in progress. Additional updates in Rust 1.29 The Rust version 1.29 also include some library stabilizations. The three APIs stabilized in this release are: Arc<T>::downcast Rc<T>::downcast Iterator::flatten Users can also compare &str and OsString. To have a detailed information on Rust 1.29, read its release notes. Deno, an attempt to fix Node.js flaws, is rewritten in Rust Working with Shared pointers in Rust: Challenges and Solutions [Tutorial] Rust Language Server, RLS 1.0 releases with code intelligence, syntax highlighting and more  

TensorFlow has continued its success in 2017 well into 2018. It's quickly expanding its capabilities, and we're beginning to see it used by engineers that aren't data specialists.  We've seen that in the launch of TensorFlow.js, which allows you to bring machine learning to the browser. But Swift for TensorFlow is a slightly different proposition. In fact, it does two things. On the one hand it offers a new way of approaching TensorFlow, but it also helps to redefine Swift. Let's be honest - Swift has come a long way since it was first launched by Apple back at WWDC 2014. Back then it was a new language created to reinvigorate iOS development. It was meant to make Apple mobile developers happier and more productive. That is, of course, a noble aim - and by and large it seems to have worked. If it hadn't we probably wouldn't still be talking about it. But Swift for TensorFlow marks Swift as a powerful modern programming language that can be applied to some of the most complex engineering problems. What is Swift for TensorFlow? Swift for TensorFlow was first unveiled at the TensorFlow Dev Summit in March 2018. Now it's open source, it's going to be interesting to see how it shapes the way engineers use TensorFlow - and, of course, how the toolchain might shift. But what is it exactly? Watch the video below, recorded at TensorFlow Dev Summit, to find out more. https://www.youtube.com/watch?v=Yze693W4MaU Here's what the TensorFlow team had to say about Swift for TensorFlow in a detailed post on Medium. "Swift for TensorFlow provides a new programming model that combines the performance of graphs with the flexibility and expressivity of Eager execution, with a strong focus on improved usability at every level of the stack. This is not just a TensorFlow API wrapper written in Swift — we added compiler and language enhancements to Swift to provide a first-class user experience for machine learning developers." Why did TensorFlow choose Swift? This is perhaps the key question: why did the TensorFlow team decide to use Swift for this project? The team themselves note that they are often asked this question themselves. Considering many of the features of Swift for TensorFlow can easily be implemented in other programming languages, it's a reasonable question to ask. To properly understand why TensorFlow chose Swift you need to go back to the aims of the project. And they're actually quite simple - the team want to make TensorFlow more usable. They explain: "We quickly realized that our core static analysis-based Graph Program Extraction algorithm would not work well for Python given its highly dynamic nature. This led us down the path of having to pick another language to work with, and we wanted to approach this methodically." The post on GitHub is well worth reading. It provides a detailed insight into how to best go about evaluating the advantages and disadvantages of one programming language over another. Incidentally, The TensorFlow team say the final shortlist of languages was Swift, Rust, Julia, and C++. Swift ended up winning out - there were 'usability concerns' around C++ and Rust, and compared to Julia not only was there a larger and more active community, it is also much more similar to Python in terms of syntax.

After the release of Boost 1.67.0 in April earlier this year, Boost 1.68.0 is now out with a new library named YAP and few updates in the libraries such as, Beast, Fusion, and GIL to name a few. Boost provides peer-reviewed portable C++ source libraries for generic programming, concurrency programming, metaprogramming, data structures, testing, and many more tasks and structures. YAP: The new expression template library YAP is an expression template library that aims to help developers in writing optimized and maintainable code. Some of its features include: Member and non-member functions on ExpressionTemplates and Expressions can be added with compact macros. A reference template that models ExpressionTemplate exists for prototyping or experimentation. The evaluation done by Boost.YAP closely matches the semantics of built-in C++ expressions, enabling clearer understanding of the semantics of expression evaluation. Expressions can be transformed explicitly in a user-defined way with the help of overloaded call operators in a transform class. The evaluate(transform(expr)) idiom is expected to be one of the most common ways of using YAP to manipulate and evaluate expressions. Boost.YAP provides functions that manipulate expressions or their subexpressions. Updated libraries in Boost 1.68.0 Beast: An executor work guard is added in all composed operations used in the implementation. To avoid crashes related to asynchronous completion handlers, users are encouraged to upgrade. Fusion: A workaround is added for ambiguous call of fusion::deque constructor on GCC 4.4/c++0x. A bug with C-style array is now fixed. Fixed a fusion::for_each signature to take functor by value. This may break existing code with non-copyable (non-movable) functor. Unintentional MPL placeholder substitution bug on fusion::transform is now fixed. GIL: C++11-compliant compiler is now required by the library. Its I/O extensions have been entirely rewritten. Math: Added support for arbitrary precision complex valued quadrature and hence contour integration. Added support for contour integrals. Performance of polynomial addition is improved. Multi-index Containers: Containers of moveable but non-copyable elements can now be serialized. The default constructor of multi_index_container is no longer explicit. Test: The master_test_suite_t object is no more copyable. Dataset test case can now use command line parameters. Uuid: Breaking change: sha1 detail namespace header redirection for backwards compatibility was removed. Added support for std::hash. Added support for move semantics on random generators. Properly handle EINTR when acquiring entropy. Use getrandom(2) instead of getentropy(3) on linux. These were some of the updates in Boost 1.68.0. To know more, head over to their official site. Working with shaders in C++ to create 3D games Understanding the Dependencies of a C++ Application Getting Inside a C++ Multithreaded Application

Yesterday, Google Cloud announced a new Go 1.11 runtime for the App Engine standard environment. This provides all the benefits of App Engine such as paying only for what you use, automatic scaling and managed infrastructure. Starting with Go 1.11, which was launched in August this year, Go on App Engine has no limits on application structure, supported packages, context.Context values, or HTTP clients. What are the changes in the Go 1.11 runtime as compared to Go 1.9? 1. Now, you can specify the Go 1.11 runtime in your app.yaml file by adding the following line: runtime: go111 2. Each of your services must include a package main statement in at least one source file. 3. The appengine build tag is now deprecated and will no longer be used when building an app for deployment. 4. The way you import dependencies has changed. You can specify the dependencies in this runtime by the following two ways: Putting your application and related code in your GOPATH. Or else, by creating a go.mod file to define your module. 5. Google App Engine now does not modify the Go toolchain to include the appengine package. Using Google Cloud client library or third party libraries instead of the App Engine-specific APIs is recommended. 6. You can deploy services that use the Go 1.11 runtime using the gcloud app deploy command. You can still use the appcfg.py commands the Go 1.9 runtime, but the gcloud command-line tool is preferred. This release of the Go 1.11 runtime in the App Engine uses the latest stable release of Go 1.11 and will automatically update to new minor versions upon deployment but will not for any major versions. Also, it is currently in beta and might be changed in backward-incompatible ways in future. You can read more about Go 1.11 runtime on The Go Blog and also the documentation published by Google. Golang plans to add a core implementation of an internal language server protocol Why Golang is the fastest growing language on GitHub Golang 1.11 is here with modules and experimental WebAssembly port among other updates

Elixir 1.7 has been released. Elixir builds on top of Erlang designed for building scalable and maintainable applications. This release is focused on improving error handling, logger reporting, and documentation. It also brings improvements to ExUnit, Elixir’s testing library. ExUnit improvements ExUnit is Elixir’s unit testing library. ExUnit uses Elixir macros to provide error reports when a failure happens using the assert macro. The assert macro can look at the code, extract the current line, extract the operands and show a difference between the data structures alongside the stacktrace when the assertion fails. However, for certain ‘bare’ assertions, ExUnit usually re-runs the tests, debugging or printing the values. In Elixir 1.7, now, whenever a “bare” assertion will fail, it will print the value of each argument individually. E.g, For a simple example such as assert some_vars(1 + 2, 3 + 4), users will get this report: Their build tool Mix has also received new updates. There is a new --failed flag that runs all tests that failed the last time they ran. The coverage reports generated with mix test --cover includes a summary out of the box. Updates to the ExDoc tool ExDoc is a tool to generate documentation for user Elixir projects. It leverages metadata to provide better documentation for developers. These are the updates to ExDoc. Deprecated modules, functions, callbacks, and types now have a warning automatically attached to them. Functions, macros, callbacks, and types now include the version in which they were added. Future Elixir versions will include their own section for guards in the documentation and in the sidebar. They are currently exploring ways to generalize this feature in ExDoc itself. Erlang/OTP logger integration improvements Elixir 1.7 fully integrates with the new :logger module available in Erlang/OTP 21. The Logger.Translator mechanism has also been improved to export metadata, allowing custom Logger backends to leverage information such as: :crash_reason, a two-element tuple with the throw/error/exit reason as the first argument and the stacktrace as the second. :initial_call, the initial call that started the process. :registered_name, the process’ registered name as an atom. Updates to Logger configuration system From Elixir 1.7 the Logger macros such as debug, info, will evaluate their arguments only when the message is logged. The Logger configuration system also accepts a new option: compile_time_purge_matching that allows users to remove log calls with specific compile-time metadata. There are also certain developments in areas not directly related to the Elixir codebase. A new Development section has been added to the website, that outlines the Elixir team structure and goals. It also now has its own mini-documentary. Read the Elixir-lang blog for the full list of Elixir 1.7 updates. You can also check the Install section to get Elixir installed and read the Getting Started guide to learn more. Elixir Basics – Foundational Steps toward Functional Programming 5 Reasons to learn programming

Splinter, the open source tool for testing web applications using Python has now leveled up to Splinter 0.9.0. Browser actions such as visiting URLs and interacting with their items can be automated. Apart from providing a simple api, Splinter has multiple webdrivers including chrome webdriver, firefox webdriver, phantomjs webdriver, zopetest browser, and remote webdriver. It provides support to iframe, alert and executes javascript while working with both, ajax and async javascript. Two ways to install Splinter 0.9.0 Step 1: Install Python In order to install Splinter, you need to make sure that Python 2.7+  is installed. Step 2: Install Splinter There are two ways to install Splinter: Install a stable release For an official and almost bug-free version, use the terminal: $ [sudo] pip install splinter Install under-development source-code For splinter’s latest-and-greatest features and aren’t afraid of running under development code, run: $ git clone git://github.com/cobrateam/splinter.git $ cd splinter $ [sudo] python setup.py install Head over to the install guide for additional notes. Upgraded features in Splinter 0.9.0 Support for phantomjs is removed. With Chrome and Firefox headless, phantom is no longer needed. Users can now add custom options to the chrome browser. The bug related to element.find_by_text  stands resolved. When trying to do a contextual search for text, the result would include all matching text for the whole DOM instead of just those nodes that are children of the contextual node. Support was added for zope.testbrowser 5+, Flask 1+, selenium 3.14.0. Splinter can now handle webdriver StaleElementReferenceException. The lxml and cssselect has been updated  to 4.2.4  1.0.3 respectively. For a detailed explanation of features visitits  Github page. Visual Studio code July 2018 release, version 1.26 is out! OpenSSH 7.8 released! JDK 11 First Release Candidate (RC) is out with ZGC, Epsilon and more!  

Yesterday, the team at Gophers released Go 1.12rc1, a release candidate version of Go 1.12. This release comes with improved runtime, updated libraries, ports and more. What’s new in Go 1.12rc1 Trace In Go 1.12rc1, the trace tool supports plotting mutator utilization curves, including cross-references to the execution trace. These are used to analyze the impact of the garbage collector on application latency and throughput. Assembler On arm64, the platform register was renamed from R18 to R18_PLATFORM to prevent accidental use, as the OS could choose to reserve this register. Runtime This release improves the performance of sweeping when a large fraction of the heap remains live. This reduces allocation latency following a garbage collection.The Go runtime now releases memory back to the operating system and particularly in response to large allocations that can't reuse existing heap space. In this release, the runtime’s timer and deadline code is faster and scales better with higher numbers of CPUs. It also improves the performance of manipulating network connection deadlines. Ports With this release, the race detector is now supported on linux/arm64. Go 1.12rc1 is supported on FreeBSD 10.x. Windows The new windows/arm port supports Go on Windows 10 IoT Core on 32-bit ARM chips such as the Raspberry Pi 3. AIX This release supports AIX 7.2 and later on POWER8 architectures (aix/ppc64). Though external linking, pprof, cgo, and the race detector aren't yet supported. Darwin This one is the last release to run on macOS 10.10 Yosemite, as Go 1.13 will need macOS 10.11 El Capitan or later. libSystem is now used while making syscalls on Darwin, which ensures forward-compatibility with future versions of macOS and iOS. This switch to libSystem has triggered additional App Store checks for private API usage. Tools The go tool vet is no longer supported. With this release, the go vet command has been rewritten to serve as the base for a range of different source code analysis tools. Even the external tools that use go tool vet must be changed to use go vet. Using go vet instead of go tool vet will work with all supported versions of Go. Even the experimental -shadow option is no longer available with go vet. Build cache requirement The build cache is now used for eliminating $GOPATH/pkg. With Go 1.12rc1, setting the environment variable GOCACHE=off will cause go commands to fail. Binary-only packages This one is the last release that will support binary-only packages. Cgo This release translates the C type EGLDisplay to the Go type uintptr. In this release, mangled C names are no longer accepted by the packages that use Cgo. The Cgo names are used now instead. Minor changes to the library Bufio: In this release, the reader's UnreadRune and UnreadByte methods will now return an error if they are called after Peek. Bytes: This release comes with a new function, ReplaceAll that returns a copy of a byte slice with all non-overlapping instances of a value replaced by another. To know more about this news, check out the official post. Introduction to Creational Patterns using Go Programming Go Programming Control Flow Essential Tools for Go Programming