Erlang/OTP 27 Highlights • Hacker News Board

Re: Erlang/OTP 27 Highlights

#51

Post by flembat » Thu, May 23, 2024, 4:31 AM UTC

binary132 wrote: post #46

TwentyPosts wrote: post #38

Earlier quoted context omitted.

I hate to be that guy, but if you want "C++ but also functional programming" then... Well, then Rust is in fact the language which you're looking for.

If anything the cognitive load of rust is worse than C++

Rust is certainly challenging, even copilot finds it difficult to write correct rust, it's fun to see the AI fight the compiler.

Re: Erlang/OTP 27 Highlights

#52

Post by lkuty » Thu, May 23, 2024, 6:14 AM UTC

nickpeterson wrote: post #12

I think I’m going to just break down and learn erlang. I’ve been interested in it for awhile but mostly work in f#. I recently started looking at gleam but I don’t think learning it with no knowledge of OTP is a good idea.

I would learn Elixir instead (unless you want to specifically learn Erlang) as it is a sort of a more modern Erlang and you get access to all Erlang ecosystem for free. Years ago, I switched a codebase from Erlang to Elixir and it was a breath of fresh air. Note that I like Erlang a lot, but Elixir even more.

Re: Erlang/OTP 27 Highlights

#53

Post by binary132 » Thu, May 23, 2024, 3:12 PM UTC

flembat wrote: post #51

binary132 wrote: post #46

Earlier quoted context omitted.

If anything the cognitive load of rust is worse than C++

Rust is certainly challenging, even copilot finds it difficult to write correct rust, it's fun to see the AI fight the compiler.

I guess the way I feel about using rust is kind of the opposite of how I feel about using Go. Go has such plain and straightforward semantics that it’s very easy to make simple, straightforward packages with it. It is actually even simpler than Python. In C++, it’s a pain to get there, but those simple anbstractions are still at least _possible_. In Rust, the nuances of the semantics are not only convoluted, but also very hard to encapsulate and abstract over. It’s not that the abstractions leak quite as much as it is that the nuances of the semantics are inextricably and necessarily _part of the package API_.

It could probably be argued that this is simply acknowledging reality, and that C++ lets you get away with murder if you want to. But maybe that’s what I want.

I think a good feature for C++ would be a “safe” (or “verified”?) block or method decorator that could enforce some set of restrictions on semantics, e.g. single mutable borrow. The problem is that those functionalities are part of the compiler APIs and not standardized.

The Rust compiler is also not standardized, but they can get away with it.