Reasonable and educated people in the US should be more critical of their own government which wages wars all around the world. China isn't a saint either but let's be real.
This seems like a non sequitur, although I do agree that more people should be more critical or at least cautious to support actions by the US abroad. The parent comment didn’t compare the US and China (foreign policy or otherwise). For instance, there was no discussion of any US big tech involvement in China.
They did, however, compare Sweden and China, both with respect to the US.
The main reason why girls are not choosing STEM is because it doesn't intrest them as much. You can try to put the blame on anything you want, but that's reality.
I love technical things and am the father of 1 son and 3 girls. I of course would love to do technical things with all of them. With my son it's easy to get him excited about lego and such. With my girls? Well, maybe you should give it a try. I decided to play with my kids the things they like to play with. And with my girls it's (unfortunately for me) non technical things.
This preference is also highly documented in gender equal societies. So do us all a favor and stop talking bullshit while it's obvious why women don't select STEM: they don't want to.
PS: My oldest daughter is going to follow STEM next year. I'm happy, but mainly wish her to be happy. If she continues it, fine. If she decides she wants to do something else, also fine. She's good at math so that's the main reason she picked it.
Gender imbalance on it's own doesn't say everything. You should actually talk with women in STEM. Many of them shared their horrible experiences so far.
I agree we should work to reduce horrible experiences.
My point is that we shouldn't be surprised by a gender imbalance on priors. By itself, a gender imbalance only goes to show that software engineering is like a lot of other jobs.
BTW, my suspicion is that similar experiences happen in many industries, and industries vary according to (a) how horrible a given experience is said to be and (b) social norms around registering a complaint.
Marx never specified how “country-wide implementation” should look like, Marxism-Leninism was the most common one. Escaping capitalism in today's world is impossible because the moment you decide to work on different economic model and distance yourself from IMF you'll sign your death sentence. Big players will never allow that.
Python is generally considered quite strongly typed, though dynamic. That is because Python has relatively few implicit conversions, and especially few that are surprising ("1" + 1 is an error, not 2 or "11"; and unsigned short + unsigned short does not equal a signed int).
You don't do manual memory management in Rust either. AFAIK (correct me if I'm wrong), even in C++ manual memory management is discouraged in favor of RAII.
You surely do, first of all the borrow checker is only a compiler validation that you are writing the manual code correctly, and no one is magically writing Drop traits implementations for the user.
Likewise on the C++ side, someone has to write those constructor/destructor pairs, and there are ways to get RAII wrong.
Yes, you have to think about ownership. Because of single owner. But in general, not alloc/free. I work in Rust (after doing C++ for the 10ish years prior) full time and a couple nights ago was honestly the first time I had to really think about this (I had to do a 'forget' because I was passing a ptr to a vector back through from WebAssembly to our Rust-based runtime, and then clean it up back there instead of having Rust let it fall out of scope and free when the stack frame exited).
Think of Rust as a world where pretty much everything is inside a std::unique_ptr.
Most developers used to a GC language will have little problem working in Rust once they understand the single ownership model.
Yes, GUI work is a pain because of the way event loops and ownership in existing UI toolkits work, they're generally not designed for this. But Arc<Mutex< is likely your friend here.
Async can be a pain, but you learn the ways. I work in a codebase with quite a bit of it.
There are appropriate and inappropriate places to apply Rust.
> no one is magically writing Drop traits implementations for the user.
Yes, the compiler is - for almost all structs. I've been working with Rust since around 1.0 and I can count the number of times I manually had to write Drop implementations with my hands. Unless you are writing lower-level parts of the stack (which you rarely need to, since for many of those there are good crates already available) where you are responsible for resources that need a custom Drop implementation, the auto Drop implementation is good enough.
> Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages.
There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a serious work.
How can you know if you don't have a verified formal description of your language's semantics?
It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting.
Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define" whatever one likes.
> Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN.
Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"
James Clear talks about this in his book Atomic Habits. Basically people are happier during the _process_ of trying to accomplish some goal than when they actually accomplish that goal.
