simplotek

> I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds.

I have to call bullshit on this claim.

CMake is at its hear a build system generator. It offers a high-level abstraction to define software projects, and it uses that abstraction to generate the actual build system. It can generate makefiles, but also Ninja, Xcode, visual studio, and even msbuild projects.

What actually does the build is not CMake, but make, msbuild, ninja, Xcode, or visual studio. Not CMake.

You run CMake once to generate the build project, and when you actually want to build the project you only call ninja or make etc.

To top that off, some of these build systems support build cache systems such as sccache or ccache. Plugging in one of these tools can easily drop build times to a fraction of the time. Literally. I had C++ projects which used CMake whose build time of a complete rebuild dropped to 15% of it's original time.

> People are making arguments here about whether it's legacy based on number of projects in C++ or # developers who know C++, and that's just wrong.

They are hype-driven cargo-cultists who embody the role of hype-driven fanboys mindlessly pushing a hyped technology.

No technical merit is presented other than cargo-cult aspirations, and to fill in the void in their rationale they resort to try to denigrate other technologies again through non-technical arguments.

The most pressing problem plaguing Rust is it's community and it's extensive use of ignorant and/or bad faith claims to upsell Rust while criticising technologies they know nothing about. Most of the people they are trying to pull these stunts are professional software developers with years of experience. Perhaps some of them know a thing or two about the technologies they've been using? Why does the Rust community think these stunts work in their favour?

The whole thread is silly, and I praise the patience of those when went through the trouble of explaining why these suggestions are silly.

> C++ just isn't a very expressive language and has a high impedance with cognition.

I feel that you are the very first person ever making such a statement. Can you provide what's your single best example showing C++'s inexpressiveness and "high impedance with cognition"?

> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

I've been working with C++ for a few years and did some work porting legacy apps to CMake. I've saw awful CMake legacy projects but since CMake 3.0 and the introduction of it's declarative way of setting up targets CMake is actually quite nice to work with.

What exactly does CMake do that you feel is "an ancient horrible mess"? Can you provide any specific example?

> But every time I have to set up a new project it feels like death by a thousand cuts

Which part of the following example is hard:

program(mynewproject LANGUAGES CXX)

add_library(libfoo STATIC foo.cpp )

add_executable(bar bar.cpp main.cpp )

target_link_libraries(bar libfoo )

Edit: and this message was downvoted? Seriously?

> What if it becomes clear across the industry that remote workers are first in line for convenience layoffs?

From the article:

"The Bay Area’s office market has been hit hard over the past two years, as companies pivoted to remote work and gave up real estate to cut costs."

It looks like remote work is not being singled out. In fact, it's pointed out as a cost saver.

What makes you believe that remote workers are first in line for convenience layoffs?

> This sounds good if family relationships are priority. I think networking and building professional relationships are often improved over in-person interactions.

I don't understand this comment. We're living in a world where the bulk of our social relationships have mostly an online component. Whether it is Facebook, Twitter, Instagram, slack, mastodon, WhatsApp, etc... It's all online. We search for jobs online. We have professional social networks.

And we're expected to believe that networking is either done in person or not at all?

Honest question: taking in consideration the major busts that are the T14 Armata or the BMPT Terminator programs, would Russia have the know-how in place to do anything with a Challenger?

> Ukraine does have a mechanized infantry core that's already done some pretty amazing offenses. But Ukraine obviously needs to make that core larger and stronger for the upcoming offensive.

It's also big news as an offensive in the south can cut off supply to Crimea and thus lead to a siege similar to the one of Kherson. It would already be very hard for Putin to endure more major defeats but Ukraine retaking Crimea or even Mauripol could ultimate sign Russia's defeat and Putin's demise.

> What goes to the heart of the entire issue is whether recommendation systems, as used by social networks, are inferring "what people like". That's the whole problem.

It really doesn't. You're trying to debate the semantics of the keyword "like", but that discussion is meaningless and irrelevant. The only objective fact about these services is that they use the data provided by users to infer the preferences they reveal. These services then use this information to meet the company's goals, such as meeting the expectations of paying customers. These paying customers include marketing companies, and their expectations include driving up user engagement and associate their programs with specific type of content.

You might complain about whether these goals are aligned with what you believe are some user's goals, but you'd be missing the fact that users of services like Facebook or Twitter are the product and not the customers. You're not paying for that click, the marketing company is. If customers pay for that click then this clearly means these services do a good job determining what users "like".

> No ad platform has access to what people "like", this is a psychological property of people that isnt measurable, and at least, isnt being measured.

You're either commenting on something you are oblivious about, or are pulling a red herring just to be contrarian.

Concepts like revealed preferences [1] are nearly a century old, not to mention the fact that the whole consumer behavior field as a whole has plenty of quantitative methods to infer "what people like".

Facebook and Twitter support a feature where quite literally users specify in no ambiguous term that they like something. Theirnl platform is so effective that their problem is filtering out bad actors.

Then there's also engagement. You can get a pretty good idea of what people are interested in by tracking what they read.

You might try to nitpick about the true meaning of "like" but you'd need to be really determined to intentionally miss the point.

[1] https://en.wikipedia.org/wiki/Revealed_preference

> They don't need to release the actual code, but releasing "these are the inputs we use, these are the high level functions of the pipeline, these are the outputs" would be enough.

I'm not sure you thought this problem through. Even if you can specify the inputs, the high level functions mean nothing and the output can and very often is determined by implementation details and the current state of the whole service.

Say for example that personalized recency search of tweets takes into account bad actors being banned/shadow banned/downanked. How exactly do you expect to specify what output you expect from your inputs and your high-level description of your pipeline when a specific spammer is downranked?

I'm sure you can setup a pretty little diagram, full of colors and nice rounded edges, but it would be completely meaningless as state matters, and it's practically impossible to specify what state a global or regional system has in place.

> But do you have any examples of this having ever happened?

Yes, there are whole Wikipedia lists of this having ever happened.

https://en.wikipedia.org/wiki/Interbank_network

This is no rocket science. I mean, even utilities grids in open markets work like this, for stuff like power and even gas. Nowadays even railway networks in Europe are decoupled from operators. Why do people still cling to old monopoly tales?

> (...) and they didn’t need to create/support/release those to achieve their goals.

I'm not sure about that. These framework projects sound like internal projects developed to meet internal needs and improve internal processes. The GraphQL concept and use case in particular, as well as API management tools, is something I've seen reinvented internally by companies to be able to simplify processes. You just hear about GraphQL because Facebook decided to release it publicly. Everyone else has been more or less reinventing the wheel to meet the same needs.

> I'm always more impressed that sites like twitter and facebook need so many engineers for what are fundamentally fairly simple platforms that haven't hugely changed in years

The bit that you get wrong is assuming that Facebook or Twitter are simple platforms, and that their main and most complex features is allowing users to post, search and read messages. This is entirely wrong as these platforms are actually ad-selling platforms and thus include region-specific services, localized ranking, all sorts of data harvesting, etc etc.

Also, as companies grow they start to feel the need to implement efficient development processes, and thus start to allocate resources to stuff like putting together their own build farms, CI/CD infrastructure, deployment auditing, etc etc etc. They also develop things like front-end and back-end frameworks. It's not like a random team at Facebook just signs up for gitlab and does all it's business from there.

> You do NOT want to return to that.

I'm not sure your assessment is reasonable. You're putting up a strawman by claiming that the only way to have shared infrastructure is to have an abusive monopoly that stifles innovation and screws consumers over. This is false. It's quite possible to have a single infrastructure provider that does it's job, such as a consortium of telcos shipping in to deploy and run shared infrastructure. There are plenty of examples of those types of initiatives in other areas, such as shared ATM networks, which provide a far better service than "everyone for themselves" deployments.

Amazon also announced a while ago they had adopted a new motto, which was something like aiming to be the world's best employer.

And on the very first moment their growth wasn't as fast as hoped for, they automatically fire a small army of employees by email and cut off their access.

> Yeah, extra work for overworked IT departments.

I'm not sure you're being serious. Wiping a laptop before getting rid of it is SOP for a IT department. This is hardly a new requirement.

Again, the only people impacted are those who want to leverage their ability to take over a laptop without authorization.

What's wrong with being able to use a single app to read all books?

> I just think the idea that reducing headcount is not a legitimate strategy seems naive to me.

This reads like a disingenuous attempt at a strawman.

It's immaterial if firing people is a legitimate strategy or not. The whole point is that executives get little to no repercussion for dictating layoffs, regardless of the company's health.

They wake up one day, can decide to fire 10k people, order HR to prune the loose ends to meet the target, tell the assistant to write a heart-felt "I take full responsibility" email, and get back to browse the web or sip lattes or go for a nice walk like nothing happened. In the end they can even get a raise out of it.

Meanwhile, 10k workers are screwed.

The incentives are all wrong.

> This is not true. Most executives' compensation is tied to equity. For example, Tim Cook's base pay + bonus is 9M, but he has 40M in equity comp (performance + time based).

Tim Cook is still getting paid millions. His pay cut was voluntary.

Workers getting fired are getting zero salary and are not leaving because they want to.

I'm sure Tim Cook isn't stressing about how to make rent or pay the mortgage, unlike people getting laid off.

I don't understand the question. Do you mean all executives are irreplaceable?

> Cut the dividend, not exec compensation.

Also, stock value definitely needs to be in the equation. It makes no sense to fire people if the company's valuation is increasing and thus stockholders are getting richer.

> Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms.

See, this is yet another instance of the strawman argument I pointed out.

This is not a "enough time" problem. It's a resource allocation problem. Time is irrelevant if no resources are allocated to a task. Rust does not add manpower to rewrite things.

Rust fanatics just perpetuate survivorship biases because the project they did with the express purpose of fixing a specific issue ended up fixing the specific issue, and proceed to somehow go the cargo cult way and praise the framework instead of the rewrite effort. It's disingenuous and a gross misrepresentation of reality, and one which will inevitably come around to bite Rust in the ass. We already see backpedalling with regards to some of these claims once Rust started showing up in SVEs.

> I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care.

I don't agree, specially considering legacy code. Those of us still have to deal with an awful lot of code written 10 or 20 years ago still have to maintain code that juggles pointers and references around in ways that are hard to track ownership, and migrating this code to C++11 is no simple task. This doesn't mean people don't care. It just means the industry cannot afford getting whole teams to spend a couple of years on sabbatical to refactor legacy code and pay it's legacy debt.

This is perhaps the biggest strawman that Rust fanatics use to criticize all things that isn't written in Rust. They pick their small little greenfield modules and boast how safe and perfect it is, and proceed to criticize all legacy production code whose teams can't even spare time to fix long standing bugs, let alone pay off technical debt. And that's somehow something Rust fixes?

> Tells me he doesn't really "get it." People do not follow the core guidelines, and other languages are designed such that there aren't guidelines.

I don't think this is true at all. There are already a few popular static code analyzers and lingers around which integrate quite nicely with your run of the mill build system.

The purpose of these static code analyzers and linters is none other than enforce the adoption of stuff like the C++ core guidelines in a workflow a kin to unit testing.

How do you explain that, based on your personal assertion that no one bothers with those? I mean, even popular C++ IDEs support those out-of-the-box.

I really do not understand this absurd idea that those who care about safety drop everything they're doing to mindlessly migrate all things under the sun to a programming language, and the only ones not doing that are the poor incompetent fools who foolishly don't succumb to this cargo cult nonsense.

> I would personally choose Rust over C++. I dislike the number of gotchas that C++ has and I think the language has gotten too big and complex to use safely.

This take sounds like fomo mixed with cargo cult programming.

When you write something in C++, nothing forces you to use all features of C++. There is no bingo card you have to fill to get your project to compile. You just pick the things you feel serves your purposes, and stick with them.

I don't really understand this irrational take. It's like claiming they don't want to speak in English because the dictionary is too large and some words are too tricky to spell to use in a conversation.

> That is provably false:

You're confusing things. Google's example focused on rewriting specific components with a specific goal in mind: fix/avoid unsafe memory access. The examples in that blog post consist of major rewrites of huge software projects like browsers, whose goal was to be feature complete.

Those are quite different things.

> (...) instead of this kind of stuff that really doesn't improve life all that much for most development

There are comments in this very discussion praising this change due to how this stuff really improves their life as a developer.

Anyway, can you pass the link to your JEP with a proposal for "?." ?