Damn... So good. Thank you!

https://hn-wrapped.kadoa.com/nhatcher

(Kind of embarrassing TBH)

Ha! My project actually has 0 dependencies! /jkjk Though it's not in rust..

Mine is probably even more embarrasing, but mostly due to focusing on random threads: https://hn-wrapped.kadoa.com/ashirviskas

This blows my mind TBH. I used to say a few years back that Ryu is my favorite modern algorithm but it felt so complicated. Your C implentation almost feels... simple!

Congratulations, can't wait to have some time to study this further

Thank you! The simplicity is mostly thanks to Schubfach although I did simplify it a bit more. Unfortunately the paper makes it appear somewhat complex because of all the talk about generic bases and Java workarounds.

I've just started a Julia port and I think it will be even cleaner than the C version (mostly because Julia gives you a first class (U)Int128 and count leading zeros (and also better compile time programming that lets you skip on writing the first table out explicitly).

Cool, please share once it is complete.

C++ also provides countl_zero: https://en.cppreference.com/w/cpp/numeric/countl_zero.html. We currently use our own for maximum portability.

I considered computing the table at compile time (you can do it in C++ using constexpr) but decided against it not to add compile-time overhead, however small. The table never changes so I'd rather not make users pay for recomputing it every time.

Oh wow, I would love to see that if you can share it :)

Once I finish it, I'll be PRing to the Julia repo (to replace the current Ryu version), and I'll drop a link here.

I started a section to list implementations in other languages: https://github.com/vitaut/zmij?tab=readme-ov-file#other-lang.... Once yours is complete feel free to submit a PR to add it there.

Not adding it until complete, but https://github.com/JuliaLang/julia/pull/60439 is the draft.

Quick question, if you are still around :).

I have been doing some tests. Is it correct to assume that it converts 1.0 to "0.000000000000001e+15".

Is there a test suite it is passing?

It converts 1.0 to "1.e-01" which reminds me to remove the trailing decimal point =). dtoa-benchmark tests that the algorithm produces valid results on its dataset.

So if I use:

    #include "zmij.h"
    #include <stdio.h>

    int main() {
        char buf[zmij::buffer_size];
        zmij::dtoa(1.0, buf);
        puts(buf);
    }

I get `g++ zmij.cc test.c -o test && ./test` => `0.000000000000001e+15`

My bad, you are right. The small integer optimization should be switched to a different output method (or disabled since it doesn't provide much value). Thanks for catching this!

Should be fixed now.

"1.e-01" is for 0.1, not 1.0.

I assume they meant 1.e+00

That is what Schubfach does

Yeah, that's what I meant.

I was hesitant to add my own but I think you might find it interesting as we make money not from clients but from grants.

We have IronCalc[1]. We don't make money from customers as we don't have a finalized product yet. But we have an ongoing grant from the NLnet[2]. You can have a look at the kind of projects they are granting money. It's always a source of inspiration.

That being said IronCalc takes a lot of time from me. Way more than a side project should.

[1]: https://www.ironcalc.com

[2]: https://nlnet.nl/project/IronCalc/

The friction to try it out is already really low, I like that! But it could be even lower if instead of an image the interactive version is served right on the landing page. Great project!

Yes, Dani the designer involved in the project, keeps saying that. There are two things that stops me from doing that:

* It would make the landing page a bit heavier * I would need to synchronize deployments somehow

But I guess I should do that sooner rather than later.

Thanks!

Just my two cents, but:

- In terms of data, this is nothing compared to any site serving a bunch of images. The compute would differ, but loading speed shouldn't be an issue if you can render the HTML first, and hydrate it after page load. This static HTML would then also serve as fallback when Javascript is disabled.

- For a quick demo, I doubt you will lose people by embedding an older version. Serving a version of a few months ago seems like 80% of the work, with 20% of the effort, in terms of deployment.

Anyhow, nice to see government funds put to a good cause!

Top-three time-sucks?

Thanks for sharing! Awesome.

This is lovely! I'm surprised I had never heard of it before today

This is very cool indeed. Is there anything similar for ppt presentations that you know of?

No, not really.

If folks find this interesting, maybe also mosh[1] is for you. Different trade offs.

[1]: https://mosh.org/

I'm in crunch mode doing the internationalization and localization of my spreadsheet engine. This is a rabbit hole and a nightmare in Excel, so a big opportunity for us to get this right.

This is the PR: https://github.com/ironcalc/IronCalc/pull/616

Feel free to comment and destroy it!

You can test it in: https://testing.ironcalc.com

Glad to see you're doing this! I was wondering if the currency button could be changed. Defaulting to Euro is fine, but being able to switch that shortcut would be handy.

I still need to update the UI to reflect the changes of the locale and language, but that should be the easy part.

> We've been seeing variations of the same article every week.

Time has come. Over the last few years there is more and more interest from goverments and private organizations to have relieable software that does not depend of foreign entities. Software sovereignty is becoming a necesity rather than a nice to have for both nations and enterprises.

> Excel, in particular, hasn't been unseated despite billions in investments from competitors over the years.

Excel, like many other technologies in the past can be disrupted. Like mane other commenters say, it won't come cheap. Saving costs shouldn't be the the goal here.

> Parity will happen someday, but it's at least a decade away.

Challenge accepted!

This is the year of LibreOffice on the government? I'd love if you were right, but I doubt it. The chasm is enormous, and maybe you don't use Excel enough to realize it.

The chasm is enormous, but Calc doesn't need to implement 100% of Excel's functionality when most people - even business/power users - don't use all of its features.

What major commonly used features do you reckon Excel has that hasn't been implemented in LO Calc yet, that would be a deal-breaker for most businesses?

To my knowledge, Calc has implemented most of Excel's formulae (well over 500 in total count), so at least for typical spreadsheet functionality you wouldn't missing anything.

The biggest limitation I can think of is the limited support for VBA, but Microsoft have already announced VBA's deprecation[1], so no one should be relying on it even in MS World.

And whilst LO's own Basic scripting is... basic, it also supports rich scripting and full automation via Python and Javascript. It even has a full-fledged SDK for developing addins/extensions using a high-level language like C++/Java etc[2], so businesses who're dependent on some random proprietary excel COM addin or something could invest in development effort to port it over.

Heck, if businesses are so inclined, they could modify the LO source itself and build a custom version to add the features they want - that's the beauty of FOSS.

[1] https://devblogs.microsoft.com/microsoft365dev/how-to-prepar...

[2] https://api.libreoffice.org/

You don't use all it's feature, but if you need part of the 10% of features that Calc doesn't support, then your in a world of hurt.

When Calc gets the other 90% of the features Excel has, you also need to contend with word, Outlook, Visio and all the rest that Libre Office has a 0% solution for.

I support FLOSS... But pretending that anything else does enough for many orgs is delusional. There is work and pain to get through to even have a workable solution... And it won't be as good for a long while.

Massive cost savings are one of the bigger motivators... But that will be offset by the need for more internal staff.

I don't see why you would automatically be in "a world of hurt". Yes, you might be if you were to suddenly roll it out organisation wide without any testing, but no sane IT department would do that. This is why you have internal test groups and pilot groups. Once you identify the limitations, you scope out the missing features/issues, engage developers if need be, or look for alternate solutions. No one needs to get hurt.

Will you, personally, volunteer to resolve all the issues when trying to convert the older Excel based workflows?

What's your approach to getting out of Access, Visio and Outlook integrations?

No, but that's only because I hate Excel. But I'm sure developers who don't hate it but also appreciate FOSS solutions might be interested, if the pay is good.

Access = LibreOffice Base

Visio = LibreOffice Impress

Outlook = Schleswig-Holstein already switched successfully to Open-Xchange and Thunderbird, I've not heard of them running into any major issues with this setup.

And if the cost of (re)developing all the existing solutions exceeds the costs of MS licensing for a decade?

I find that highly unlikely given how much commercial agreements with MS costs.

But if that's the case then they should either look for a different COTS solution, and/or change their business workflow.

And in the event even that is unfeasible, then just continue to keep a few windows machines (maybe convert them to VMs or VDIs for ease of maintenance) for the few users that can't be migrated.

Have you, personally, ever had to convert an MS Access based application that took years to write to something else? It seems like all your responses either shift responsibility or hand wave it away. I'm sure migration is incredibly easy when you don't have to deal with said migration in a meaningful way.

No, I don't think LibreOffice is the answer. And I am with you here, I would love to be wrong. One issue is that it doesn't really work well online. The folks from Collabora[1] have done an amazing job at wrapping LibreOffice for the web and maybe that is a way to go?

As a sibling comment says you don't need to implement absolutely everything Excel does to _disrupt_ Excel. But you do need to provide a fantastic tool that is easy to use and solves 99% of the problems. If governments start putting their money were their mouth is I am very convinced we can create tools that supersede Excel, Word,...

[1]: https://www.collaboraonline.com/

Oh wow! Looks lovely TBH Congratulatiosn to the proton team!

EDIT: Anyone in the proton team can make public any details?What do you use for collaboration? How compatible is with Excel?

Disclaimer: I am the creator of another spreadsheet engine

Frequenz Energy-as-a-Service GmbH | Full-Time | Berlin/Hybrid-Possible, Germany

We are a technology company developing groundbreaking solutions that help companies to rapidly transition from being passive electricity consumers to becoming fully self-sustaining prosumers, capable of leveraging various renewable energy assets.

We are currently looking for software developers to join our team building an Open Source SDK and related open source projects.

Our homepage:

https://www.frequenz.com

Our open source org:

https//github.com/frequenz-floss

Apply here: https://www.frequenz.com/careers/open-source-sdk-developer

As this is a position for developing open source, it would be highly appreciated if you can attach links to your code examples from github, gitlab, or the like to your application.

These roles are not fully-remote. These are based in Berlin, with a possibility for hybrid-model, which can be discussed during the course of the interview.

(PS: If you choose to apply, we would appreciate if you could mention that you have come from HN)

Discussed before here:

https://news.ycombinator.com/item?id=45967079 (245 and 112 comments)

A more readable take:

https://www.msstate.edu/newsroom/article/2025/11/new-clues-o...

Nice, but it has a subtle mistake:

Nature C.> The retention of ancestral alphaproteobacterial pathways in some protist lineages reveals that the mitochondrion of the last eukaryotic common ancestor was more metabolically versatile than are the highly derived mitochondria that are found in most modern eukaryotes.

Press release> These findings suggest that the earliest eukaryotes were far more metabolically versatile than their modern descendants.

The ancestors of mitochondria were parasite bacteria, and they made a lot of proteins themself. (I don't know. Perhaps they changed host frequently? perhaps just in case the sucker dies? Perhaps to survive while they hunt a new host?)

Modern mitochondria lost many of these features because they relay on the host that is stable.

The mitochondria of this eukaryote are strange, because they (only partially?) lost one of these features to create one of the proteins. (I'm not sure. It looks like it's non functional, but some parts are still there? Perhaps they only do some steps and relay on the host eukaryote for the rest?)

So, when the ancestors of these eukaryote and the ancestors of most eukaryotes (including us) split, the mitochondria were still able to make this protein. Our mitochondria lost it completely, but their mitochondria only partially.

Suggested fix> These findings suggest that the *the mitochondria* of earliest eukaryotes were far more metabolically versatile than their modern descendants.

I don't think what this sentence says is surprising (but I'm not a biologist). Anyway, the paper is about a more subtle detail that is more interesting. It's about the mitochondria at the moment of the ancient split of the eukaryotes. Perhaps there is a better way to fake-edit the press release.