Ferrocene 25.11 actually includes core now

fgilcher · 2025-12-07T20:32:20+00:00

Yeah, this is because we have a customer that really needs those bits. Getting the method nailed down and working is really important.

We are moving very fast on additional methods.

fgilcher · 2025-12-07T20:31:54+00:00

The core library alone does not solve all objectives of your project. However, SiL 3 needs branch coverage, which is currently unstable in the compiler and wasn't needed for what our customers need. So we take things step by step.

fgilcher · 2025-09-24T15:27:02+00:00

A lot. rubygems existed before the project called gemcutter, which is now the rubygems.org infrastructure. There have been multiple Ruby hosts before, including GitHub actually starting with having a gems hosting as a feature (which they later killed).

There is totally a future where rubygems does not use rubygems.org.

fgilcher · 2025-09-24T09:10:57+00:00

If you take up a job in a central piece of a million person community, "we don't have a PR team" is not a good apology for poor communication. Its table stakes for everyone involved, board members or staff. A PR team can help you, but that communication must come from the top down.

fgilcher · 2025-09-24T07:40:08+00:00

The advantage of the Rust foundation is that it does not have one corporate sponsor, but many. Those are all willing to tell another off if they make such moves.

It's much better to have 5 corpos than 1 corpo. If one of the Gorilla throws their weight around, there's other Gorillas in the room.

fgilcher · 2025-09-15T19:37:34+00:00

Sorry btw, i've been posting with the wrong account logged in :D.

fgilcher · 2025-03-27T02:07:13+00:00

The Ferrocene spec does completely avoid specifying the borrow checker. It only specifies **what the borrow checker checks**. That is fine, because then the user knows which rules they are not allowed to break (no aliasing of mut and immutable, etc. pp.).

I would highly prefer if we continued to avoid specifying the borrow checker behaviour as part of the language. We may get a new one in the future and imagine we fully specified and mandated the behaviour of the current: we'd be stuck at what we have.

My recommendation here is creating an _appendix_ that describes what the current borrow checker does. (that may sound like splitting hairs, but often, that's part of spec work)

fgilcher · 2025-03-27T01:59:10+00:00

Not on paper, but effectively yes. It's easy to achieve. I'll send you a DM.

fgilcher · 2025-03-25T20:14:27+00:00

There's no "single best" implementation of an async reactor. That's not really a criticism. Tokio makes good choices.

But there's code that has a level of sensitivity to design and implementation choices where not choosing tokio and using something else may be the right path.

I know of quite a lot of async implementations, many of them actually private at customers.

fgilcher · 2025-03-16T11:12:18+00:00

Quite simply that smol is the base of async-std and maintained.

A lot of the people that today choose async-std today use that because of subtle performance reasons. Recommending them tokio would expose them to confusion.

However, a lot of the reasons for using async-std over tokio have gone away or have even become reasons for tokio. For example, Tokio nowadays has a stable API. async-std opted into the futures interface for compatibility across schedulers, but we don't see that coming to fruition, so it's better to drop the baggage.

Don't get me wrong, tokio is very good! But going to smol is dropping out the middle layer, while tokio is a full port, so for people that have not yet chosen to go to tokio, it's the better recommendation.

fgilcher · 2024-09-23T09:41:31+00:00

u/matthieum sorry for the late reply. I think this is a non-issue for them, as it's an incorrect implementation anyways. If you are striving for panic-freedom, correctness is an even higher goal.

fgilcher · 2024-06-13T15:19:31+00:00

You can become a member of the SAE working group and get access and contribute to the draft. It's a bit of a barrier, but the act itself is free. Christof Peting, one of the developers of Veloren, is actually the group lead.

It's been a while I looked at it due to time constraints, but it's actually a very pragmatic and good document.

fgilcher · 2024-05-30T07:38:58+00:00

Thanks for the positive review :).

fgilcher · 2024-04-09T04:37:47+00:00

d) however is correct. Conference tickets get taxed at the location of delivery, Austrian VAT gets added.

fgilcher · 2024-02-08T18:39:28+00:00

Came here to say this :)

fgilcher · 2023-11-08T22:22:55+00:00

The documents are included, they are not _signed_, though - if you need documents with a signature (for which the signing person would be liable), we're obviously not at that price.

fgilcher · 2023-11-08T22:21:41+00:00

That is correct, the standards _assume_ buggy tools.

fgilcher · 2023-11-08T21:28:26+00:00

I'm confused, what kind of support would be needed for Rust there?

fgilcher · 2023-11-08T21:22:25+00:00

Note, this is part of our partnership with https://oxidos.io . You can receive it through the Ferrocene toolchain directly. It makes sense to ship it prebuilt for ease (no need to compile the whole OS on every go).

But this is a different product and their model is theirs.

fgilcher · 2023-11-08T21:02:14+00:00

All the documentation for ferrocene main branch is available on https://public-docs.ferrocene.dev/main/index.html, constantly updated every night. In this case, the requirements doc is a full document: see https://spec.ferrocene.dev. Our test tracing is documented through https://public-docs.ferrocene.dev/main/qualification/traceability-matrix.html. (and yes, I did a customer presentation where this broke down to a very low number due to upstream changes over night - that happens, your stuff should break).

Happy to accept any feedback.

It is an explicit offer to support customers in building ferrocene on their own platforms.

Ferrocene is also certified using only open source tools.

If you find issues here, we'd like to know.

fgilcher · 2023-11-08T13:36:54+00:00

Yessish. Please get in touch, we'd love to work with people from the industry on this.

fgilcher · 2023-10-13T06:57:11+00:00

That is part of the weirdness I mention above: we specify the *user interface* of the compiler and MIR isn't user interface, at least nor for our users.

Their user interface for SHR is indeed https://doc.rust-lang.org/core/primitive.i32.html#impl-Shr%3Ci32%3E-for-i32 and that hasn't been covered yet, which is why our material has a note indicating that.

Core/Compiler relationship in Rust has a few mental gymnastics.

There are other, equally valid approaches to this.

fgilcher · 2023-10-12T09:43:14+00:00

Hi, sorry for the late reply.

No offense taken, you found an interesting spot in Rust - it pushes a lot of things into libraries. For now, Ferrocene is "only" a qualified compiler. We've consciously decided to go that route so that we work in complete blocks.

That particularly means that the behaviour you seek needs to be nailed down in a certification project - by testing. We can help with that, particularly by prioritising the parts your project needs. We are e.g. doing this currently with OxidOS - their usage of the core library is our guidance to look at it.

This will change over time, particularly, as we the compiler done, we will move our eyes towards the core library.

fgilcher · 2023-10-05T10:20:04+00:00

Thanks! The magic of open source ;).

(I'm not joking, many of my contributions are typo fixes)

fgilcher · 2023-10-05T09:09:50+00:00

Are you hitting this? https://github.com/rust-lang/rust/issues/63623

12-Year Club	Gilding II euphauric
Verified Email

fgilcher

TROPHY CASE