Things I like about Gleam's Syntax

• Phoenix

  111 20,579 9.3 Elixir

  Peace of mind from prototype to production

  

Since you mention Rails, have you seen https://www.phoenixframework.org/

• erlt

  5 102 -4.3 Erlang

  Discontinued Early prototype of ErlT, an experimental Erlang dialect with first-class support for static typing.

  

I remember reading somewhere,WA had to go back to do some improvements, so there was going to be a delay. Was it this one https://github.com/WhatsApp/erlt ?

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• otp

  9 346 7.3 Gleam

  📫 Fault tolerant multicore programs with actors (by gleam-lang)

  

Looks like it is an external library[^1]. Readme states it is experimental and lists some limitations.

[^1]: https://github.com/gleam-lang/otp

• rust

  2,682 92,831 10.0 Rust

  Empowering everyone to build reliable and efficient software.

  

The history on Rust’s todo!() is fun, because that’s actually not the reason why it was first made a macro.

First there was fn std::util::unreachable(). You had to import it, and the panic source printed out was …/rust/src/libstd/util.rs:132, which wasn’t very useful.

I wasn’t happy with this, and so proposed turning into a macro <https://github.com/rust-lang/rust/issues/8991>, which fixed both of those problems. The import thing alone could have been resolved by adding it to the prelude, but the panic message file/line thing couldn’t be fixed at the time other than by turning it into a macro.

At some point (still before 1.0.0) unimplemented!() was added as “unreachable!() but with a different message”.

In 1.20.0, these macros got the ability to take format arguments, because why not, since they’re already macros anyway, and adding an extra message is sometimes quite helpful. <https://github.com/rust-lang/rust/pull/42155>

Until this change, the sole reason for them being macros was the file and line number thing.

Then from October 2019 (though not stabilised until 1.46.0, but the standard library could immediately use it) came the really amusing part: this original reason became obsolete with #[track_caller].

So really there have been three distinct answers to “why is it a macro?” for three phases of Rust’s life:

• Before 1.20.0: “so the panic output gets the right file and line number”.

• Between 1.20.0 and 1.forty-something: “so the panic output gets the right file and line number, and because it takes format args”.

• Since then: “because we didn’t have #[track_caller] before 1.0.0 (since changing it from a macro to a function now would be a breaking change), and more recently because it accepts format args”.

If we’d had #[track_caller] back in 2013 (or any plans in that direction), we wouldn’t have made unreachable a macro, and then unimplemented would have also been made a function, and then format args stuff couldn’t have been added without introducing new macros, and I’m dubious it’d have happened.

Little things in history and how they affect the future can be fascinating to observe. This is a tiny and pretty harmless point, which I largely remember because it was one of my early contributions (and I haven’t made a large number in total, to drown it in volume), but there are many other things in Rust where little pragmatic decisions long ago have been causing all sorts of pain in trying to properly generalise them now. Const generics is far from the worst, but perhaps the simplest to observe, especially in how things have largely eventually been fixed (whereas various others have just ended up dead in the water). The [T; 0], [T; 1], [T; 2], …, [T; 12] implementations and similar have caused quite a lot of trouble.

(todo!() was added in 1.40.0 as a third member of this family of “panic!() but with a different message and intended semantics” macros.)

Suggest a related project