There are many open source licenses that don’t force redistribution of the code.
Correct, I'm saying public domain never requires that which is different from open source licenses, which may require it (and other stipulations)
Readit Newslevodelellis commented on Stopping bad guys from using my open source project (feedback wanted) evanhahn.com/stopping-bad... · Posted by u/emschwartz
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)
levodelellis commented on How good engineers write bad code at big companies seangoedecke.com/bad-code... · Posted by u/gfysfm
I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong. His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misguided.
My instinct after reading this article is to pull back a bit and ask some larger questions. Why is it necessary for big tech companies to act this way? Why does bad code bother engineers so much? Are they actually misguided for feeling like bad code is a catastrophe, or is it really the fault of the broader economic sphere we all inhabit? Is it actually maturity to reconcile ourselves to drift powerlessly as faceless and titanic forces sculpt our reality? So many possible questions.
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
levodelellis commented on Why engineers can't be rational about programming languages spf13.com/p/the-hidden-co... · Posted by u/spf13
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
Dead Comment
levodelellis commented on Futurelock: A subtle risk in async Rust rfd.shared.oxide.computer... · Posted by u/bcantrill
Are you saying GUIs in general don't need multithreading or just that you think you haven't needed it so far? Or that you use some high-level async framework that hides just the synchronisation bits (at the cost of async type complexity)?
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
levodelellis commented on Futurelock: A subtle risk in async Rust rfd.shared.oxide.computer... · Posted by u/bcantrill
If you take programming serious, learn it.
With a library that encapsulates a low number of patterns (like message passing) you'll be very limited. If you never start learning about lower level multi-threading issues you'll never learn it. And it's not _that_ hard.
I'm not writing multi threaded every day (by far), but often enough that I can write useful things (using shared memory, atomics, mutexes, condition variables, etc). And I'm looking forward to learn more, better understand various issues, learn new patterns.
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
levodelellis commented on Automatically Translating C to Rust cacm.acm.org/research/aut... · Posted by u/FromTheArchives
> proper compiler
Not just compiler but GC as sell. So it does note solve same problem as Rust.
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
levodelellis commented on Automatically Translating C to Rust cacm.acm.org/research/aut... · Posted by u/FromTheArchives
The code I've seen that was autotranslated from C to Rust has an absolutely hopeless number of unsafe statements.
You're better off using Fil-C.
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
levodelellis commented on Futurelock: A subtle risk in async Rust rfd.shared.oxide.computer... · Posted by u/bcantrill
People are messing up any number of things all the time. The more important question is, do you need to risk messing up in a particular situation? I.e. do you need multithreading? In many cases, for example HPC or GUI programming, the answer is yes, you need multithreading to avoid blocking and to get much higher performance.
With a little bit of experience and a bit of care, multithreading isn't _that_ hard. You just need to design for it. You can reduce the number of critical pieces.
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