271–280 of 387 posts
Earlier quoted context omitted.
> the inability of IDEs to deterministically parse templates / index code without huge problems is problematic. More like the inability of text editors to parse templates; most IDEs rely on a full compiler backend that can usually figure things out.
Not in my experience. IntelliJ can't even figure out where a make_shared call goes.
Earlier quoted context omitted.
What is profoundly pissing me off are bunch of hipsters on the internet that are using xyz language and are constantly trying to compare everything to C. We are faster, we are better, we are more portable, we have JIT, we have reflection... and so on. Who cares what your tool for solving the problem is. Use Java, use JS, use python, go, rust... whatever suits for the task. Why do you want to compare yourself to C. Ju…
The "right tool for the job" is a myth (EDIT: exaggerating; clearly it applies in some cases). Languages don't work together very well, so you need huge, thick boundaries between them, such as serialization/deserialization. Data types don't match up, GCs require special data formats and don't line up with the GCs of other languages, other runtime weirdness, etc. At minimum, you need lots of copying/transformation of…
But if you want to be able to optimize both globally and locally, well that's just an engineering problem!
Two examples spring to mind:
1. Lisp. Lisp's metaprogramming facilities allow you to build the language into the specialized tools that you need, while still having the common runtime and base language.
2. Unix. There a hundreds (possibly even thousands) of little programs running on my Linux machine written in probably dozens of languages. For the most part, I have no idea (nor do I care) what language they are written in. That's because the Unix model puts a strong emphasis on the protocols for communicating between programs.
Earlier quoted context omitted.
> the inability of IDEs to deterministically parse templates / index code without huge problems is problematic. More like the inability of text editors to parse templates; most IDEs rely on a full compiler backend that can usually figure things out.
But it shouldn't require a full compilation. The ultimate result, given the slow compile times of c++, is that you cannot know in your editor if your code is correct.
Earlier quoted context omitted.
>inability to read uninitialized memory printf("%x", *(int*)0x12345678);
Even casting 0x12345678 to int* is undefined behavior
Earlier quoted context omitted.
Probably the closest you'll find today is LLVM IR (or maybe there's a slightly closer IR in some other compiler). In terms of languages you'd actually like to program yourself, Rust and C++ are slightly closer, but that's mostly a factor of trying to incorporate more hardware features rather than modelling hardware better.
Does anyone code directly in LLVM IR? I've had the thought of toying with it as a better portable assembly with a crazy optimizer behind it...but since the LLVM folk want it to be an implementation detail they warn against it due to how volatile it is across versions. I'd be really interested to hear experiences of people who have done it though, even as a toy.
Earlier quoted context omitted.
> most other answers will raise an eyebrow from me Portability. A C library can be trivially linked with any other language. But one will be hard pressed using a python library form Ruby, for example.
Indeed. C++ is relatively portable too (or at the very least, can be made to hide behind a C ABI in many cases) and it seems like Rust is as well. Whereas, if you have a library written in python that you want to leverage, you're forced to include a python interpreter. This sucks.
Earlier quoted context omitted.
We are not oblivious. First of all, we are not really trying "to replace C." Second, a tremendous amount of work has been put into specifying Rust. It's just also a tremendous amount of work. Like, "the EU has given grants of millions of Euro towards working on it but we're still not done" amounts of effort. C did not have a standard for 18 years, it was first created in 1972, and ANSI C didn't appear until the sprin…
Go has a spec, which has been used to make gccgo. I'm not very familiar with other specs: is it fair to say that the Go spec is less detailed and so was able to be completed before 1.0? Is it "not a real spec" compared to ANSI C, ECMA, etc.?
However, you do also bring up something that's a good point when it comes to this discussion: a lot of people treat "a spec" as a binary thing: a language has it, or does not have it. But specs are written by humans, and have their own mistakes, bugs, errata, etc.
One of the reasons that we haven't wanted to declare "this is the spec for Rust" is that we want to have a good, possibly even formally verifiable spec. The reference is basically at a fairly reasonable informal spec level.
Earlier quoted context omitted.
Using a union still has the going-through-memory problem, though. I spent a day or two trying to coax clang into doing the efficient thing with a union a couple years back when I could have gotten the job done in 30 minutes with raw assembly (alas...) RE: Return values, you'd be surprised. You can't assume you'll get properly optimized code for something like that in WebAssembly for example, despite the fact that you…
> Using a union still has the going-through-memory problem, though. Not with modern compilers: https://godbolt.org/z/e6sRqh
Earlier quoted context omitted.
> Using a union still has the going-through-memory problem, though. Not with modern compilers: https://godbolt.org/z/e6sRqh
That's a compile-time constant, effectively. What matters is real code.
Earlier quoted context omitted.
Probably the closest you'll find today is LLVM IR (or maybe there's a slightly closer IR in some other compiler). In terms of languages you'd actually like to program yourself, Rust and C++ are slightly closer, but that's mostly a factor of trying to incorporate more hardware features rather than modelling hardware better.
Does anyone code directly in LLVM IR? I've had the thought of toying with it as a better portable assembly with a crazy optimizer behind it...but since the LLVM folk want it to be an implementation detail they warn against it due to how volatile it is across versions. I'd be really interested to hear experiences of people who have done it though, even as a toy.
There is a small, very restrictive class of LLVM IR that is going to be effectively stable, and even portable. Stripping debug information goes a long way to making your IR readable by newer versions of LLVM, and staying away from C ABI compatibility (especially structs) can make your code somewhat portable.