5 ms·
It actually makes sense to me. Compile-time programming is a very powerful feature of C++ that does not have an equivalent in other systems languages. It is co
by jandrewrogers 7y ago
It actually makes sense to me.
Compile-time programming is a very powerful feature of C++ that does not have an equivalent in other systems languages. It is commonly used to effect several types of compile-time verification of code design and safety that would be difficult to do any other way, in addition to its more obvious use case for effecting relatively complex performance optimization algorithmically. The ability to algorithmically generate almost arbitrarily complex types during compilation that are fit to purpose is an extremely useful feature for fast, high-reliability code and used pervasively in modern C++ as the facility has become more expressive. Filling some of the last remaining holes in its expressiveness would be high-value novel capability. Think of it as a hardcore safety feature.
You can put me in the camp that adding more support for concurrency in the language beyond a feature like coroutines (in C++20) and the existing primitives is not that useful. It would have the same issue as STL containers, where there simply isn't enough control of the implementation details for them to be used for many applications C++ is used for, so most concurrency infrastructure will be purpose-built anyway.
Pattern matching functionality can already be effected in many cases, albeit quite ugly. This would be more syntactic sugar than new capability, so I can understand why it isn't prioritized as much.
- pjmlp 7y agoHave you ever used Common Lisp macros, D meta-programming, Nim, Dylan macros, BETA pattern matching, OCaml pptx templates, Template Haskell,...? Yes, C++ compile time capabilities are powerful, but they aren't by all means the only game in town.
- jandrewrogers 7y agoAlmost none of those are systems programming languages, which was the domain of comparison.
- pjmlp 7y agoCommon Lisp (Lisp Machines), D, Nim, OCaml (MirageOS Unikernel, Docker macOS TCP/IP stack), Haskell (House OS and Galois bare metal deployments).
- nestorD 7y agoRust with its macro system and explicit target of system programming seem like a perfect fit.
- banachtarski 7y agoRust is beyond even current C++ with respect to compile time code.
- comex 7y agoSort of. Rust procedural macros are powerful, but they’re basically glorified code generation: they take a list of tokens as input and return a list of tokens as output. They don’t have access to type information. For that you need to use a combination of the trait system and `const fn`, to which the C++ equivalent is templates and `constexpr`. But C++ `constexpr` is currently way ahead of Rust `const fn` in functionality. And while Rust’s trait system tends to be nicer than C++’s templates for most purposes, it’s not as good at performing arbitrary computations. Overall, when I use either language I find myself badly missing features from the other. I look forward to seeing both close the gap…
- slaymaker1907 7y agoSystems programming language is only a useful term if you define what systems you are talking about. Are you talking about creating an OS, highly performance micro services, distributed systems, etc.? Common Lisp would likely be a poor choice for an OS but would be great for some of those other types of systems.
- jandrewrogers 7y agoI would say that the common feature of a systems language is that it is explicitly designed to enable direct control of hardware resources and -- very importantly -- operation scheduling by the programmer. A point I think is often overlooked is that some software architectures cannot be implemented correctly without this level of control, and for some applications those architectures are the only competent choice. Using a systems language should be driven by the requirements of application with respect to software architecture, and most applications don't have that requirement. Some applications that are above the OS and device drivers, such as database engines, are clearly in the domain of systems applications because it is not possible to create a competent implementation without the control a systems language provides. Even for relatively abstract high-level software like distributed systems, strict control of scheduling is required for consistently robust throughput and behavior. Some key algorithms only work in real systems if resource management and concurrent operation sequencing is inexpensively deterministic. For some other applications, the only real benefit of a systems language would be for performance engineering purposes, which may not be a practical priority. The "managed language" litmus test is quite good in my opinion, and almost definitional.
- pkolaczk 7y agoAlso Java (annotation processors) and Scala (macros with full access to type system). Java is considered good enough systems language for some definition of a system - there are successful high performance database engines, web servers, web frameworks, compilers, distributed computing engines written in Java.