Language Selection

English French German Italian Portuguese Spanish

Rust 1.39.0 Release and Beyond

Filed under
Development
  • Announcing Rust 1.39.0

    The Rust team is happy to announce a new version of Rust, 1.39.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.

    [...]

    The highlights of Rust 1.39.0 include async/.await, shared references to by-move bindings in match guards, and attributes on function parameters. Also, see the detailed release notes for additional information.

  • Rust 1.39.0 released

    Version 1.39.0 of the Rust language is available. The biggest new feature appears to be the async/await mechanism, which is described in this blog post: "So, what is async await? Async-await is a way to write functions that can 'pause', return control to the runtime, and then pick up from where they left off. Typically those pauses are to wait for I/O, but there can be any number of uses."

  • Async-await on stable Rust!

    On this coming Thursday, November 7, async-await syntax hits stable Rust, as part of the 1.39.0 release. This work has been a long time in development -- the key ideas for zero-cost futures, for example, were first proposed by Aaron Turon and Alex Crichton in 2016! -- and we are very proud of the end result. We believe that Async I/O is going to be an increasingly important part of Rust's story.

    While this first release of "async-await" is a momentous event, it's also only the beginning. The current support for async-await marks a kind of "Minimum Viable Product" (MVP). We expect to be polishing, improving, and extending it for some time.

    Already, in the time since async-await hit beta, we've made a lot of great progress, including making some key diagnostic improvements that help to make async-await errors far more approachable. To get involved in that work, check out the Async Foundations Working Group; if nothing else, you can help us by filing bugs about polish issues or by nominating those bugs that are bothering you the most, to help direct our efforts.

  • Support lifecycle for Clang/LLVM, Go, and Rust in Red Hat Enterprise Linux 8

    The Go and Rust languages continue to evolve and add new features with each compiler update, which is why so many users are interested in getting the latest versions of the compilers. At the same time, these compilers are designed to remain compatible with older code. So, even as we advance to newer versions of Go and Rust within the RHEL 8 application streams, you should not need to update your codebase to keep it compilable. Once you’ve compiled your valid code using the Go or Rust application stream, you can make the assumption that it will continue to compile with that stream for the full life of RHEL 8.

    We are excited to continue to bring you the latest and greatest in new compiler technologies. Stay tuned to the Red Hat Developer blog to learn more about what you can do with LLVM, Go, and Rust.

Rust 1.39 Released With Async-Await Support

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Mozilla: Firefox 71 Beta 12 Testday and Privacy Debate

  • Firefox 71 Beta 12 Testday – November 22nd

    We are happy to let you know that Friday, November 22nd, we are organizing Firefox 71 Beta 12 Testday. We’ll be focusing our testing on: Inactive CSS. Check out the detailed instructions via this gdoc. *Note that this events are no longer held on etherpad docs since public.etherpad-mozilla.org was disabled.

  • Mozilla Privacy Blog: Mozilla Mornings on the future of openness and data access in the EU

    On 10 December, Mozilla will host the next installment of our Mozilla Mornings series – regular breakfast meetings where we bring together policy experts, policymakers and practitioners for insight and discussion on the latest EU digital policy developments. The next installment will focus on openness and data access in the European Union. We’re bringing together an expert panel to discuss how the European Commission should approach a potential framework on data access, sharing and re-use.

Programming Leftovers

  • Quicksort in Python

    Quicksort is a popular sorting algorithm and is often used, right alongside Merge Sort. It's a good example of an efficient sorting algorithm, with an average complexity of O(n logn). Part of its popularity also derives from the ease of implementation. We will use simple integers in the first part of this article, but we'll give an example of how to change this algorithm to sort objects of a custom class. Quicksort is a representative of three types of sorting algorithms: divide and conquer, in-place, and unstable.

  • GCC 10.0 Status Report (2019-11-18), Stage 3 in effect now
  • GCC 10 Feature Development Is Over - Now The Focus Turns To Bug Fixing

    GCC 10 has moved to its next stage of development that shifts away from feature work to instead general bug fixing with hopes of shipping the GNU Compiler Collection 10 release in the months ahead. GCC 10 release manager Richard Biener of SUSE announced this Monday morning that "stage three" development phase.

  • ttdo 0.0.4: Extension

    A first update release to the still very new (and still very small) ttdo package arrived on CRAN today. Introduced about two months ago in September, the ttdo package extends the most excellent (and very minimal / zero depends) unit testing package tinytest by Mark van der Loo with the very clever and well-done diffobj package by Brodie Gaslam.

  • Adventures optimizing a bytecode based scripting language
  • Keeping a simple markdown work-log, via emacs

    For the past few years I've been keeping a work-log of everything I do. I don't often share these, though it is sometimes interesting to be able to paste into a chat-channel "Oh on the 17th March I changed that .."

  • Implement C++ coroutines.
    This patch series is an initial implementation of a coroutine feature,
    expected to be standardised in C++20.
    
    Standardisation status (and potential impact on this implementation):
    ----------------------
    
    The facility was accepted into the working draft for C++20 by WG21 in
    February 2019.  During two following WG21 meetings, design and national
    body comments have been reviewed, with no significant change resulting.
    
    Mature implementations (several years) of this exist in MSVC, clang and
    EDG with some experience using the clang one in production - so that the
    underlying principles are thought to be sound.
    
    At this stage, the remaining potential for change comes from two areas of
    national body comments that were not resolved during the last WG21 meeting:
    (a) handling of the situation where aligned allocation is available.
    (b) handling of the situation where a user wants coroutines, but does not
        want exceptions (e.g. a GPU).
    
    It is not expected that the resolution to either of these will produce any
    major change.
    
    The current GCC implementation is against n4835 [1].
    
    ABI
    ---
    
    The various compiler developers have discussed a minimal ABI to allow one
    implementation to call coroutines compiled by another; this amounts to:
    
    1. The layout of a public portion of the coroutine frame.
    2. A number of compiler builtins that the standard library might use.
    
    The eventual home for the ABI is not decided yet, I will put a draft onto
    the wiki this week.
    
    The ABI has currently no target-specific content (a given psABI might elect
    to mandate alignment, but the common ABI does not do this).
    
    There is not need to add any new mangling, since the components of this are
    regular functions with manipulation of the coroutine via a type-erased handle.
    
    Standard Library impact
    -----------------------
    
    The current implementations require addition of only a single header to
    the standard library (no change to the runtime).  This header is part of
    the patch series.
    
    GCC Implementation outline
    --------------------------
    
    The standard's design for coroutines does not decorate the definition of
    a coroutine in any way, so that a function is only known to be a coroutine
    when one of the keywords (co_await, co_yield, co_return) is encountered.
    
    This means that we cannot special-case such functions from the outset, but
    must process them differently when they are finalised - which we do from
    "finish_function ()".
    
    At a high level, this design of coroutine produces four pieces from the
    original user's function:
    
      1. A coroutine state frame (taking the logical place of the activation
         record for a regular function).  One item stored in that state is the
         index of the current suspend point.
      2. A "ramp" function
         This is what the user calls to construct the coroutine frame and start
         the coroutine execution.  This will return some object representing the
         coroutine's eventual return value (or means to continue it when it it
         suspended).
      3. A "resume" function.
         This is what gets called when a the coroutine is resumed when suspended.
      4. A "destroy" function.
         This is what gets called when the coroutine state should be destroyed
         and its memory returned.
    
    The standard's coroutines involve cooperation of the user's authored function
    with a provided "promise" class, which includes mandatory methods for
    handling the state transitions and providing output values.  Most realistic
    coroutines will also have one or more 'awaiter' classes that implement the
    user's actions for each suspend point.  As we parse (or during template
    expansion) the types of the promise and awaiter classes become known, and can
    then be verified against the signatures expected by the standard.
    
    Once the function is parsed (and templates expanded) we are able to make the
    transformation into the four pieces noted above.
    
    The implementation here takes the approach of a series of AST transforms.
    The state machine suspend points are encoded in three internal functions
    (one of which represents an exit from scope without cleanups).  These three 
    IFNs are lowered early in the middle end, such that the majority of GCC's
    optimisers can be run on the resulting output.
    
    As a design choice, we have carried out the outlining of the user's function
    in the front end, and taken advantage of the existing middle end's abilities
    to inline and DCE where that is profitable.
    
    Since the state machine is actually common to both resumer and destroyer
    functions, we make only a single function "actor" that contains both the
    resume and destroy paths.  The destroy function is represented by a small
    stub that sets a value to signal the use of the destroy path and calls the
    actor.  The idea is that optimisation of the state machine need only be done
    once - and then the resume and destroy paths can be identified allowing the
    middle end's inline and DCE machinery to optimise as profitable as noted above.
    
    The middle end components for this implementation are:
     1. Lower the coroutine builtins that allow the standard library header to
        interact with the coroutine frame (these fairly simple logical or
        numerical substitution of values given a coroutine frame pointer).
     2. Lower the IFN that represents the exit from state without cleanup.
        Essentially, this becomes a gimple goto.
     3. Lower the IFNs that represent the state machine paths for the resume and
        destroy cases.
     4. A very late pass that is able to re-size the coroutine frame when there
        are unused entries and therefore choose the minimum allocation for it.
    
    There are no back-end implications to this current design.
    
    GCC Implementation Status
    -------------------------
    
    The current implementation should be considered somewhat experimental and is
    guarded by a "-fcoroutines" flag.  I have set out to minimise impact on the
    compiler (such that with the switch off, coroutines should be a NOP).
    
    The branch has been feature-complete for a few weeks and published on Compiler
    Explorer since late September.  I have been keeping a copy of the branch on
    my github page, and some bug reports have been filed there (and dealt with).
    
    The only common resource taken is a single bit in the function decl to flag
    that this function is determined to be a coroutine.
    
    Patch Series
    ------------
    
    The patch series is against r278049 (Mon 11th Nov).
    
    There are 6 pieces to try an localise the reviewer interest areas.  However
    it would not make sense to commit except as possibly two (main and testsuite).
    I have not tested that the compiler would even build part-way through this
    series.
    
    1) Common code and base definitions.
    
    This is the background content, defining the gating flag, keywords etc.
    
    2) Builtins and internal functions.
    
    Definitions of the builtins used by the standard library header and the
    internal functions used to implement the state machine.
    
    3)  Front end parsing and AST transforms.
    
    This is the largest part of the code, and has essentially two phases
     1. parse (and template expansion)
     2. analysis and transformation, which does the code generation for the
        state machine.
    
    4) Middle end expanders and transforms
    
     As per the description above.
    
    5) Standard library header.
    
    This is mostly mandated by the standard, although (of course) the decision
    to implement the interaction with the coroutine frame by inline builtin
    calls is pertinent.
    
    There is no runtime addition for this (the builtins are expanded directly).
    
    6) Testsuite.
    
    There are two chunks of tests.
     1. those that check for correct error handling
     2. those that check for the correct lowering of the state machine
     
    Since the second set are checking code-gen, they are run as 'torture' tests
    with the default options list.
    
    ======
    
    I will put this patch series onto a git branch for those that would prefer
    to view it in that form.
    
    thanks
    Iain
    
  • Initial Patches Wire In C++20 Coroutines For The GCC Compiler

    The GNU Compiler Collection continues picking up new features aligned for the upcoming C++20 standard. The latest are patches pending on the mailing list for implementing coroutines in C++. C++20 is expected to have coroutines per the pending technical specification. Coroutines allow a function to have its execution stopped/suspended and then to be resumed later.

  • Faster Winter 1: Vectors
  • Faster Winter 2: SPECIALIZE
  • Attention! Attention! Tutorial Proposal Deadline Approaching
  • Python Software Foundation Fellow Members for Q3 2019

    Congratulations! Thank you for your continued contributions. We have added you to our Fellow roster online. The above members have contributed to the Python ecosystem by teaching Python, maintaining popular libraries/tools such as cryptography and pytest, helping document on packaging.python.org, organizing Python events, starting Python communities in their home countries, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

  • Why Sponsor PyCon 2020?

    Sponsors help keep PyCon affordable and accessible to the widest possible audience. Sponsors are what make this conference possible. From low ticket prices to financial aid, to video recording, the organizations who step forward to support PyCon, in turn, support the entire Python community. They make it possible for so many to attend, for so many to be presenters, and for the people at home to watch along.

  • Pandas GroupBy: Your Guide to Grouping Data in Python

    Whether you’ve just started working with Pandas and want to master one of its core facilities, or you’re looking to fill in some gaps in your understanding about .groupby(), this tutorial will help you to break down and visualize a Pandas GroupBy operation from start to finish. This tutorial is meant to complement the official documentation, where you’ll see self-contained, bite-sized examples. Here, however, you’ll focus on three more involved walk-throughs that use real-world datasets.

  • Solving CAPTCHA with Web automation

    CAPTCHA is no longer an alien term to the users. An acronym for Completely Automated Public Turing test to tell Computers and Humans Apart. CAPTCHA is basically a computer program built to distinguish between the human and machine to prevent any type of spam or data extraction from websites. The entire concept of CAPTCHA is based on the assumption that only a human would pass this test and bot or automated scripts would fail.

Intel: BIOS, Mesa and Devices

  • Intel To Drop Very Old Drivers/BIOS From Their Site, But The Linux Impact To Be Minimal

    Making waves today is that Intel will be removing very old BIOS and driver downloads from their site on or after 22 November. Though these software downloads for the products in question are around ~20 years old so the real-world impact should be small plus with Linux drivers being in the mainline kernel, all you'd really be losing out on are BIOS updates that themselves haven't seen updates in years. Intel is said to be removing old drivers and BIOS from their original Pentium era product offerings later in the week. Intel hasn't provided an exact list of all the products affected, but they are all close to 20 years old and beyond. Besides vintage hobbyists and those relying upon the outdated hardware still in niche use-cases, there shouldn't be much real impact. This Reddit thread has additional details on some of the affected products and unofficial mirrors of the files now that the removal of the files are imminent.

  • Intel's Vulkan Driver To Lower CPU Overhead With Mesa 20.0

    A patch series was merged today for the in-development Mesa 20.0 to further lower the CPU overhead of Intel's open-source Vulkan driver. Lead Intel "ANV" driver developer Jason Ekstrand merged the 15 commits focused on CPU overhead reductions. These reductions come after analyzing traces from rapid bind-and-draw benchmarks and seeing that the binding tables and push constants were in the hottest of hot paths.

  • Intel's oneAPI / DPC++ / SYCL Will Run Atop NVIDIA GPUs With Open-Source Layer

    With yesterday's much anticipated Intel oneAPI beta being built around open-source standards like SYCL, the "cross-device" support can at least in theory extend beyond just Intel platforms. Codeplay is already showing that's possible with a to-be-open-source layer that will allow oneAPI and SYCL / Data Parallel C++ to run atop NVIDIA GPUs via CUDA. Codeplay, which is already known for their several Vulkan / SYCL / SPIR-V initiatives, is working on this layer to run oneAPI / DPC++ / SYCL codes atop NVIDIA hardware while still leveraging NVIDIA's CUDA drivers. You could think of it akin as DXVK or VKD3D that map Direct3D 11 to Vulkan but this is about allowing Intel-focused code to run on NVIDIA's drivers. Or similarly, AMD's Radeon ROCm that allows some CUDA codes to be compiled for execution on AMD hardware.

  • Mini Type 10 dev board supports extended mini-PCIe I/O modules

    Acromag’s rugged “ACEX4041” Mini-ITX carrier is equipped with a Linux-friendly, Apollo Lake based COM Express Mini Type 10 module plus 4x mini-PCIe based “AcroPack” slots that support 25+ I/O modules. Acromag announced a Mini-ITX form-factor carrier board for COM Express Mini Type 10 modules sold in three configurations: barebones (ACEX4041); equipped with an Intel Apollo Lake Mini Type 10 module (ACEX4041-2000); or a Development Lab System sold with the Apollo Lake module and 1TB storage (DLS4041-2110). The ACEX4041 is equipped with 4x AcroPack I/O slots that support third-party mini-PCIe cards but are designed primarily to load one of Acromag’s 25+ AcroPack modules.

  • Some FUJITSU FUTRO Thin Clients are Powered by Intel Gemini Lake Refresh SoC’s

    Six new Intel Gemini Lake Refresh processors were just announced a couple of weeks ago, and some of the first systems to feature the processor are part of FUJTISU Thin Client FUTRO family.

  • Gemini Lake based Lattepanda Delta SBC relaunches for $188

    DFRobot’s previously Kickstartered, Ubuntu-ready LattePanda Delta SBC has relaunched for $188 with a quad-core Gemini Lake SoC. The Intel Core-based Lattepanda Alpha is already available starting at $379 for a model that recently switched from a 7th Gen to an 8th Gen Amber Lake-Y CPU. Back in Dec. 2017, DFRobot’s LattePanda project went to Kickstarter to launch a community-backed LattePanda Alpha SBC with a 7th Gen Kaby Lake Intel Core m3-7Y30 and an almost identical LattePanda Delta with a Celeron N4100 from the “Gemini Lake” follow-on to Apollo Lake. Both boards shipped to backers late, with the Alpha ARRIVING in late 2018 and the Delta being fulfilled this spring. The Alpha relaunched for public sales in January, and now the Delta is available.

Audiocasts/Shows/Screencasts: System76, Linux Headlines and More

  • The System76 Superfan III Event: Gardiner and Jay Chat About Their AWESOME Experience There

    The System76 Superfan III event occurred on November 16th, 2019 and it was a ton of fun! Gardiner Bryant and I talk about our experience there, some of the things they revealed, and other geeky topics around System76 and their computers

  • 2019-11-18 | Linux Headlines

    The Oracle vs. Google copyright case goes to the Supreme Court, NextCry attacks Nextcloud servers, Chromebooks prepare to use LVFS, and Debian takes the systemd debate to the next level.

  • Things are Looking Pod-tastic | Fall Time Blathering

    I started to produce some video content on YouTube and this site to enhance some of my content and later, I thought I would cut my teeth on a podcast of my own to talk about the nerdy things I enjoy. My reoccurring topics consist of my additional thoughts about a subject or two of the last BDLL show and an openSUSE corner but truth be told, openSUSE weaves itself throughout my “noodlings”. In September of 2019, the formation of Destination Linux Network was announced where these well established content creators have pooled their resources to draw together their somewhat discrete communities and provide a forum for interaction in greater depth than what Telegram, Discord or YouTube can provide on their own.

  • Test and Code: 94: The real 11 reasons I don't hire you - Charity Majors

    If you get the job, and you enjoy the work, awesome, congratulations. If you don't get the job, it'd be really great to know why. Sometimes it isn't because you aren't a skilled engineer. What other reasons are there? Well, that's what we're talking about today. Charity Majors is the cofounder and CTO of Honeycomb.io, and we're going to talk about reasons for not hiring someone. This is a very informative episode both for people who job hunt in the future and for hiring managers and people on the interview team.

  • Bluestar Linux 5.3.11 Run Through

    In this video, we are looking at Bluestar Linux 5.3.11.