cristeigabriel

I did not make a statement on reading, but on social perception where I'm from. Reading is nice, I have many thick books myself and I love(d) them, and it's a sustainable hobby in my perspective of social relations because the majority of people here tend to have a negative experience with reading, not being a thing of their own volition, but a requirement, especially on content they don't even care about. Therefore, if, say, you're a child, and your parents see you reading, they're less likely to throw a fit than if you were playing Counter Strike or something.

> Why do hold books on a pedestal?

Maybe my opinion on this is negative due to my Eastern European upbringing, but I would say it's because it's something often seen as painful (think of a thick book with a dense vocabulary, being more scary rather than appealing to the majority of people), and, people are OK with wasting time if it involves pain, it gives the impression of a more honest attempt to achieve something, and books are the go-to for the majority of people who judge whether somebody is being productive or not.

> I'm thinking battery life and heat.

The problem is, I'm not sure how it'd help, when you have to do emulation. It often requires explicit hardware support (or some system level support) to break ABI to not manually do mappings and stuff, to make emulation as little overhead as possible. Make sure you caught that, "as little overhead as possible", I am not good at hardware whatsoever but to me there's no reason that an alternative chip would be any better than the original chip being emulated, when you have the same ISA being ran....... UNLESS there is some recompilation. This is why I'm a fan of JITs and their little VMs, you can do your own JIT compiler for VMs and implement your own optimizations, the same way you'd, say, implement fast-paths in a JS JIT compiler.

Thanks for correcting me!

> I'm waiting for a ARM Steam Deck that has something like Rosetta built in.

This would solve nothing, besides maybe a better chip design, but you're bringing back the same ISA, and you'd have to bend over backwards with your new fancy architecture to painstakingly truly support old software.

> Windows has a compatibility layer for x64 applications on ARM

It's the WoW layer, there's also Arm64X and I think a x86 mode (see Arm64EC documentation?).

> Teams: Electron.

Not as simple with Preview versions on Windows. I don't think they use Electron whatsoever anymore, and old versions weren't fully Electron either (I remember seeing Chakra [their old JS engine] in the stacktraces, doing some elementary logic), I think it's XAML with UWP + WebView2.

> Resources Available

> Also, the quantity of teaching material and resources available to learn the language is currently overwhelmingly more abundant on the C++ side.

Quality over quantity. I'm a predominantly C and C++ developer, and the generic resources for C and especially C++ are horrible for the better part. This changes though when you look at what actual experts are putting out, either by themselves or by presenting at some convention, etc..., but these resources take knowing where to look, and many of them are useless in the process of learning the essentials, which everybody will screw up, because the language doesn't guide you, unlike Rust, which nannies you a lot (thankfully!!! you understand if you've written enough C++.)

> So if I want to bet safe in the development of a new system, I have to go with C++.

despite what I said above, C++ is prone to getting you in very unique scenarios if you're actually doing a new system (my anecdote), so you can't rely on people who aren't already skillful to even figure out that there's issues, even less how to address them. There's no guidance, really (unless you use C++Insights and hack stuff to compile-time.)

> In many years of coding C++, very rarely I experienced a stack overflow or segmentation fault. It is literally not an issue in every codebase I have worked with.

You espouse a pop understanding of software issues. These issues are not just magic, they happen for very exact reasons, this is why we can work against them happening in the first place.

I end my comment with saying that I'm not even a big fan of Rust, it's very specifically designed, I do not like the principles that Rust builds on, but I still disagree with your analysis.

Paywall

You don't have to do this, here's an alternative approach:

template<std::size_t N> struct fstr: public std::array<char, N + 1> { using std::array<char, N + 1>::array;

    constexpr fstr(const char* str) noexcept : std::array<char, N + 1>() {
        for (size_t i = 0; i < N; i++) (*this)[i] = str[i];
    }

};

template<std::size_t N> fstr(const char (&)[N]) noexcept -> fstr<N - 1>;

template <fstr sz> struct log { log() { std::cout << std::string_view{ sz.data(), sz.size() } << std::endl; } };

int main() { log<"Hello, world!"> _; }

You can do this (if you want to be evil!)

struct fstr { constexpr fstr(const char* s) { for (length = 0; s[length] ; length++) data[length] = s[length]; }

    char data[256] = {0};
    size_t length = 0;

};

template <fstr sz> struct log { log() { std::cout << std::string_view{ sz.data, sz.length } << std::endl; } };

int main() { log<fstr(std::source_location::current().file_name())> _; }

it would be really interesting to sabotage these

The first thing I did is to check if the easyclick functionality uses UIA. It does. I am very satisfied. For those interested, Windows Kits comes with a tool called INSPECT.EXE, which allows you to interrogate UIs. Very cool!