We are a young startup building digital twinning solutions for spacecraft validation & verification.

The ideal candidate would have a demonstrated track record with Rust or possibly C++/Haskell/*ML, a passion for space and a background in physics or a related field of engineering.

Please apply at: https://www.linkedin.com/jobs/view/4129163803/ or email us at office@[company name].com

[1] https://docs.rs/atomic-waker/latest/atomic_waker/

    @enumclass
    class MyEnum:
        class UnitLikeVariant(Variant0Arg): ...
    
        class TupleLikeVariant(Variant2Arg[int, str]): ...
    
        @dataclass
        class StructLikeVariant:
            foo: float
            bar: int

        # The following class variable is automatically generated:
        #
        # type = UnitLikeVariant | TupleLikeVariant | StructLikeVariant

I found Hifitime to be very opinionated and give a false sense of security due to its automatic computation of leap seconds based on historical tables. Yes, leap seconds are announced some ~6 month in advance, but what if you don't update regularly the library? Or if you can't because it is deployed on an embedded system?

In the end I wrote my own minimalistic TAI timestamp library [1] and made the conscious decision to let the user take the responsibility to deal with leap seconds in UTC conversion.

[1] https://github.com/asynchronics/tai-time

If optimizing repeated atomic loads is indeed allowed, waiting for a signal by spinning on an atomic load could loop forever. Yet I have the feeling most people consider such code to be valid. Are they wrong?

[1] http://backreaction.blogspot.com/p/talk-to-physicist_27.html

[2] https://aeon.co/ideas/what-i-learned-as-a-hired-consultant-f...

Even with those gigantic solar arrays, energy management on Juice is extremely challenging. Once in the vicinity of Jupiter, the spacecraft will be powered by less than 4% of the solar flux it receives in earth orbit.

One use case for C is communication with the CPU (remoteproc stuff). We commonly had one PRU handle CPU communication with trivial C code while another PRU on the same PRU subsystem was coded with assembly to handle real-time I/O.

The territorial limitations effectively prevents any form of open distribution, yet the license is open enough to remove most commercial incentive for maintenance and further development: a perfect recipe to make software instant abandonware upon release.

[1] https://essr.esa.int/license/european-space-agency-community...

But more importantly, unlike the various Markdown flavors or AsciiDoc, it is incredibly extensible thanks to the combination of custom filters and the possibility to add HTML classes and attributes. One can write filters to leverage the class/attribute information and perform transformations at the AST level, which basically lets you define a DSL with an arbitrary number of custom elements.

I wrote a collection of filters for the publication of a large online legal playbook. Not only did Pandoc make it possible to introduce different kind of custom elements that don't exist in plain Markdown or AsciiDoc, but by using different filters it was possible to use a single Markdown source to generate both the book and various summaries such as a list of examples, a list of civil code clauses etc. I don't know Haskell that well so I used Rust for the filters, but that worked very well.

Pandoc is IMO a very underrated tool.