TransAtlToonz
So why insist on c? This seems to directly contradict your terms. Surely not pissing people off would imply not using c.
> Given that they've gotten a ton done in 30 years, I would suggest that either a) your understanding of their conflict-resolution process is wrong, or b) your assertion that this conflict-resolution process doesn't work is wrong.
Ah you forgot the solution where the people win. This necessarily implies evicting the c purists.
Like who gives a flying fuck about languages outside of safety. These people are just assholes
Like who would even claim american bankruptcy as a bad thing? Are you even american if you don't declare bankruptcy? We were founded on incompetency and we will die by incompetency.
Why not? That's the really juicy part of the pitch. Who could claim this is bad? Edit: yes i get there are linux vets we need to be tender with. This shouldn't obstruct what gets committed. If any linux developer offs themselves i ain't gonna resurrect C just to curse their grandchildren
> R4L is about new drivers. Not even kernel subsystems, just drivers, and only new ones. IIRC there is a rule against having duplicate drivers for the same hardware. I suppose it's possible to rewrite a driver in-place, but I doubt anyone plans to do that.
...if this is what linux conflict resolution looks like, how the hell did the community get anything done for the last thirty years? What does successful conflict resolution even look like? If this isn't ossification, what is?
Still curious to hear your responses, btw. You quarter-assed this reply so I'm sure your next one's gonna be a banger.
Presumably, this is an investment in replacing code written in C. There's no way around abstraction or overhead in such a venture.
> there's no way it doesn't significant put additional pressure when making breaking changes
This is the cost of investment.
> The natural reaction is that there will be less such breaking changes and interfaces will ossify.
A) "fewer", not "less". Breaking changes are countable.
B) A slower velocity of changes does not imply ossification. Furthermore, I'm not sure this is true—the benefits of formal verification of constraints surrounding memory-safety seems as if it would naturally lead to long-term higher velocity. Finally, I can't speak to the benefits of a freely-breakable kernel interface (I've never had to maintain a kernel for clients myself, thank god) but again, this seems like a worthwhile short-term investment for long-term gain.
> In addition, depending on the skill of the "binding writer" (and generally, since the rust bindings are actually designed instead of evolving organically), the second set of interfaces may simply be actually easier to use. There may not even be a point to evolving one interface, or the other. Which just further contributes to splitting the project.
Sure, this is possible. I present two questions, then: 1) what is lost with lesser popularity of the C interface with allegedly less stability, and 2) is the stability, popularity, and confidence in the new interface worth it? I think it might be, but I have no clue how to reason about the politics of the Linux ABI.
I have never written stable kernel code, so I don't have confident guidance myself. But I can say that if you put a kernel developer in front of me of genius ability, I would still trust and be more willing to engage with rust code. I cannot conceive of a C programmer skilled enough they would not benefit from the additional tooling and magnification of ability. There seems to be some attitude that if C is abandoned, something vital is lost. I submit that what is lost may not be of technical, but rather cultural (or, eek, egoist), value. Surely we can compensate for this if it is true.
EDIT, follow-up: if an unstable, less-used interface is desirable, surely this could be solved in the long term with two rust bindings.
EDIT2: in response to an aunt comment, I am surely abusing the term "ABI". I'm using it as a loose term for compatibility of interfaces at a linker-object level.
Fuck the democrats and fuck the democrats for the last forty years. This still sucks ass. The people doing this have utter contempt for the people who live here.
EDIT:
> At the same time, his companies have created seemingly impossible/fantastic technologies/tools that have changed the world forever.
There may be a reversal of causation going on here. It may be that Musk is attracted to successful companies, in which case he is at best an investor, and at worst a parasitic grifter. I see no evidence that he actually adds value compared to other competent people of average competancy. I certainly see no justification for him rampaging about our society destroying most of what remains of a state I actually am willing to associate with. Finally, I see extremely negative value in tying our state to a person who owns the thing that makes a critical asset (rockets). I'd much rather kick him out of our society in order nationalize the talent that we actually benefit from. Hell the employees would probably get a pay increase and we'd get a tax cut and only investors would be off worse (who gives a shit).
I just abandoned the code interview altogether and ask them questions about process. It's a very simple workaround, but very effective. I'll admit it helps that there are very few problems these days outside of specific problems to solve that require a high degree of technical competency to tackle.
EDIT: The process overhead seems straightforwardly worth it—rust can largely preserve semantics, offers the potential to increase confidence in code, and can encourage a new generation of contribution with a faster ramp-up to writing quality code. Notably nowhere here is a guarantee of better code quality, but presumably the existing quality-guaranteeing processes can translate fine to a roughly equivalently-capable language that offers more compile-time mechanisms for quality guarantees.
> Excluding places that do that leaves you with what exactly? Boutique shops filled with 20 year veterans?
We are on a VC forum—I imagine small shops focused on quality are quite common here.
Of course, this involves being honest with yourself about risk and reward, and we all have implicit incentives to disregard the risk until we get burned and learn to factor that in.
I don't see AI as a serious threat to the interview process unless your interview process looks a lot like hackerrank.
I say: give Iran and the DRC some nukes and we can finally enjoy the peace dividend we've been promised since WWII. Not comfortable with that? Well, that's about how I feel about the DoD.
Oh trust me it's still not that great a signal.
Hell, you can still rig a physical handset to work with bluetooth + cellphone and it'll guaranteed sound terrible.
EDIT: phrasing, wording.
That said, people have strong opinions on whether reference counting counts as GC. I say it does, but others are vehement that it does not. If it does not count as GC, I think Interlisp-D would qualify.
I also strongly suspect these numbers are misleading. I was offered another pair for free on opening a verizon fiber account. I'm betting there's some scheme to pump up these numbers to make it look like they're catching on. Though perhaps this skepticism is negated by the increase in production.
Granted, I've seen a couple tiktokers use something like them, but I don't know what the experience is like getting that video out of Meta's grasp.
EDIT: added a couple thoughts.
Plus, it offers very little convenience for users vs just using a password manager. I realize figuring out the right bcrypt/datastore setup is kind of annoying, not to mention opening you up to liability, but it's always been worth it to me in the past.