levodelellis

Great. C++20 has been my favorite and I was wasn't sure what the standards says since it's been a while. I'll be reading the C++26 standard soon

I have no faith in anyone doing AI to accomplish anything (especially relative to how much money they spend) except John Carmack. People should be trying to throw money at him

Haha, yes

You don't really need to deal with gcc backend. Most languages are expressible in C89. It'll obviously be less readable since generated lines look nothing like source lines but C89 beats llvm in most cases, especially if the C compiler supports assembly. I stuck to using intrinsics only because I heard of compilers producing worse code when it hits asm blocks since it can't understand it as well as intrinsics. I took out llvm last time it broke my compiler because it didn't add any value

I don't know what point you're trying to make but your question was what's an alternative to llvm. People writing compilers always used C89 or a version of it (C11 allows an easier atomic implementation). There's a lot more C89 compilers than backends that llvm supports. When I was writing arduino code clang/llvm couldn't generate the AVR code for the board. The default toolchain was gcc with an AVR backend. IIRC it had optimizations and was the only reasonable compiler I could use. There's nothing wrong using C as your backend

I never heard of hardware without one

Many compilers including my own uses C89

Yes. I also written a compiler and I also complained about LLVM.

LLVM is

  - Slow to compile
  - Breaks compilers/doesn't have a stable ABI
  - Optimizes poorly (at least, worse than GCC)

Swift I never used but I tried compiling it once and it was the bottom 2 slowest compiler I ever tested. The only thing nearly as bad was kotlin but 1) I don't actually remember which of these are worse 2) Kotlin wasn't meant to be a CLI compiler, it was meant to compile in the background as a language server so it was designed around that

Mojo... I have things I could say... But I'll stick to this. I talked to engineers there and I asked one how they expected any python developers to use the planned borrow checker. The engineer said "Don't worry about it" ie they didn't have a plan. The nicest thing I can say is they didn't bullshit me 100% of the time when I directly asked a question privately. That's the only nice or neutral thing I could say

A 200ms difference is adding or removing 200lines lines of implementation, and spliting it up into a file can make it slower because of include overhead. You completely made up C being twice as fast as C++.

Oh? I use a boring old $5 VPS (using nginx for https). There's no cloudflare or anything else involved. I wonder why that's happening. I may look into that this week

tcc is 8x faster, twice as fast isn't doing it justice.

As for the header thing, that'd could potentially be true if the compile time was something like 450ms -> 220ms, but why bother saying it when you're only saving a few hundred milliseconds

IIRC go wasn't that fast but can feel like it in vscode. IIRC vscode compiles go using the lsp which is faster than launching a process because for some reason, vscode stalls for a second or more before launching a process.

I can't remember how fast D was but iirc it was fairly fast. Actual fastest is my compiler which I don't work on anymore and isn't ready for production. It's the only compiler I know of that hit millions of lines <1s in a non trivial language https://bolinlang.com/

I don't believe you, I measured compile times in c compilers and my own. If you provide more information I'd be more likely to believe you

I measured once and to my surprise templates aren't (directly) the reason for long compile times. It's function bodies in headers, and obviously templates are in headers and they call other templated functions/classes which explodes code generation and time. But if it's only a few lines and doesn't call other templated functions it's likely fine. I wrote about it here https://bolinlang.com/wheres-my-compile-time

After writing that, I wrote my own standard library (it has data structs like vector, hashmap and sets; slices, strings, rng, print, some io functions, and more) which uses a lot of templates, and it compiles in <200ms on both clang and gcc. Many standard library headers take much longer to compile than that. It's not a terrible idea to have your own standard lib if you need quick compile times.

Not sure, I'd like that too

You could use io_uring but IMO that API is annoying and I remember hitting limitations. One thing you could do with io_uring is using openat (the op not the syscall) with the dir fd (which you get from the syscall) so you can asynchronously open and read files, however, you couldn't open directories for some reason. There's a chance I may be remembering wrong

Correct, I'm saying public domain never requires that which is different from open source licenses, which may require it (and other stipulations)

It's not open source when you disallow people and companies from using it. One big difference between open source and public domain is that code in the public domain doesn't force anyone to redistribute the changes.

I have had several projects where I didn't want to be forked, especially by a company with a marketing budget. I choose not to distribute it with an open source license. There's nothing wrong with that. Companies have sold copies of source to people who paid, so that's an option. But I don't know of any licenses like that which have been written for the public to use (copying a company license is a copyright violation)

Every time I read his article I regret it. I literally mean every time, 100% of it. Judging by the title of the article, I didn't expect his reason to be "engineers working outside their area of expertise". I've seen good engineers figure out problems outside of their expertise plenty of times, so that's not a good reason either.

I feel like this article is the equivalent 16 paragraph stating you're likely to be correct only 10% of the time when you guess a random number from 1 to 10

Isn't this what Joel wrote 25 years ago? Don't rewrite your software?

I wrote a compiler/language, and I was expecting something different from the article after my experiences

Like many of the other commenters, I didn't like the article

I use a high-level async framework. It works extremely well so far. I do need to add code occasionally, but that's because it's an in-house lib that isn't a year old yet

I do write code that uses multi-threading every day and usually I write a few lockless functions every month for the in-house library I use. I was considering writing an article on atomics after all the mistakes and bad code I've seen.

A problem with writing an article is that if I don't show real code, people might think I'm exaggerating; if I do show real code, it'd look like I'm calling someone a bad programmer

Would you rather have a gc or unsafe?

In just about every language I seen people use .clone rather than deal with problems so I suspect a lot of cases a GC can be just fine or faster. Although I'm comfortable with memory management and rather use C or C++ if I'm writing fast code

I find it funny AF that Fil-C is safer than languages with the unsafe keyword. Who knew C could be so safe with a proper compiler

I completely disagree with you and I do write performance code (but not specifically HPC) and my current day job is highly async code with a GUI

People mess up the order all the time. When you mess up locks you get a deadlock, when you mess up an atomic you have items in the queue drop or processed twice, or some other weird behavior (waking up the wrong thread) you didn't expect. You just get hard to understand race conditions which are always a pain to debug

Just say no to atomics (unless they're hidden in a well written library)

To clarify by "your code" I mean your code excluding a library. A good library would make it impossible to deadlock. When I wrote mine I never called outside code during a lock so it was impossible for it to deadlock. My atomic code had auditing and test. I don't recommend people to write their own thread library unless they want to put a lot of work into it

From my understanding this talk describes how he implemented a solution for a similar problem https://www.youtube.com/watch?v=Kvsvd67XUKw

I'm saying if you're not writing multi-threaded code everyday, use a library. It can use atomics/locks but you shouldn't use it directly. If the library is designed well it'd be impossible to deadlock.

In October alone I seen 5+ articles and comments about multi-threading and I don't know why

I always said if your code locks or use atomics, it's wrong. Everyone says I'm wrong but you get things like what's described in the article. I'd like to recommend a solution but there's pretty much no reasonable way to implement multi-threading when you're not an expert. I heard Erlang and Elixir are good but I haven't tried them so I can't really comment

That's the best answer. Just wondering because you have a lot of experience and many people disagree with me.

How realistic is a C++ compiler that's 50x faster than clang for debug builds? Assuming 1) there's enough work for each core 2) there's so many files/headers that a unity build takes 1/4th of the time as a rebuild using individual files (this theoretical compiler would be multi-threaded)

I've been meaning to ask you what the motivation of your project is? Why would you want a safe-c? When I saw the headline I was worried that all my runtime code would break (or get slower) because I do some very unsafe things (I have a runtime that I compile with -nostdlib)

I'm also tempted to write a commercial C++ compiler, but it feels like a big ask, paying for a compiler sounds ridiculous even if it reduces your compile time by 50x