simplotek

> Any tips for giving feedback to senior people here? A lot of the complexity from abstraction is very hard to quantify and experienced people can have arguments that sound reasonable.

Perhaps a starting point for this discussion is to point out that the DRY principle is nice and all, but there is also WET. Premature abstractions are bad code, a liability and hinder development. It's always better to have two independent but mostly similar codepaths than a strategy pattern with two concrete implementations. If it's cleaner to copy/paste a method and do some tweaks, do that instead. It's not like you can't refactor it when additional use cases emerge, and if they don't emerge then the abstraction wasn't needed to begin with.

Plenty of people believe that being senior is being clever with complex stuff. It isn't. Being senior is to know you don't need complex stuff, and be able to keep as simple as possible. Abstractions go against that.

> They are aware of things like the separation of concerns, but as soon as they run into a situation wheres its easier for them to leak one layer's concern into another they will do so.

That says nothing without context.

If you want to move fast then it's ok to break things, and leaking layers is far from a non-negotiating tradeoff. Software is soft, and you can always revisit a piece of code to refactor it to suit someone's architectural tastes.

It makes no sense to criticize someone for focusing where it matters the most and actually deliver critical features without delay if the tradeoff is some legacy debt, and that by no mean implies they're junior.

One important skill of a senior is being able to keep their eyes on the prize and be smart about tradeoffs. Prioritizing subjective opinions over software architecture over delivering value is more in line with a junior way of thinking about software than not, and to me doesn't sound like a position to criticize others.

> The Socratic method for teaching is actually quite good, and it can be employed without condescension.

I seriously doubt a PR is the right medium for the Socratic method, or that trying to employ it in that venue can sound anything other than condescending.

PRs are the end result of the developer's work to address an issue. Communication through a PR is asynchronous and inefficient wrt time. Engaging in gratuitous chatter in PRs actively blocks the developer from delivering his work. Pushing for needless iterations with cryptic open-ended questions where you force a developer to be on the defensive reads as if you're standing in the way while gratuitously questioning someone's ability in a very public way through a medium designed to persist discussions til the end of time.

If a PR has an issue just do the right thing and go straight to the point. If you feel the need to get into what you feel are teachable moments, reach out to the developer through your choice of direct chat.

> The Egyptians built a wonder of the world before the invention of the wheel

You might find this link interesting

https://journals.uair.arizona.edu/index.php/jaei/article/vie...

> I don't believe in collective guilt. If 10 or 20 or 200 assholes out of group of 30000 do something stupid, do you sentence the 30000 or the assholes, even if the rest of community has distanced from it?

You mentioned Reddit. Rust's subreddit had at the time over 80k subscribers. The subreddit massively piled on the maintainer of Actix. This harassment campaign was so massive that core Rust members felt obligated to write public declarations how Rust should invest in community building and, with the Actix case as an example, whether they could actually reject contempt culture.

It was not an isolated bad apple. Rust's community is renowned for being toxic, hostile and abbrasive. This topic is underlined time and again even in HN. It's not possible to hide this fact.

> There is a huge gap between something like boost that is designed to be reused and internal libraries that are subject to the usual corporate constraints (the least amount of work is done if even that)

You're somehow trying to imply that libraries are not reusable if they are not widely shared, which makes no sense at all.

The best argument you could make is regarding stability, but you simply cannot lay any such claim just from the library's licensing.

Accusing internal libraries of being half-baked, badly designed, or bug-riddled is just a cheap blanket putdown.

> Even the author mentions that he intends to rewrite everything he ever writes in some memory safe language he's building.

It's a framework. It's a set of C macros and C code. It's not a new language. Please stop.

> Arguments like this sound like old arguments that were re-told to me by my father where people argued that C couldn't replace the use case for Algol at the University of Michigan MTS system.

The problem with those comments is that they are intellectually lazy, and use age as a proxy for "better". Language X can be designed with specific features in mind that offer interesting features that Language Y fails to offer, but that is not ensured by the release date, nor might that be an acceptable tradeoff when considering other factors.

> Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field.

Is it really that fundamental if you can setup your project to throw warnings/errors, and even use static code analysis tools to flag those?

I'd argue that it's far worse to work on a project that's not setup to detect those errors than to expect that sort of issue to be handled at the recruiting level.

> Null was a trillion dollar mistake.

I don't agree. Null is just a tombstone value. If you're dealing with specifying memory addresses, you either specify the address or point a value that tells you the variable is not pointing to an address.

If anything, conflating arrays with pointers was a bad idea. The language would be far better equiped to deal with memory safety issues if an array data type included info like total size, used size, and perhaps also stride length. Relying on tombstone values to delimit strings or arrays was just prone to blow up on everyone's face.

> I don't limit my statement to just C. The topic was C however so I mentioned C.

Your comment reads like a red herring though. You're not actually trying to argue that C makes thing easier or hard. Your red herring only means that hard problems affecting all languages aren't magically turned into non-issues in C. You can still write a C program that uses threading and is as safe as any other language and end up being a far simpler project, but that means nothing because the subject is still hard. And what would that actually say about C, let alone refute?

> I think these people are just not very good managers and they don't care much about the people they hire.

The diktat to fire people didn't sprung from the same org level that was tasked to do the firing.

Those who ordered X% to be fired didn't even bothered with freezing hiring.

In cases like Amazon, apparently they even forbade internal transfers.

> But some people just do it out of curiosity and wanting to know how things work from the ground up.

And that is perfectly fine.

Some people also get a kick out of learning Esperanto or Klingon, but that doesn't mean those are critical subject areas that you need to to excel in any professional domain.

> Don't judge community (especially one you don't know) by their worst member.

The community was massively represented in that harassment campaign targeting Actix. We can still read the threads and the bug reports that fueled that shit show. Things got so bad that distinguished members of Rust's core team felt compelled to put on their PR hat to work on salvaging Rust's reputation and do limitation.

It was not bad apples. It was a hallmark of Rust's community.

> (...) big shops that did some programming would have their own languages, which continued into the 00's in the form of everyone rolling their own C++ standard library.

It sounds like you're talking about using libraries as if it was a bad thing.

> had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff (...)

Where do you think "off-the-shelf" stuff comes from? It sounds like you're trying to mistepresent the adoption of subjectively sub-optimal libraries as somehow the issue caused by using libraries and frameworks.

> mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that.

You're showing a tremendously naive and misguided belief that libraries are somehow bad.

Languages such as Rust flourish with the adoption of third party libraries,some of them euphemistically described as "not stable". Languages such as C++ flourish with third-party components like Boost and POCO. But applying the same principle to a language like C warrants an automatic and mindless putdown like blindly accusing anything of being bad? It makes no sense.

> People threw a fit, and it got patched.

By "people threw a fit" you mean the Rust community put up a relentless harrasment campaign targeting the project author, even to the point where they involved their employer, and ultimately forced the maintainer to give up on FLOSS and abandoned the project altogether.

> This means you have some guarantees about the whole ecosystem.

Sure, you are free to make this sort of claims. But they are besides the point, aren't they?

The cliche being discussed here is C's hypothetical ties with memory safety issues, and here we are commenting on a discussion on how someone writes C using a framework focused on memory safety and thus providing "some guarantees" about their whole ecosystem. Yet, we're still seeing comments mindlessly parotting myths in spite of the facts that are being dangled right in front of their nose.

> so the article being an account of the guy's journey using C seems highly appropriate.

More importantly, it goes against the cargo cult narrative that the choice of programming language is the one and only factor determining memory safety, and consequently any use of languages such as C automatically leads to security issues.

It's not a coincidence that we have people in this discussion coping with that concept by spinning the use of frameworks focused on memory safety in C applications as somehow representing writing code in an entirely different programming language.

Sure.

* https://www.theregister.com/2020/01/21/rust_actix_web_framew...

* https://news.ycombinator.com/item?id=33391344

> Some over zealous Redditors doing Redditor things.

Except that this was not a Reddit problem, was it? This was a problem created by the Rust community that showcases exactly the "Rust Evangelism Strike Force" behavior we're talking here.

Would it made it a Mastodon problem if the Rust fundamentalists opted to use that to drive their relentless attacks? It wouldn't, would it?

I mean, it surely wasn't a GitHub problem when these Rust evangelists started harassing the maintainer through bug reports, which was the place where it all actually took place.

> The article itself is basically this guys journey with C and the steps he takes to get something other languages now build in (...)

Not really. The author describes he put together a framework for C that implements memory safety features.

Isn't it intellectually dishonest to criticize the adoption of libraries that provide features that other languages may or may not have built in?

What's the end goal exactly? Use safety features to write safer software, or attack anyone that hasn't mindlessly jumped onto a particular bandwagon?

I'm sure even the most militant of CCP members would agree that genocide is not a key factor in China's economic growth.

> The "Rust Evangelism Strike Force" isn't actually a thing that exists. (...) It's not a core policy and basically all serious Rust users don't do any of the alleged activities claimed to happen.

If that was remotely true how do you explain the Actix episode?

> Yeah, you can always ship a shitty SaaS or plug libraries you don't understand into each other and still make a lot of money.

What you're failing to understand is that the SaaS or plug libraries are not shitty. They might even be better than anything someone who reads SICP like the bible can possibly put together. Why? Because they focus on the right level of detail and abstraction instead of wasting time and effort on irrelevant and useless details. And they deliver it far faster.

I repeat: the StatsD daemon is written in Node.js. it's a >100MB Node.js application to receive, aggregate, and send UDP packages. The StatsD daemon is perhaps the most popular metrics sidecar out there, and no one cares it's not a 1MB C app.

> Statsd is like ~4000 lines of code, which is absolutely tiny; it's a trivial codebase.

Don't you get the point? It's a Node.js app that took a few lines of code to out together to handle UDP packages. Writing the same thing in C would not be hard and it would be far more efficient, but it would be entirely pointless because slapping together a Node.js application performance wise is already good enough. What does this say about the cargo cult beliefs of SICP fundamentalists ?

> You can't write fast JavaScript if you don't know how arrays are represented in memory.

Sure you can. You just hear that arrays are faster and use those not bothering with any irrelevant low-level detail. And who exactly advocates using JavaScript for a UDP server and mention performance needs with a straight face?

> You can't optimize SQL queries if you don't know how a database works.

Don't you get the point? The point is that you don't need to waste your time bothering with performance tuning if your goal is designing a working system. Bothering about irrelevant details like that is a waste of time. Decades ago someone smart already stated that premature optimization was the root of all evil. The first rule of software optimization is "Don't". And here you are trying to argue that being bothered about low level details is relevant for the sake of optimization? Don't.

> The difference between trade schools and universities is in the depth of fundamentals.

It's definitely nonsense. You're failing to understand that today's "fundamentals" are not the parlour tricks you have in mind. You're in a better position to get ahead in providing software development services if you're able to put together a customized script that launches traefik, nginx, rabbitmq and a few nodejs services fully dockerized than if you're able to tell what opcodes your compiler generated out of C code.

> I meant profit, not revenue

Honest mistake. Happens to the best of us.

Still, regarding profit, I'm not sure that firing people in profitable companies effectively contributes to higher profits. Sure, you pay fewer salaries. However, that comes at a cost, such as supposedly cutting programs the company deemed valuable and eroding the company's ability to conduct their business.

Also, it seems Google's reaction to drops in profit was to fire 6% of their staff. Does that even register in Google's accounting? I mean, payroll is typically 20-30% of a healthy company's expenditure.

And would a hiring freeze not reach the same goal without causing any disruption? I mean, apparently Google is still hiring and has a large volume of job openings. If the amount of people in their payroll is too much as is then why are they hiring even more?

https://careers.google.com/jobs/results/

> Interest rates go up, future revenue becomes less valuable (...)

I don't think this is true at all. Central banks hike interest rates to limit and reign in inflation. It's the exact opposite of what you claimed.

If you get upset by people who state that genocide is bad, you're rooting for the bad guys.

> This change is necessary because young people aren't interested in the fundamental abilities of computers, instead they're only interested in the applications.

I don't think it's fair to spin this on lack of interest. My take is that young people are smart and they are goal-oriented, and their goal is to actually provide value instead of wasting time with irrelevant low-level details that matter nothing and are practically meaningless.

And they do it just like the generation before them did. No one bothers with knowing how to put together opcodes once they got around to use compiled languages. Some people do quite well for themselves in the software engineering field without touching a compiled languages even once, and thus can't be bothered with subjects like linking, how to create and consume static lib, rpaths, finding symbols, etc. You can have high-paying careers in software engineering and never be bored with the difference between a stack and a heap. Popular tools like the StatsD daemon are written in Node.js, and no one can be bothered about it.

So why pretend that knowing how things work from the metal up is relevant to get an understanding of how things operate? I mean, most services don't even operate on metal, but on interpreters running on containers launched from virtualizations.

To each its own, but let's not fool ourselves into believing that in a world of countless layers of abstraction it's relevant to dive into the lowest of levels.

> Excel at what? You need to build a strong foundation in order to innovate and to discover new stuff.

I agree. The problem is that you have a gross misconceptions about what "strong foundation" represents in this day and age.

I knew guys who fail to stop and think about "foundations" and instead use that as a scapegoat to shoehorn their gatekeeping logic and as a form of ladder-pulling. It's the kind of character who think that playing trivia games is a good way of asserting whether a candidate is a competent engineer.