[mikekchar]

I haven't written C++ code since the 90's, but I enjoyed writing code that way. I've also written Java code and C# code (in the late 90's and early 2000's). I enjoyed C++ at least as well as those. Some things are better, some things are worse. I've been doing some Rust lately and probably I would reach for that before I would reach for C++. There's a lot I don't like about Rust. I think it would be great if someone designed a language in about 5 years from now that contains all the things learned about Rust, but was designed from the beginning to solve the problems elegantly. Still, it's a fun language to use.

For me modern C++ is interesting, but it has even more of the problems that Rust has. There are lots of good ideas that help fix problems we've seen over the last 40 years or so (man, I'm old...), but I think unless you are already a C++ programmer it's probably more convenient to start with a language that was designed from the beginning to solve those problems. If someone paid me, I'd very happily write C++ code again, though.

[steveklabnik]

Out of curiosity, what do you find inelegant with Rust?

[mikekchar]

Edit: Was surprised to see someone down vote the parent. Perhaps not realising that Steve Klabnic might legitimately be interested in how Rust can be improved ;-)

Ha ha! Before I answer, I should say how much I appreciate the work you do. It really is awesome.

I've been a bit clumsy with my words, though. It's not so much that I know there is a more elegant way to do it as much as I'm left with that feeling. For example the ? operator. It's incredibly useful and makes the code much less clumsy. But I'm left thinking, "Why do I need this"?

I've got a list of actions, some of which could fail and some of which can not fail. I want to exit early if something fails. Is there another way I could represent this? For example, something like a "do" notation. Then each statement essentially needs to be a monad. I'm not necessarily keen on that, but I think we're missing an abstraction somewhere. The set of functions that all return the same type, describe a monad... Why am I mixing functions with different return types, I wonder...

The thing is, I've got this extra notation that I have to learn about that does something useful. It just appears to me that I wouldn't need that extra notation if I could abstract the execution differently. Maybe that's a pipe dream, but it gnaws at me :-) And, of course, if we had it, the result wouldn't be Rust -- you'd need a completely different language to support that way of looking at it. Just to get rid of ?. Yeah, not worth it for Rust, but I think still worth thinking about.

Sorry for the rambling nature of this post :-) Just to leave you with a more concrete example that's not about Rust. I actually like many things about Javascript. One of the things I found really elegant about JS is that there are no private or public variables. If you want something to be private, you just make a closure. There is no need for a "private" keyword or a "public" keyword. There is no need to build in special code in the interpreter. It just works because that's the way it works.

Another thing I found really elegant about JS (though, unfortunately not executed as far as they might have) is the way classes are represented. You write a function that returns a dictionary/struct. That's a constructor. But it's also pretty much everything you need in a class. A class is just a function. Although it's a bit bizarre, functions are also dictionary/structs, so if you need class functions, just add it to the function. I'm not so keen on how they implemented prototypical inheritance, but it was the 90's so I'll cut them some slack ;-)

So when I say "elegant", what I mean is that the form of the language dictates its function. With Rust, I find that we have quite a lot of stuff like the ? operator. It's super useful and leads to better code, but it's also kind of tacked on. If I were going to design a language that had similar utility, but didn't need the operator, what would it look like? Maybe there is no more elegant solution. However I kind of think that with another 5 or 10 years of work with Rust people will start seeing the kinds of workflow that Rust engenders and will probably discover abstractions that fits that workflow better -- much in the same way that Rust has done with C++.

[steveklabnik]

> Was surprised to see someone down vote the parent.

It happens, it's just the internet. I have enough karma, haha.

> Before I answer, I should say how much I appreciate the work you do. It really is awesome.

Thanks! It's cool, I was just legitimately wondering. As you said sorta, it's helpful for me to understand people's perspective. If you'd like, I can give you some explanations here, but I wasn't asking to try and correct you, I was interested in your perspective. Thanks for sharing it :)