Rust???The language which is more complicated than C++??? I have learned Rust almostly, but it is too enormous to replaced the C/C++. If rust can't simplify its concepts and syntax, this language will turn to failure again like D...
Rust is not more complicated than C++; you actually have to be thinking about the concepts (ownership and lifetimes) in C++ too, there's just no compiler help, so it seems like you don't.
(Well, you get some help: the compiler inserts (arbitrarily expensive) copies of your data for you.)
The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars".
I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.
> The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars".
> I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.
Many of those real projects can't use anything easier than Rust. Sure, using a GC for everything is easier, allowing memory safety violations is easier, and allowing data races is easier (for some definition of "easy"). But for many projects, like browser engines, kernels, games, etc. neither of these are an option. In other words, avoiding new concepts comes at a price. The concepts in Rust aren't there for no reason; they're there because they're solving real problems.
(Incidentally, I don't think that "simpler" is the right term; I think there's a lot of confusion between "simple" and "easy".)
In my experience most people won't even learn the ins and outs of the "for those who can't" languages. Worst yet, it's not about the language: most people won't grasp more important concepts that maybe "for those who can" languages force them to know upfront. And clearly while not knowing upfront some things is easier in the short term, it is a recipe for disaster as problems get more complex. So maybe it's about problems "for those who can" and "for those who can't".
People can write bad code in any language. I don't know that "forcing" people to know about it will do anything other than force people to make a possibly bad decision... such as simply marking all values as mutable.
The nice thing about go is that there's just a lot less to know. You can learn everything in a weekend. There just aren't many dark corners in the language.
And the problem with "languages for those who can't" is the rise in off-shoring and erosion of working conditions for everyone involved, in both sides.
Not targeting any specific language, as I imagine all of us that went through this, have own hard earned war scars.
Suggesting that offshoring is a result of languages that are "too easy" is both insulting to those who work offshore, and totally inaccurate.
There's plenty of off-shore C++ programmers, and I doubt anyone would say that's an easy language.
And yes, offshored work is almost always of poor quality, but I actually think this is due to the inherent problem with paying people to write a product that they are not fully invested in. The same thing happens with contract work done in your own country. If the developers don't work for your company, they don't have your culture and they don't know your business. This is compounded by the communication inefficiencies from being outside your trusted mediums.
I have seen pay-for-code (contracting, offshore or not) fail many times. The only times I have seen it succeed is when the contractors are hired to work for the company directly, are taken inside its boundaries, and given full access to the company communication facilities and culture. But then, they may as well be regular employees.
None of this has anything to do with the language being used. As they say, you can write bad code in any language, and even the best code doesn't help if it's not doing the right thing.
