2
points
levodelellis
Joined 187 karma
- levodelellisCorrect, 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
- I don't remember, I grabbed a project that I can't remember the name of and compiled something else first to warm up the compiler then compile the project. I tried several times and it seemed to be consistently < 100K
- I'd call it not terribly slow. IIRC it didn't hit 100k lines on an M2, while I saw over two million on my own compiler (I used multiple instances of tcc since I didn't want to deal with implementing debug info on mac)
- Yes. I once was thinking I should write a x86-64 codegen for my own compiler, but using tcc I was able to reach 3 million lines in a second (using multi-threading and multiple instances of tcc) so I called it a day. I never did check out if the linking was in parallel