mikebenfield

That’s really surprising to me to read; surely figuring out a better convention for returning a struct would never have been a challenge, right?

I agree that Myers Briggs is pretty wishy washy, but "You answered these questions in these particular ways, so we can conclude these facts about your personality" is a completely different galaxy from "You were born in this month, so we can conclude these facts about your future."

One major thing I like about having to implement a defined interface is that it forces people creating an API to actually define what that interface is. And in typing out that interface there's a fair chance they'll actually write doc comments.

IME a lot of libraries that do duck-typing (for instance Python) make very little effort to explain what methods I'm supposed to implement or what the contract is supposed to be for those methods.

It also forces users of the API to explicitly state in code that they're intending to implement that interface, as opposed to just implementing a handful of seemingly random methods whose purpose will not be immediately clear to readers.

Also, AFAICT duck typing is incompatible with the approach taken in Rust or Haskell where the definition of a type can be decoupled from its implementation of various interfaces (called traits in Rust or type classes in Haskell), and where methods or attributes in different interfaces implemented for the same type can have the same name and not clash, because the object isn't the namespace for its methods. I strongly prefer this approach.

Yeah, after all, as everyone knows, it's not possible to care about both climate change and mutilating babies.

I'm not a massive fan of duck typing, but it's literally never even occurred to me to worry about the concern addressed in this article (that an object accidentally conforms to an interface and is used as such).

> And everyone agreed so hard that it was removed from almost every modern C replacement

They removed it because they made the regular "if" statement into an expression, so the separate "ternary" operator expression is superfluous. Rust et al made the "if" situation better than C; Go made it worse.

To toss you a bone, it's true that many dense areas in the US don't feel really safe.

But it doesn't have to be like this. It's very possible to build dense living spaces that are nice to live in.

But more to the point, you are free to live in the middle of nowhere if you want to. If you don't want to live in a dense area, the vast majority of residential areas in the US cater directly to you. Personally, I'd like to live in an actual city, and I'd like to pay less than $5000/month for a decent 1 bedroom apartment.

You seem to be pretty confused about the comments you’re reading.

Not just that… “on the first computers.”

The 1990s, age of the first computers.

I didn’t read that as intending to include Einstein in that group.

The fact that the magnitude of positive constant factors is irrelevant doesn’t mean it makes any assumptions about the cost of operations.

> In just another few years, if Rust does not fizzle, you will feel the same way about code in Rust as it evolves and improves.

I've written fairly extensive amounts of code in C, C++, Rust, Python, Java, OCaml, Haskell, Clojure, Common Lisp, Scheme, and probably some others that aren't coming to mind right now. All of these languages except Rust have been around for decades (and I guess Clojure is about a decade and a half). My opinion of these languages vary. They all have their warts. Some of these languages I don't particularly like. Some of them are complicated, some are fairly simple.

But C++ is the only one where I feel like the basic features of the language are actively working against me. It's the only one where I feel like such a huge portion of language design decisions were utterly baffling and wrong.

IME some members of the C++ community can be fairly insular. They just can't see how things are done outside their world. You expect me to believe that I'll eventually feel the same way about Rust as I do about C++, but I know that's unlikely to be true because C++ is the only language that I feel this way about.

I don't follow this, either logically or in practice.

Granted I've never dated as a gay man or as a lesbian, but from what I've observed it seems to me a much smoother and more mutual process than straight dating. I've even heard from bi men about how much easier and less stressful it is to date men than women. AFAICT when both parties are on a level playing field, and there's not a massive asymmetry in power, interest, and investment, there's a lot less grief overall.

> edit: I mean, isn't that Bumble?

Bumble is a valiant attempt to fix this issue but it seems to mostly be a failure. An average man may occasionally get a message (which will usually just say "hi"), but the asymmetry in interest is still there, and it's still mostly men's responsibility to do the real initiating.

1. Since it's an external web site with a little bit of tech behind it that presumably others are using, it might seem less desperate or strange than the post you suggest.

2. The potential crushee can do the check without notifying you they're doing so. They might be too embarrassed/intimidated to actually tell you they're interested in whether you have a crush.

> Those games only make at least a bit of sense when everybody enters their crush and only when matching both get notified.

Even then, among heterosexuals they will suffer from the same problem as basically every software platform for romance among straight people: the massive asymmetry in interest between men and women. Men would copy and paste virtually every woman they know into the system as a "crush," so they can find which if any of their female acquaintances might be interested, and then they would decide who to pursue.

Actually I have been around physicists. In my experience they use “codes” for any amount of code. If A wrote some software, B might say “I’d like to use your codes.”

That reference you give doesn’t appear to be available online but I’ll take your word for it.

Rust is indeed changing pretty fast. But it's new. And most of the design decisions work well together. The language as of 2015-2016 was a reasonable language, and the changes since then have very rarely been of the form "This earlier design was a mistake, and we need to fix it all."

But C++, even in its pre-template 1980s form, was already full of wrong decisions (granted, many of those decisions were done for compatibility with C).

Including headers is the wrong way to share code. C-style macros are a bad idea. The whole copy constructor idea instead of move semantics, and then an explicit clone function when you need that, was the wrong idea. The complex mess of various constructor types. The friend mechanism to control access is complicated and unnecessary - why not just a simple module system? The complicated inheritance system - virtual, public, protected, private inheritance - what is this goop? The implicit conversions between integer types has caused countless problems. The language is extraordinarily hard to parse.

All of these things (and plenty more) I feel perfectly comfortable saying are just outright bad.

In Rust, all the basic language stuff... the module system, the traits, trait objects, the mechanism for defining new types as enums or structs, even the borrow checker... it's all fine, and it works well together. It's definitely not perfect, I have my gripes. But when I write C++ I can never forget for one second that it's a conglomeration of baffling design decisions and one attempt after another to patch over prior mistakes. I never feel anything like that with Rust.

> If your language or your code of five years ago does not embarrass you today

I mean I get where you're coming from with this, but I would say if an entire community that's been around for 40 years can look back every 5 years and always say "the way we were doing things 5 years ago was completely wrong," that's a serious problem.

> C++20 is not the same language as C++11, which was not the same language as C++03

This is not a good thing. In fact, it's a shockingly bad thing. C++ is basically 40 years old, and still every few years the C++ community feels like, "OK, now we know how to get C++ right; yeah the old C++ was a mess, but now we just need to add these 12 new features and it'll all be good."

Unfortunately many of the problems with C++ are due to mistakes in its early design. It was wrong from the beginning.

I've been programming Rust for 6 years. C++ for over 20. I'll take Rust every day of the week and twice on Sunday.

It is true. I’m not basing my statements off random info I gleaned from the internet.

This is not accurate.

Pretty damn mainstream nowadays, yes. Quite a few big tech companies are either actively doing much of their new systems programming in Rust, or else dipping their toes in.

I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely - they are _all_ looking for alternatives, and Rust is the most obvious option.

To me C++ is much, _much_ harder than Rust.

Maybe in C++ it's easier to get a program to compile, but it's dramatically harder to make sure you've checked all the boxes you're supposed to check to make sure your code is safe and complies with best practices.

For instance, consider the rules of 5 [1]. There are so many rules like this in C++, so much complicated stuff you're supposed to know to write anything at all, and much of this is just _accidental_ complexity: it's just there for historical reasons or language design reasons that in retrospect don't make much sense.

[1]: https://stackoverflow.com/questions/65455464/is-the-rule-of-...

Sure, there's no absolute right or wrong on terminology, but it is a sign that they're cut off from the software engineering world, which leads to a whole host of dumb practices, described elsewhere in the comments here.

As someone with a mathematics background, whenever I encounter someone in another community using mathematics (like economics or accounting or finance or whatever) using mathematical terminology that seems silly to me, it's a bad sign.

That article appears to be written by a non-native English speaker. I don't think I've ever heard anyone refer to a software package as "a code."

I have an academic mathematics background and I'm perfectly OK with this.

Python can be simple, to the degree it is simple, because it makes so many of your decisions for you.

In Rust the design space is very large. For instance, if your new type is going to refer to some data, should it own the data, should the data be on the heap (in a box), should it carry a safe reference (if so, mutable or not?), should the data be reference counted, or possibly atomic reference counted, or maybe for some reason you need to keep an unsafe raw pointer to the data?

In Python this is simple because the decision is already made for you: your new type keeps (essentially) a reference counted ref to the data it needs. That’s it. That’s all you can do.

That’s great if that decision is always adequate for your application. If you need extra flexibility you’ve got a problem.

Getting a PhD (ie, passing an apprenticeship in how to do research in an academic setting) is a lot more strongly related to being a RSE than playing golf is to running a business.

> They call it "codes"

This is not really the core issue here, but yes, I've encountered this many times, and I have to admit that in some professional contexts I use "codes" as a shibboleth to identify people who aren't really in touch with the software engineering world.

What I'm suggesting is that "Important software has been written by people who couldn't/didn't do X" is not a very strong indication that X is not a valuable quality that employers should want in their engineers.

No. There are many places where it’s perfectly viable and pleasant to do without a car, through some combination of walking, biking, and public transport. Granted, most of those places are outside the US, but even in the US there are a few decent spots, I’ve lived in them.

Not every location adopts the approach of building a car dependent hellscape, and then using the very car dependence they have created as justification to continue the car dependent approach.