you wrong
You can simply use modules with includes.
If you will #include vector inside your purview then you will just get a copy of the vector in each translation unit. Not good, but works. On the other hand. If you include a vector inside the global module fragment, then the number of definitions will be actually 1, even if you include it twice in different modules.
Well, the standard says you can, but it doesn't actually work in practice in msvc, which is the only compiler that's supported modules for over a year.
sure, but don't forget that rust gives us also a nice tooling, functional syntax sugar like pattern matching, enums, monads; and other more or less useful things like explicit lifetimes
Of course.
This is kind of to be expected as it has the benefit of hindsight of 25+ years. It is infinitely easier to design better things with all the accumulated experience and know-how of what works and what doesn't under your belt. It would have been truly horrifying if that had not been the case.
That being said, Rust is really about lifetimes. That's the big ticket selling point. My point above was that 1) it isn't a silver bullet and 2) it can be a real hindrance is many applications.
I often hear about a lot of advantages of D. So I don't understand why it is so unpopular.
Probably I need to give it a chance, but I'm unsure that I will find a real job with the D stack.
Most languages that have made it big have been the primary language for a platform that made it big, and it is really the features of the platform more than those of the language that have driven that.
> Most languages that have made it big have been the primary language for a platform that made it big,
I think you're going to want to define "made it big" and then make yourself some lists as this to me sounds like it doesn't have much explanatory power.
D is fine. Like many languages that postdate C++ and Java, it made better choices, learning from the past. But it doesn't really have a differentiator.
Knowing D will make you a better programmer in other languages. For example, D pushes you to write better encapsulated modules, which is a transferable skill.
Can't include _any_ header downstream if you import std, it is also unknown how you're gonna export and share modules across dependencies you have no indention of 'porting' to modules...
That's kind of the point of C++'s retro-compatibility: C++20 contains new additions to the C++11 standard. Unless you rely in mistakes in the standard like auto_ptr or faulty atomics, which should be fixed regardless of the C++ standard, your C++11 dependencies are perfectly valid C++20 and do not block the new shiny toys.
there are really a lot of simpler solutions than switching the standard of the whole codebase.
E.g. write wrapper which interface doesn't require a new standard.
You have it backwards. Everyone wants a new standard but no one wants to fix the code to make it work with a new way. They would rather introduce a whole new thing.
We want new stuff, but in order to do that we must break old stuff. Like breaking old habits, except this one will never die.
we spent a billion dollars to rewrite our code breaking everything. 15 years latter and we have a better product than the old stuff- but 15 years ago was pre c++11, and rust didn't exist. i cannot honestly ask for another billion dollars to repeat that again and we are stuck. We must keep the old code running and if your new thing isn't compatible with whatever we did back then you are off the table.
c++26 still builds and runs that c++98 and so we can use it. Rust is nice but it can't interoperate as well in many ways and so it gets little use. you can call that bad desingn - I might even agree - but we are stuck.
This. This is why C++ is stuck. The effort required to rewrite old shit code (that works, does its job, makes money) is just too valuable to the company so it sits. All vendors must conform or else be shown the door. No innovation can take place so long as Clu has its claws in our company.
I empathize. This is where rust could really help but there’s a lot of hate around “new” so it sits. The C++2042 standard will still have to be able to solve for C++98. The language will die. A pointer is a pointer and it shouldn’t need weak_ptr, shared_ptr, unique_ptr etc. If you expose it, it’s shared. If you don’t, then it could be unique but let the compiler decide. The issue with all these additions is they are opt in for a community that would rather opt out since it means learning/rewriting/refactoring.
I’ve come across this so many times in my career. Thank goodness for AI and LLMs that can quickly decompose these hairball code bases (just don’t ask it to add to it).
I love C/C++ but it’s so old at this point that no sane person should ever start with that.
If that is what you take from it, you missed the point entirely.
I could care less about shared_ptr.
The issue is why should I care? Why is it on the dev to determine how a pointer should work? Why the dev has to go back and refactor old code to be new again? Why can’t the committee build non-breaking changes to the spec? I would rather have compile flags that make a pointer an “old pointer style” vs having to mentally juggle which ptr container to use, when, and why.
This is just one example. Gang of 3, becomes gang of 5, becomes mob of state…
It’s just a giant mess.
that youieven think a compile flag could switch everything shows how little you understand the problem. it is fine not to understand - it isn't possible to understand everything - but stop talking as if there is an easy problem that would work.
more generally - it is worth it to pay for a good developer experience. It's not exactly about the CPU. As you compared build times - it is worth it to make a build faster. And, happily, often you don't need new CPU for this.
> Suppose you have a FILE file and you want to get it’s contents. Ideally, you’d be able to type file. and see a list of every function that is primarily concerned with files. From there you could pick read and get on with your day.
> Instead, you must know that functions releated to FILE tend to start with f, and when you type f the best your editor can do is show you all functions ever written that start with an f
Why do you think that this is a problem of C? no one is stopping your tools from searching `fclose` by first parameter type when you wrote `file.`. Moreover, I know that CLion already do this.
Looking at service logs at my company show a serious amount of hacking attempts by bots originating from Russian and Chinese IP addresses. Mostly harmless on an updated server not running an ancient Wordpress but attempts nonetheless.
For companies that don't serve customers there it's very common to just block those network ranges. Of course, it's no real solution, but some people are convinced every security layer contributes to 'defense in depth'.
It's not specifically Ukraine related, (spam) botnet harvesting is a much older practice. It was already a problem at my first job at the beginning of the century...
