https://github.com/chromium/chromium : C++ 74.0%, Java 8.8%, Objective-C++ 4.8%, TypeScript 4.2%, HTML 2.5%, Python 2.4%, Other 3.3%

https://github.com/mozilla-firefox/firefox : JavaScript 28.9%, C++ 27.9%, HTML 21.8%, C 10.4%, Python 2.9%, Kotlin 2.7%, Other 5.4%

How significant?

According to https://4e6.github.io/firefox-lang-stats/, 12%.

I would love an updated version of https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9e... (which stops in 2020).

For Chrome, I don't know if anyone has compiled the stats, but navigating from https://chromium.googlesource.com/chromium/src/+/refs/heads/... I see at least a bunch of vendored crates, so there's some use, which makes sense since in 2023 they announced that they would support it.

One could rewrite curl with Perl 30 years ago. Or with Java, Golang, Python, you name it. Yet it stays written with C even today.

Your comment comes across disingenuous to me. Writing it in, for example, Java would have limited it to situations where you have the JVM available, which is a minuscule subset of the situations that curl is used in today, especially if we're not talking "curl, the CLI tool" but libcurl. I have a feeling you know that already and mostly want to troll people. And Golang is only 16 years old according to Wikipedia, by the way.

For my hobby code, I'm not going to start writing Rust anytime soon. My code is safe enough and I like C as it is. I don't write software for martian rovers, and for ordinary tasks, C is more ergonomic than Rust, especially for embedded tasks.

For my work code, it all comes down to SDKs and stuff. For example I'm going to write firmware for Nordic ARM chip. Nordic SDK uses C, so I'm not going to jump through infinite number of hoops and incomplete rust ports, I'll just use official SDK and C. If it would be the opposite, I would be using Rust, but I don't think that would happen in the next 10 years.

Just like C++ never killed C, despite being perfect replacement for it, I don't believe that Rust would kill C, or C++, because it's even less convenient replacement. It'll dilute the market, for sure.

> Just like C++ never killed C, despite being perfect replacement for it

I think c++ didn't replace C because it is a bad language. It did not offer any improvements on the core advantages of C.

Rust however does. It's not perfect, but it has a substantially larger chance of "replacing" C, if that ever happens.

I was about to say that I never encounter TLS errors while browsing, but that's not strictly true. There is one such website, and it's only because the webmaster had a stroke and can't maintain it currently. But apart from that rather sad story I can't relate to your issues at all.

I agree. I don't remember the last time I saw an expired cert, and it was probably an abandoned web site (which would eventually expire even with a 3-year certificate as well). At least with Let's Encrypt you have to automate it.

American IT Mafia? That provides free certificates? You'd think setting up renewal would be less of a hassle than dealing and paying CAs even if it's once every 3 years, so that would be a rather benevolent mafia. Which of those CAs went out of business by the way?

Do you think Let's encrypt is less popular outside the US?

StartSSL, WoSign were the ones I've used. Very convenient services, much more convenient, compared to this certbot insanity.

I think that the rest of the world does not have much choice, because US uses their IT superiority to force political decisions to the rest of the world. I experienced that first-hand. When my country wanted to implement MITM to improve Internet usability for their citizens, US companies blacklisted government root certificate which disrupted this scheme and forced my country to roll back this plan. Now I have lots of websites completely blocked, instead of more careful and precise per-page blocking that would only be possible with MITM.

Hopefully, over time, China and Russia will destroy this superiority and will provide viable alternatives.

I had to deal with StartCom once many years ago, before LetsEncrypt. They had the rudest customer service I think I've ever encountered.

I hope that's not literally incrementing a sequence. Because it would lead to trivial neighbor ID guessing attacks.

I've implemented this thing, though not called it ULID. I've dedicated some bits for timestamp, some bits for counter within millisecond and rest for randomness. So they always ordered and always unpredictable.

Another approach is to keep latest generated UUID and if new UUID requested within the same timestamp - generate random part until it's greater than previous one. I think that's pretty good approach as well.

> I hope that's not literally incrementing a sequence

It's literally incrementing it by one:

https://github.com/ulid/javascript/blob/11c2067821ee19e4dc78...

https://github.com/ulid/javascript/blob/11c2067821ee19e4dc78...

Well, that makes little sense for me, you can just use numeric identifier instead. Bulk inserts which generate identifiers in bulk are commonly used.

But that's easy to fix, so just implementation quirk for this particular library, the idea is sound.

> But that's easy to fix, so just implementation quirk for this particular library, the idea is sound.

It's in ULID spec.

> I hope that's not literally incrementing a sequence. Because it would lead to trivial neighbor ID guessing attacks.

It is and it does.

Also the ULID spec suggests you use a CSPRNG, but doesn't mandate that or provide specific advice on appropriate algorithms. So in practice people may reach for whatever hash function is convenient in their project, which may just be FNV or similar with considerably weaker randomness too.

Did you ever visit `https://news.ycombinator.com/newest` page? Like 99% of submitted topics are never seen by anyone but few wanderers.

Often.

95%+ of submitted topics have poorly formatted titles, are submitted at off-peak times where there’s less users of demographics who might upvote,

and if your Show HN isn’t as widely applicable as this, those things might be important to think about.

Fairness aside, of course.

I prefer the "New" page. Much more random.

Why Rust? Haskell is gold standard here.

I guess there is a reason why Linux kernel accepts Rust not Haskell.

Haskell need a runtime environment for memory management.

Linux want all memory management explicit.

Can you elaborate? What is it about Haskell that makes it better?

Very advanced type system which allows to move a lot of program correctness to typing system. So basically if your program compiles, it probably works.

It's also has GC which makes it better suited for most programs, compared to Rust with its manual memory management.

Rust does not have manual memory management, and its type system also has the property that if your program compiles it probably works, IME.

Purely functional code is easier to test because of its referential transparency and lack of shared state.

Haskell is also nice because of quickcheck.

I would think Lean and other formal languages are the real gold standard.

But none of them really have enough training data for LLMs to be any good at them.

Dota and League are not RTS games. They are Moba. These are completely different genres. Dota happened to utilise Warcraft engine and assets back in the days, but that doesn't make it RTS.

And it's still popular and actually playable today. Warcraft 2 is not really fun to play. Very clunky control, very outdated graphics, bad story telling. With Starcraft, my only real complain is terrible cinematics which just doesn't cut it today. Otherwise this game is as fun to play today, as it was 15 years ago.

The cinematics were the best part of Starcraft!

I still get a kick out of the fact that the units look completely different in the cinematics as they do in the game and even the instruction manual

I quite like the StarCraft remaster. It plays just like the old one (to me, at least; I am not a competitive player), and it looks much better.

> Warcraft 2 is not really fun to play.

Compared with a lot of ptesent games is luxury: no updates, no bullshit introduction, just play.

I tried claude code to write very simple app for me. Basically Golang mock server which will dump request to console. I'd write this kind of app in an hour. I spent around 1.5 hours with claude code and in the end I had code which I liked, almost the same code I'd write myself. It's not vibe coding, I carefully instructed it to write code in a way I prefer, one small step after another.

So for me, it's pretty obvious that with better training, I'd be able to achieve speed ups with the same result in the end. Not 10x, but 2x is possible. The very first attempt to use AI ended up with almost the same time I'd write the same code, and I have a lot to improve.

That said, I have huge problem with this approach. It's not fun to work like that. I started to program 25 years ago, because it was fun for me. It still fun for me today. I love writing all these loops and ifs. I can accept minimal automation like static autocomplete, but that's about it.