Haskell, OCaml, Erlang lead the way and Rust, Zig and Go get all the mindshare. I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

▲

cultofmetatron 5 hours ago | parent | next [-]

Rust and Zig brought new ideas for memory management that Haskell, OCaml, Erlang sidestep having garbage control. its honestly amazing to me that they managed to get the adoption they have while being so innovative. I say this as a fulltime elixir dev.

▲

skybrian 4 hours ago | parent | prev | next [-]

Being first isn't necessarily good if you get it wrong, though. Laziness by default and Hindley-Milner type inference seem like mistakes that simply aren't going to get cleaned up. Other languages make their own mistakes too.

▲

fwip 3 hours ago | parent [-]

What's wrong with Hindley-Milner?

▲

skybrian 3 hours ago | parent [-]

Leaving out types in public API's makes type errors hard to understand. Types should be declared in the API and bidirectional type inference used in the implementation.

https://jimmyhmiller.com/easiest-way-to-build-type-checker

	▲	josephg 2 hours ago \| parent [-]
		Eh. This causes some problems for rust. Right now you can have a function return impl Trait instead of a concrete type. Very handy - and essentially required by async functions. But the language also requires that types have names in lots of places. For example, you can't store an 'impl Trait' in a struct. You can't make a type alias of an impl Trait. And so on. As a result, async rust can only interact with a butchered subset of the language. (You can work around this with Box<dyn Future<...>> but performance suffers.) There's a proposal[1] to fix this. But the proposal has been under discussion for (checks watch) 7 years now. Until this lands, async remains a second class citizen in rust. This entire problem stems from rust's early decision to requiring concrete types at interface boundaries. https://github.com/rust-lang/rust/issues/63063

▲

jiggawatts 4 hours ago | parent | prev | next [-]

I wish I could find the reference, but there was a great blog / article by a computer science academic basically saying that OO, procedural, and functional paradigms are extremes of a design space where the “middle” of its Pareto frontier was essentially unknown until recent advances.

Moreover, many functional languages are getting pseudo-procedural features via the like of “do” syntax and monads, but that this is in some sense a double abstraction over the underlying machine that is already inherently procedural.

Starting from a language that is already procedural and sprinkling some functional abstractions on top is simpler to implement and easier for humans to use and understand.

Rust especially showed that many of the supposed advantages of functional languages are not their exclusive domain, such as sum types and a powerful type system.

Update: Hah! ChatGPT found it: https://news.ycombinator.com/item?id=21280429

Note the top comment especially, which explains succinctly why functional has rather substantial downsides.

▲

jen20 2 hours ago | parent | prev [-]

The idea that Erlang is experimental is pretty amusing- it’s one of the most stable platforms there is.