Rui, if I ever get rich, I will seriously give you 1 million US dollars, $100K the minimum, for everything you have done so far, with all your projects.
That's the least I can do to show my appreciation for your incredible work; I can't thank you enough brother!
I also wish to see that chibicc compiler plus the book completed. I want to learn everything around such topics.
I don't know the details, but once it is proven that achieving lld/mold/sold-level performance is technically feasible, it shouldn't be extremely hard to achieve similar success for macOS.
CRT object files which contain process startup routines are not in a fixed directory. Unfortunately compilers have to be hard-coded to contain an appropriate directory name.
Well, can't that be made a build parameter, that can be determined during build configuration? CMake'ifying the project might help you get there perhaps?
So the chibicc book is not available yet. I'm busy working on the other project (the mold linker) and don't have time to work on it. That being said, I believe the repo is still very valuable for those who want to learn how easy it is to implement a simple C compiler. chibicc's each commit was carefully written so that you can read one commit at a time. I'd recommend starting from the initial commit and observe how each feature (`if`, `for`, local variables, global variables, etc.) is implemented by following each commit.
I'm charmed by projects like this, thanks for sharing.
What I want to see is a program like this, with very simple assembly/object code, and very fast compilation, and uses DynASM to build the executable in-memory.
Then use a tracing JIT to make it fast.
Having good, tiny, reference C compilers is a prerequisite for that, so I'm always happy to see work in that field.
I am interested in this too. I would do different tradeoffs. I am more interested in optional garbage collection, the parallelism and async story in the language such as threading and coroutines or both together.
I suspect combining garbage collection, exceptions, closures, tail call optimisation, parallelism, JIT compilation and coroutines is difficult to do orthogonally.
On eatonphil's discord someone recently shared this link: This is a framework for building high performance language runtimes
> It didn't work. If it is available as open-source, they don't _need_ a different license.
Don't they? I'm surprised to hear that. I have sold a few proprietary versions of my AGPL codes (which were identical to the original one, but with the license stripped). Not enough to make a living, but I can buy some fancy bikes with the money.
In some cases, they even paid --separately-- for support and a few features of the software that were of particular interest to them. For some reason, many companies are extremely frightened of the AGPL, but a dual AGPL/commercial licensing seems to fit them very well. This is a nice model for free software distribution, but it only suits small projects that do not get external contributors.
I could buy bikes too, but as you wrote that's not enough to make a living. This is my full time project. I could earn a mid 6 figure salary if I work for a big tech, and I think I'm creating a more valuable program than I did when I was working for a big tech, and in return I make money that counts in "fancy bicycle" unit... I think it's not wrong to say it didn't work quite well.
I might get shit on for saying this here, but I agree with you that it's very difficult to make a decent living on fully "free" software.
I've had orgs not bat at an eye paying a few thousand for a software license if there are justifiable productivity returns and the license is required for us to continue to use the software.
If that license is not required, we would never give you a dime. It's sad, but true. Those few thousand, to many companies, are pennies on the dollar. Just price it graciously so you don't leave the little guys out.
You'll get grumbles but do what you need to survive if you want to do this full time and for a living. God knows you, of all people, have earned it.
I think I recall you saying that you elided the bugs, yeah? (Am I under-caffeinated this morning?) If so, you could write a second book about the bugs and issues you encountered while implementing chibicc and, uh, that would be awesome too! (I'd buy a copy.)
mold/macOS aims to be a drop-in replacement for the Apple's ld. I don't think it supports all the feature you mentioned already, as it is still pre-Alpha. But we are working on it to make it "just work".
I dislike "contact us for pricing" too, but pricing is hard! I don't know how much I should ask for. This is also a bit unusual business model because mold can be used for free. I'm happy if users pay me 10%-20% of the total cost they could save by using mold though.
$200K is nowadays an annual total compensation of a junior dev. I believe mold values much more than a one year outcome of a typical 5-person junior dev team.
Not even in most of the U.S. I’ve never broken that salary in the Midwest and I’ve gone from Junior to SWE to Senior to Lead to Manager to Director. Even in total compensation it took me until Director (managing managers who in turn manage individual contributors) to reach that level.
In my country, $200k is what a senior dev makes in 10 years. The issue is, I very much doubt people like Rui could be expected to live in places like mine. So comparing against US salaries is probably what you should do anyway.
I'm curious - is that salary difference enough to cause a significant brain drain? Can you hire really good developers for that price in your country?
I live in the UK and dev salaries are maybe half of the US, but people don't leave in droves because there are other factors - family, friends, quality of life, effort of moving your life across continents, etc.
Sure. Significant brain drain might be an understatement — I don't think there are any excellent developers left here (if there were any at all). Anyone half worth their salt either moves to Russia where there was a decent IT sector up until the recent events, or wins a green card/marriage lottery and leaves for the West. FWIW I'm not leaving because I didn't want to live in Russia even before the war started (and even less so now), and I'm not good enough to emigrate to the West.
I am sorry I was not trying to undermine the value of Mold. I was told the average / median of Junior Dev are't even $200K in FAANG. But then I dont work in the US so I dont know.
( I hope more US companies are opened to truly remote )
I didn't take it as an offense, so don't say sorry! I just wanted to say that if a senior dev wants to earn $1M in a few years, they can just find a job and do whatever assigned to them there. They didn't have to take a risk of starting a completely new ambitious open-source project to earn that much.
Please give a list of companies (Europe/Japan) where I can apply for such a salary. I started working recently and I'm at more than 10 times less than this...
I don’t know much about the European job market, but you can see lots of examples of US job positions and their salaries at websites such as https://www.levels.fyi.
Build times are a huge issue impacting how fast I can develop at my job (and I'm fairly certain that's the norm for my team), and I suspect that using a faster linker would mitigate that by a significant chunk. Unfortunately I'm just an IC and don't have the authority to look into something like paying for this, and I'd likely need to actually try it out and show numbers for how much things would improve to get management interested in actually looking into this. Because the project I work on requires interfacing with some cloud services that I can't connect to locally, I would either need to actually build on one of our cloud servers or compile the entire thing locally and copy it over, but I imagine the performance gains from multithreading would not be nearly as great on the 8 cores on my laptop compared to the 64 on my cloud server. I'm a bit hesitant to take initiative and just try this out due to the AGPL license though, since IANAL and I imagine if I tried to get permission for this internally, I'd run into the circular issue that without data to show it's worth it to look into, I'd probably just be told not to do it.
Basically, I think your best chance of generating interest from this is the bottom-up (since the individual engineers are the ones who would be feeling the pain that this could help solve), but I'm not really sure ICs at the companies large enough to be potential customers for this have any likely path forward with the way you've structured things right now. I'm not sure if you're flexible on this at all, and obviously I can't guarantee we'd get anywhere, but if you're interested in hearing more details about the potential use my team (and probably a number of other teams at my company would be able to make use if we were able to work something out), feel free to email me! Any prefix @<my username>.com will forward to my gmail.
I was joking and I don't think you need a price on there. But if you're serious, you can put out an asking price and everyone involved should just assume it's negotiable. Just use something like a couple of million USD as a starting point.
> This is also a bit unusual business model because mold can be used for free.
You're selling the copyright, right? That's ok - businesses pay for stuff like this. Although I wonder if instead you'd be better off if you created a corporation and instead offered to sell the company's IP + your commitment to support the work over ~1-2 years. This might be a more common scenario for M&A teams to work with. Especially if you are keen on supporting more target architectures/OSs. Someone like ARM or SiFive or FAANG would easily shell out that kind of money to get mold.
If it takes 20 seconds, you go for a coffee or switch the window to start web browsing, but if it takes only 2 seconds, you can wait without being distracted. So it's more than just saving 18 seconds for each build. It wouldn't interrupt your flow.
Jesus. What product? The only thing I've ever worked on that got close to that was a compiler that built LLVM and Boost. LLVM takes like 40 minutes on a laptop.
