3 ms·

> This list, together with already mainstream features, turns a programmer’s learning curve into an uncompromising cliff. This is because many insist on having

> This list, together with already mainstream features, turns a programmer’s learning curve into an uncompromising cliff. This is because many insist on having one giant programming language to do everything both low-level and high-level together. Rust just follows C++ along this same path. The resultant language will always be a complex compromise that is suboptimal for almost everything. For example, both Rust and C++ have too many high-level abstractions to easily reason about where allocations will happen and their manual memory management makes lambdas and async painful. I personally would favour the use of multiple languages. Such an approach is commonly emerging anyway due to practicalities, e.g. Python/C/Fortran use in machine learning.

einpoklum 5y ago
> a complex compromise that is suboptimal for almost everything Whenever you have a programming language with multiple goals (or, let's say, more than two distinct goals) - it's almost certainly going to be suboptimal for any individual one of them. The questions are: * Whether choice of goals is worthy/reasonable; and * Whether a good balance and compromise has been struck by that language's specifiers and implementers. Also remember that languages evolve; and if one of the language goals is backwards compatibility (which is the case for C++, less so for Rust) - then part of the compromise is that they have to support multiple older and less-recommended idioms and facilities while offering newer, hopefully better ones.
- grumpyprole 5y ago
  I hope it was clear from my earlier post that I am arguing "No" for your questions above, especially regarding C++ and Rust. This doesn't necessarily mean I don't think great software cannot be built with these languages, but rather I do not see them as the future.
ncmncm 5y ago
> [because languages] do everything both low-level and high-level together This is very far from true. Like, not even the tiniest bit true. It is easy to program in C++ or Rust and pay no attention at all to where allocations happen. Almost all application-level coding in those languages is written exactly that way. Even in programs where such attention is needed, the overwhelming bulk of the program, such as all the initialization and setup code, gets away with completely ignoring allocation. Certain libraries whose value proposition includes having been heavily optimized need to pay attention to memory placement, but probably more than half of libraries would only ever be used in places where performance doesn't matter at all, and the author knew it. Anyplace where you do need to pay attention to details of allocation, or of atomic event ordering, or of interrupt context, you are not obliged to use every last bit of abstraction your language enables. It is totally allowed to drop to a C level of specification. (In Rust you might even put some of it in "unsafe" blocks.) Rust and C++ do impose inconveniences for various reasons -- C++ mainly because of backward compatibility, Rust mainly for extra static enforcement -- but the inconveniences are completely unrelated to the occasional need to pay attention to memory placement. Where existing languages do still demand low-level attention is in obliging the programmer to be aware of control flow, and what thread is executing which bit of code. They are only starting to loosen that. It used to be that you didn't care because there was only one thread. Then, we made threads, but not too many, because of numerous costs. Now, we would mostly like our programs to use as many threads, scheduled any which way, as would be useful.
- nine_k 5y ago
  I'd say that to appease the borrow checker is to care about allocation and especially deallocation.
  - ncmncm 5y ago
    Allocation and deallocation are divorced from borrow checking.
    - verdagon 5y ago
      One could say that the point of a borrow checker is to guarantee that you don't deallocate an object until all references to it are gone (for some definitions of deallocate and object).
      - andrewflnr 5y ago
        In my experience the annoying clashes with the borrow checker are more to do with mutability than de-allocation. It's not that the reference lasts longer than the allocation, it just overlaps other borrows you want to make.
        ncmncm 5y ago
        Right. At any point that an object could possibly be deallocated, everybody who wanted to look at it has, perforce, already lost interest. The system knows at what point this is, and can quietly dismantle the object and free its storage without bothering the programmer.
- grumpyprole 5y ago
  This statement: >> do everything both low-level and high-level together > This is very far from true. Like, not even the tiniest bit true Does not really align with: > It is easy to program in C++ or Rust and pay no attention at all to where allocations happen (This is what high-level languages offer) > It is totally allowed to drop to a C level of specification. (This is what I mean by low-level) I would also argue that in Rust the memory management unfortunately does affect the ergonomics of lambda and async, for example the need to explicitly pin memory. I really don't mean to criticize all the recent effort that has gone into Rust, it is certainly a huge improvement over C++. But it's far from perfect and I'm arguing that is probably not the fault of any of the individual choices, but rather the language goals. I would like to see a future where we use more specialised languages; rather than the many languages that can both peek/poke bytes and implement the full lambda calculus. More specialised, simpler, languages are much more amenable to static analysis and formal methods.

einpoklum 5y ago

> a complex compromise that is suboptimal for almost everything Whenever you have a programming language with multiple goals (or, let's say, more than two distinct goals) - it's almost certainly going to be suboptimal for any individual one of them. The questions are: * Whether choice of goals is worthy/reasonable; and * Whether a good balance and compromise has been struck by that language's specifiers and implementers. Also remember that languages evolve; and if one of the language goals is backwards compatibility (which is the case for C++, less so for Rust) - then part of the compromise is that they have to support multiple older and less-recommended idioms and facilities while offering newer, hopefully better ones.

grumpyprole 5y ago
I hope it was clear from my earlier post that I am arguing "No" for your questions above, especially regarding C++ and Rust. This doesn't necessarily mean I don't think great software cannot be built with these languages, but rather I do not see them as the future.

ncmncm 5y ago

> [because languages] do everything both low-level and high-level together This is very far from true. Like, not even the tiniest bit true. It is easy to program in C++ or Rust and pay no attention at all to where allocations happen. Almost all application-level coding in those languages is written exactly that way. Even in programs where such attention is needed, the overwhelming bulk of the program, such as all the initialization and setup code, gets away with completely ignoring allocation. Certain libraries whose value proposition includes having been heavily optimized need to pay attention to memory placement, but probably more than half of libraries would only ever be used in places where performance doesn't matter at all, and the author knew it. Anyplace where you do need to pay attention to details of allocation, or of atomic event ordering, or of interrupt context, you are not obliged to use every last bit of abstraction your language enables. It is totally allowed to drop to a C level of specification. (In Rust you might even put some of it in "unsafe" blocks.) Rust and C++ do impose inconveniences for various reasons -- C++ mainly because of backward compatibility, Rust mainly for extra static enforcement -- but the inconveniences are completely unrelated to the occasional need to pay attention to memory placement. Where existing languages do still demand low-level attention is in obliging the programmer to be aware of control flow, and what thread is executing which bit of code. They are only starting to loosen that. It used to be that you didn't care because there was only one thread. Then, we made threads, but not too many, because of numerous costs. Now, we would mostly like our programs to use as many threads, scheduled any which way, as would be useful.

nine_k 5y ago
I'd say that to appease the borrow checker is to care about allocation and especially deallocation.
- ncmncm 5y ago
  Allocation and deallocation are divorced from borrow checking.
  - verdagon 5y ago
    One could say that the point of a borrow checker is to guarantee that you don't deallocate an object until all references to it are gone (for some definitions of deallocate and object).
    - andrewflnr 5y ago
      In my experience the annoying clashes with the borrow checker are more to do with mutability than de-allocation. It's not that the reference lasts longer than the allocation, it just overlaps other borrows you want to make.
      - ncmncm 5y ago
        Right. At any point that an object could possibly be deallocated, everybody who wanted to look at it has, perforce, already lost interest. The system knows at what point this is, and can quietly dismantle the object and free its storage without bothering the programmer.
grumpyprole 5y ago
This statement: >> do everything both low-level and high-level together > This is very far from true. Like, not even the tiniest bit true Does not really align with: > It is easy to program in C++ or Rust and pay no attention at all to where allocations happen (This is what high-level languages offer) > It is totally allowed to drop to a C level of specification. (This is what I mean by low-level) I would also argue that in Rust the memory management unfortunately does affect the ergonomics of lambda and async, for example the need to explicitly pin memory. I really don't mean to criticize all the recent effort that has gone into Rust, it is certainly a huge improvement over C++. But it's far from perfect and I'm arguing that is probably not the fault of any of the individual choices, but rather the language goals. I would like to see a future where we use more specialised languages; rather than the many languages that can both peek/poke bytes and implement the full lambda calculus. More specialised, simpler, languages are much more amenable to static analysis and formal methods.