Pair this with the fact that most people settle their musical tastes to be in line with when they are experiencing the most emotionally significant time in their early lives (high school for some, college for others, etc) and the result is an assumption that

A) What they encounter forms an overall opinion of "all" new music despite being the tip of the iceberg and

B) It's not as good as what they grew up on

Another little cut on why people are trusting big tech less ad less.

It's always noise to people that don't care, but matters to people who rely on AOSP, including third-party ROM developers.

As others say, it breaks contributions and any chance that other forks will keep up.

And think about all the merge conflicts you have to resolve after 3 months of code changes.

The obligation is specifically to provide the source code (without certain usage restrictions) for binary releases when requested, and no more.

Lol nice pipe dream. The source isn't even fully released today.

Note that the demand for secrecy is primarily driven by device manufacturers, not Google. Manufacturers want to keep their "secret sauce" from their competitors.

It's about understanding how a society can change due to climate change, not understanding the actual mechanics of climate change. Do you think that understanding whether or not conflicts stemming from climate change are not useful?

  cartels in Colombia, not Mexico

> the Ombudsman’s Office, an agency of Colombia’s Public Ministry, highlights the presence and the areas of operations of three of the strongest Mexican drug cartels: the Jalisco New Generation Cartel, Los Zetas, and the Sinaloa Cartel.. there is a belief among foreign consumers that Colombian drugs are of high quality, so the narcos capitalize on that.

  the goal of the research is to prevent people from joining crime organizations, not how to catch existing heads of criminal organizations

History suggests cutting off the head of a drug cartel is just a Tier 2 career advancement opportunity.

Did the aquisition of Joaquín "El Chapo" Guzmán as a token trophy head put much of a dent in the ongoing activity of the Sinaloa Cartel Ship of Theseus?

There's much to be said for understanding an organism (an entire cartel dynamic in this case) in order to eliminate it.

If not, what actions were taken based on previous social science research?

> Was this research the first social science project to seek an understanding of cartels?

Very probably not. Not in the US and not globally.

> what actions were taken based on previous social science research?

That'd be a question best answered by digging through the Hansards, Parliamentary Archives, Congressional Records, etc. of respective governments.

Political history would suggest that many good suggestions of social change were likely ignored in favour of operations with a lot of smoke and noise.

Likely to increase with terrorist designation, https://apnews.com/article/gangs-cartels-sinaloa-aragua-trum...

Organizations sometimes optimize for the problem to which they are the solution, https://news.ycombinator.com/item?id=39491863

Today that horse is dead and well beaten .. but maybe guns will solve things this time 'round.

Why not? That's a really broad brush.

The fact that we (somewhat) do it with biology is amazing.

That doesn't mean we should avoid spending money in hard to replicate fields, or that we should require impossible to satisfy bars for funding.

Some of the most interesting results in these fields come with further questions attached.

Also this might be a hot take, I don't agree with Elon or Vivek's plan to outsource, but I do think tech has done this to itself. Why are so many startups and tech companies so bloated with engineers? I worked at a company that sold VERY complex factory and plant monitoring software to companies around the world. It's engineering team was about 500 people supporting a wide range of products and different levels of the stack. Companies with way less complex software and less software volume have way more bloated engineering orgs and are way less efficient. Because, fundamentally most people are bad at software engineering (which is different from just programming and pure CS), including grads from MIT. A lot of companies are outsourcing because if everybody isn't that great, they might as well pay less for something that isn't good. The companies that have simple products and have crap engineers are the ones outsourcing.

Seems far more interesting than cobbling together CRUD apps but it seems tough to get into given the experience roles require.

I'd also learn a tool like yocto or buildroot, both tools for creating Linux images. They're not great tools, but they are widely used in creating embedded Linux images.

If you want to solve domain specific issues (like getting into DSP) or doing high speed networking, you have to find an entry level job in that field and have the requisite background. It's hard to do DSP without an EE background for example.

The problem I have with C++ (and I've written a lot), is every programmer involved in your project has to be 100% perfect, 100% of the time.

I know you can run memory checkers, and STL debug modes, but unless you are running these in release as well (is anyone doing that?), then you are then counting on your testsuite hitting every weird thing a silly, or malicious, user might do.

Given how important software is nowadays, and how Rust seems close to the performance of C++, is it really worth using a language where so many of the basic fundamental features are incredibly hard to use safely? They keep making it worse, calling an empty std::function threw an assert, the new std::copyable_function has made this undefined behaviour instead!

It was originally discussed as a way of avoid null pointers, for the common case where they are representing the possibility of having a value. However, it has exactly the same UB problems as a null pointer, so isn't really any safer.

I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience, of working on many large codebases, games, and seeing remote security holes caused by buffer overflows and memory corruption occurring in every OS and large software program ever written.

Also, that 'penalty' really does seem to be tiny, as far as I can tell. Rust pays it (you can use unsafe to disable it, but most programs use unsafe very sparingly), and as far as I've seen benchmarks, the introduced overhead is tiny, a couple of percent at most.

I don't think this is true. I don't think it has anything to do with null pointers, it is a standard way to return a type that might not be constructed/valid.

I think you might be confusing the fact that you can convert std::optional to a bool and do if(opt){ opt.value(); }

You might also be confusing it for the technique of passing an address into a function that takes a pointer as an argument, where the function can check the pointer for being null before it puts a value into the pointer's address.

I'm going to be honest, saying that memory corruption in C++ is 'almost never a problem' just doesn't match with my experience,

In modern C++ it is easy to avoid putting yourself in situations where you are calculating arbitrary indices outside of data structures. Whether people do this is another story. It would (or should) crash your program in any other language anyway.

Also, that 'penalty' really does seem to be tiny

The penalty is not tiny unless it is elided all together, which would happen in the same iteration scenarios that in C++ wouldn't be doing raw indexes anyway.

The paper that proposed std::optional literally uses examples involving null pointers as one of the use cases that std::optional is intended to replace:

https://isocpp.org/files/papers/N3672.html

Here is an updated paper which is intended to fix some flaws with std::optional and literally mentions additional use cases of nullptr that the original proposal did not address but the extended proposal does:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p29...

I am going to be somewhat blunt, but if you're not familiar with how some of the use cases for std::optional is as a replacement for using raw pointers, along with some of your comments about how C++ treats undefined behavior, as if it's just results in an exception, suggests you may not have a rigorous enough understanding of the language to speak so assertively about the topic.

I never said there wasn't a use case, I said it wasn't specifically about protecting you from them. If you put a null pointer in and reference the value directly, it doesn't save you.

If you don't understand the context of the thread start arguments over other people's simplified examples. I'm not going to write huge paragraphs to try to avoid someone's off topic criticisms, I'm just telling someone their problems can be avoided.

"I don't think this is true. I don't think it has anything to do with null pointers, it is a standard way to return a type that might not be constructed/valid."

This was in response to:

"It was originally discussed as a way of avoid null pointers,"

I have provided you with the actual papers that proposed std::optional<T> and they clearly specify that a use case is to eliminate the use of null pointers as sentinel values.

I'm not sure what your point here is other than to try to mince words and argue. It's a standard way to put two values together and what people were probably already doing with structs. You can put pointers into a vector too, but that doesn't mean it's all about pointers.

> The behavior is undefined if this does not contain a value.

The equivalent to this in Rust isn't `Option::unwrap`, which will (safely) panic if the value isn't present; the equivalent is `Option::unwrap_unchecked`, which can't be invoked without manually marking the code as unsafe. I've been writing Rust professionally for a bit over five years and personally for almost ten, and I can definitively say that I've never used that method a single time. I can't say with any amount of certainty whether I've accidentally used the deference operator on an optional type in C++ despite writing at least a couple orders of magnitude less C++ code because it's not something that's going to stick out; the deference operator gets used quite often and wouldn't necessarily be noticeable on a variable that wasn't declared nearby, and the compiler isn't going to complain because it's considered entirely valid to do that.

[1]: From https://en.cppreference.com/w/cpp/utility/optional/operator

That's just fundamental difference of opinion, Rust isn't designed for efficiency, it's designed for safety first. C++ unofficial motto is, don't pay for what you don't use.

If I type *X why would I pay for a check if its empty, I literally should have checked the value isn't empty.

If you work in a code base with people who don't check, your codebase doesn't have static analysers, you do no code review and dereferencing an uncheck optional get's to production, do you think a .unwrap in rust wouldn't have made it to production?

Also, an unwrap isn’t perfect, but it’s much better than UB. It asserts. No memory corruption, no leaking all your user’s data, no massive fines.

The equivalent to C++ would be an unchecked unwrap in an unsafe code block, and that would throw up flags during review in any Rust codebase.

EDIT: an unwrap that crashes in a panic is a dos condition. In severity this might be worse or better depending where it happens.

Both are programmer error, both should be caught in review, both aren't checked by the compiler.

Citation needed, because Graydon Hoare the original Rust creator (who has not been involved with Rust development for quite a long time) wrote about how the Rust that exists is not like the original one he was designing:

- "Tail calls [..] I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them which is one of the saddest things ever written on the subject. It remains true with Rust's priorities today"

- "Performance: A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good. It's a C++ idea and one that I think unnecessarily constrains the design space. I think most abstractions come with costs and tradeoffs, and I would have traded lots and lots of small constant performancee costs for simpler or more robust versions of many abstractions. The resulting language would have been slower. It would have stayed in the "compiled PLs with decent memory access patterns" niche of the PL shootout, but probably be at best somewhere in the band of the results holding Ada and Pascal."

https://graydon2.dreamwidth.org/307291.html

I think you would have a hard time convincing the C++ standards committee to put a checked container in the standard, maybe now with the negative publicity maybe but definitely not before.

I'm guessing it would be impossible to get an unchecked container into the rust stdlib.

There clearly are people who think that UB isn't as dangerous as I do, so if that's where you stand, I guess it is just a "fundamental difference of opinion". If you actually believe that you (or anyone else) is capable of being careful enough that you aren't going to accidentally write code that causes undefined behavior, then I don't think you're wrong as much as delusional.

It would (or should) crash your program in any other language anyway.

To me there is a massive difference between "there is a way a malicious user can trigger an assert, which will crash your server / webbrowser", and "there is a way a malicious user can use memory corruption to take over your server / webbrowser".

And bounds-checking penalties are small. I can tell they are small, because Rust doesn't have any kind of clever 'global way' of getting rid of them, and I've only noticed the cost showing up in profiles twice. In those cases I did very carefully verify my code, then turn off the bounds checking -- but that's fine, I'm not saying we should never bounds check, just we should do it by default. Do you have any evidence the costs are expensive?

As someone else mentioned you can boundary check access if you want to in C++ anyway and it's built in to a vector.

My point here is that it isn't really a big problem with C++, you can get what you want.

Note that this is not something C++ is able to do, and C++ has notoriously subtle iterator invalidation rules as a consequence.

Note that this is not something C++ is able to do

Or you could just not mutate the container.

They said "bounds-checking penalties are small" not that it was free. You've described a situation where bounds checking happens and declared that it "should be" expensive because it happens. You haven't given evidence that it's expensive.

You can profile it yourself, but it is the difference between direct access to cached memory (from prefetching) and two comparisons plus two branches then the memory access.

To someone who doesn't care about performance having something trivial become multiple times the cost might be acceptable (people use scripting languages for a reason), but if your time is spent looping through large amounts of data, that extra cost is a problem.

  int a = v[-100]; // yolo a is set to 0

    auto v = std::optional<int>();
    std::cout << *v << std::endl;

    int* v = nullptr;
    std::cout << *v << std::endl;

Perhaps, 3 types could exist for 3 options.

I think if you adopted a more defensive programming style where you check your values before dereferencing them, handle all your error cases, you might find C++ is not so scary. I would also recommend not using auto as it makes the types less clear.

    std::optional<int> v = std::nullopt;
    if (v == std::nullopt) {
        return std::unexpected("Optional is empty.");
    }

    std::println("{}", *v);

    if let Some(value) = some_optional {
    }

  if x.is_some() {
    let x_value = unsafe { x.unwrap_unchecked() };
  }

In Rust, they made the safe way of writing things easy (just write v[x]), and the unsafe one hard (wrap your code in 'unsafe'). C++ is the opposite, it's always more code, and less standard (I don't think I've seen a single C++ tutorial, or book, use .at() as standard rather than []), to do bounds checked.

So, you can write safe code in both, and unsafe code in both, but they clearly have a default they push you towards. While I think C++'s was fine 20 years ago, I feel nowadays languages should push developers to write safer code wherever possible, and while sometimes you need an escape hatch (I've used unsafe in a very hot inner loop in Rust a couple of times), safer defaults are better.

Essentially, the warts are too large and numerous for me to find any inner beauty in it any more.

C++ modules are supposedly meant to save the day. Although only recently have the big three compilers (GCC, Clang, MSVC) reached some form of parity when compiling modules.

I definitely got bit by it multiple times.

>The pimpl idiom: not sure why it's really a problem.

Because it's even more boilerplate and adds indirection in a place where you might have been painstakingly trying to avoid it (where the first indirection costs you all your cache coherency). C++ lets you go out of your way to avoid objects having to carry any overhead for virtual dispatch if you aren't going to use it; but then you might have to choose between rerouting everything through a smart pointer anyway or suffering inordinately long compile times. Nothing to do with type erasure (if I'm thinking clearly, anyway).

You can blame devs instead of tools all day long, but you can't deny that there are things about the tools that hold the developers back.

If you've actually worked at a large company, you'd know that 90% of the real work is done by like 5% of people (maybe even less). If the interviews worked this ratio would be so much better.

I've seen interviews where you actually have to present a thing you've done and then explain the decision making process behind it, tradeoffs, outcomes, etc. those are more common outside of CS and I'd like to see more of that in CS. Or hell, have them write an essay describing the tradeoffs about some theoretical engineering decision. That'll give me actual info on how a person thinks.

For context, I used to work in self driving cars and had to interview many people who claimed to work in that field and claim to have worked on huge projects themselves. Then you dig deeper and it turns out they were part of a huge group, they never heard of this problem, that problem, never heard of this industry standard, etc. it's like, forget coding, this person doesn't even know the domain as much as they claim and not being upfront about that disqualifies you immediately in my books.

No talking (other than me showing them how I fixed it). No bullshit questions like "where do you see yourself in 5 years" or "talk to us about your strengths" etc.

Second best - they asked me to design and write pseudo code for a simple system. Don't worry about syntax, but make sure to follow good design practices, within reason. Gave me a pen and notepad and left me alone for an hour. I wrote it, explained my thought process, they made an offer.

Then I had shitty interviews - one very large, very famous insurance company - they had 5 rounds of interviews back to back, for a normal developer role, lol. Asked me about some obscure options for grep etc. It was an exercise in them showing off their skills (more like their memory of Linux commands) than learning about my skillset. I couldn't wait to get the hell out of that building.

Of course interviews can't be light when you are hiring for highly technical, high critical positions (like security, for example). But for most software dev positions, the formats above are very efficient. Most software devs are writing "glue" code, not rewriting some mission critical real time OS.

Whereas with VSCode, I really never have to leave the VSCode environment to do what I want. I can pop open a shell within VSCode and don't have to switch windows. I can easily open random files not associated with my project and VSCode does the right thing (usually). It opens images easily, renders markdown well, etc. my favorite feature is that you can pipe cli output directly to VSCode in the shell and then it opens a tab displaying that output. You'd be so surprised how often that feature comes in handy.

I really hope you’re wrong about that. I don’t want to be ruled by another Microsoft product

Example from VSCode Terminal: $ echo hello | code -

I think you missed the point of my comment you are replying to. You can get things done in any editor. The point is that Vim/Emacs have been around for decades and last your whole career, VSCode has been around for a fraction of the time and killed off the previous editor, Atom, that everyone though was "the editor".