4 ms·

Rust is getting that, gradually, with the work of replacing the ad-hoc "const evaluator" with miri (an interpreter for a Rust intermediate representation). Righ

Rust is getting that, gradually, with the work of replacing the ad-hoc "const evaluator" with miri (an interpreter for a Rust intermediate representation). Right now you have procedural macros, which are Rust code that operates on the syntax tree, including custom attributes. Proper reflective metaprogramming would be a fairly big step though - right now, the macro systems happen well before the type system even gets a chance to look at the code, so the data to play with types in an interesting way isn't there at the right step.

Animats 6y ago
Rust is getting that, gradually. Uh oh. I'd hoped the language would settle down. The Go crowd knows when to stop. Go is mediocre, but stable.
- Rantenki 6y ago
  It's possible to stop too soon though.
- TA0X4 6y ago
  >The Go crowd knows when to stop. Considering Go is removing "blacklist" from it's code and documentation because it can delusionally be construed as racist, I'd say they don't know when to stop.
- TA0X5 6y ago
  >The Go crowd knows when to stop. Considering Go is removing "blacklist" from it's code and documentation because it can delusionally be construed as racist, I'd say they don't know when to stop.
- ThA0x1 6y ago
  >The Go crowd knows when to stop. Considering Go is removing "blacklist" from it's code because deranged individuals can delusionally construe it as racist, I'd say they don't know when to stop.
  - andrewshadura 6y ago
    It would be great if you could avoid aggressive attacks on other people's views.
- shpongled 6y ago
  You say that like mediocre is a compliment. But I guess "mediocre" has been the best descriptor of Go from its inception.
  - Animats 6y ago
    Kind of, yes. Go has a specific goal - replace C++ for server-side web related stuff. It's supposed to be dull, boring, reliable, and suitable for use by large numbers of programmers doing that kind of work. It's a success at that. Go got some things right, like "goroutines". Other languages are trying to add threads to a language with "async" type callbacks (Javascript), or "async" type callbacks to a language with threads (Python). Those concepts do not play well together, especially when retrofitted. Go does have a one-size-fits-most solution which handles the main use case - a server process handling a very large number of intermittently sending clients. The same can be said of "functional" add-ons. Full-on functional languages can be OK, but functional features in an imperative language tend to be on the painful side syntactically. Retrofitting "functional" is even worse.

Animats 6y ago

Rust is getting that, gradually. Uh oh. I'd hoped the language would settle down. The Go crowd knows when to stop. Go is mediocre, but stable.

Rantenki 6y ago
It's possible to stop too soon though.
TA0X4 6y ago
>The Go crowd knows when to stop. Considering Go is removing "blacklist" from it's code and documentation because it can delusionally be construed as racist, I'd say they don't know when to stop.
TA0X5 6y ago
>The Go crowd knows when to stop. Considering Go is removing "blacklist" from it's code and documentation because it can delusionally be construed as racist, I'd say they don't know when to stop.
ThA0x1 6y ago
>The Go crowd knows when to stop. Considering Go is removing "blacklist" from it's code because deranged individuals can delusionally construe it as racist, I'd say they don't know when to stop.
- andrewshadura 6y ago
  It would be great if you could avoid aggressive attacks on other people's views.
shpongled 6y ago
You say that like mediocre is a compliment. But I guess "mediocre" has been the best descriptor of Go from its inception.
- Animats 6y ago
  Kind of, yes. Go has a specific goal - replace C++ for server-side web related stuff. It's supposed to be dull, boring, reliable, and suitable for use by large numbers of programmers doing that kind of work. It's a success at that. Go got some things right, like "goroutines". Other languages are trying to add threads to a language with "async" type callbacks (Javascript), or "async" type callbacks to a language with threads (Python). Those concepts do not play well together, especially when retrofitted. Go does have a one-size-fits-most solution which handles the main use case - a server process handling a very large number of intermittently sending clients. The same can be said of "functional" add-ons. Full-on functional languages can be OK, but functional features in an imperative language tend to be on the painful side syntactically. Retrofitting "functional" is even worse.