Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Erlang/OTP 24 highlights

blog.erlang.org

Post reply on HN
Print view View original

91–100 of 103 posts

Re: Erlang/OTP 24 highlights

#91

Post by semilattice »

Seems like there is less and less reason for not using Erlang for distributed coordinated compute broker tasks.

I have a stateless java backend servicing REST APIs. These backends are load-balanced by nginx.

Now the time is approaching where I need to introduce some form of global state (that involves global caching, message passing, registering/discovery of known workers, periodic (cron-like tasks), etc).

I would much prefer a single tool to add to my backend stack (currently Java + postgres) to cover most of the above needs.

With the performance improvement + persistent_term [1] -- in current Erlang, I basically get:

- a light weight distributed K/V cache

- a ZeroMQ like on-wire messaging system (built into erlang)

- discovery/coordination

- a distributed compute grid

- a way to write my own routines within that compute grid, and have them exposed via Java interface to my existing backend.

I do not need 'fastest' possible performance or least memory consumption. I just need them to be 'reasonable', 'known' and 'controllable' (not to exceed some baseline).

Erlang is just looking better and better (and I prefer its syntax to Elixir, for some reason.).

[1] https://erlang.org/doc/man/persistent_term.html

Re: Erlang/OTP 24 highlights

#93

Post by pdimitar »

deeviant wrote: post #51
travisgriggs wrote: post #25

> there are still 260k lines of code added and 320k lines removed So a net reduction of 60K lines of code? And yet functionality was added to the system as well. That's praiseworthy IMO. Imagine if "we did more with less" infected much of software development today.

Imagine if we had a metric of "how easy is the code to understand and work with" rather than "can we do it with less lines of code".

I think every good programmer has these rules of thumb, from most important to less important:

1. Make it so you'll understand it in 2 minutes after being away for a year. Positive side effect: it's very readable for your colleagues.

2. Make it brief.

3. Make it fast.

4. Make it pretty (although often times readable + brief code is pretty but obviously it's subjective).

Re: Erlang/OTP 24 highlights

#94

Post by pdimitar »

all2 wrote: post #82
deeviant wrote: post #51

Earlier quoted context omitted.

Imagine if we had a metric of "how easy is the code to understand and work with" rather than "can we do it with less lines of code".

I've gotten to a place where I start with a sketch of how I think my code ought to be used and then work backward into the implementation. So far I've gotten a lot of pushback from others on my team. And, what starts as "oh, you should just have to ____" gets really messy as the implementation takes shape.

So test-driven development (where you write the user -- the test -- first, and then the implementation)?

Re: Erlang/OTP 24 highlights

#95

Post by pdimitar »

josevalim wrote: post #76
latch wrote: post #39

Earlier quoted context omitted.

The delay is all in compiling exs files. It uses Kernel.ParallelCompiler to compile every .exs file, so it's very CPU/core dependent. On my weaker laptop, `mix test` takes nearly 10 seconds to just start. I've looked into this in more details in the past. We've had success just writing our own test runner and avoiding exs files. But re-implementing things like running tests based on line number, or integrating with e…

FWIW, I recently pushed a commit to master that made loading of Elixir's test suite 33% faster (from 15s to 10s): https://github.com/elixir-lang/elixir/commit/2eb03e4a314c0e6... Unfortunately, it is a bit too large (and too late) for v1.12, but if loading times have been problematic for you, it would be awesome if you could try master out and let us know in the issues tracker (or in the commit) if you see any improve…

Can we expect it for 1.13?

Re: Erlang/OTP 24 highlights

#96

Post by pdimitar »

semilattice wrote: post #91

Seems like there is less and less reason for not using Erlang for distributed coordinated compute broker tasks. I have a stateless java backend servicing REST APIs. These backends are load-balanced by nginx. Now the time is approaching where I need to introduce some form of global state (that involves global caching, message passing, registering/discovery of known workers, periodic (cron-like tasks), etc). I would mu…

Do consider Elixir for its metaprogramming (macros) and the goodies that come with them, namely fantastic libraries and frameworks like Ecto and Phoenix.

Re: Erlang/OTP 24 highlights

#97

Post by pdimitar »

QuinnWilton wrote: post #79
cuddlecake wrote: post #69

Earlier quoted context omitted.

If you want type systems, you can probably work with Gleam, in the future, I imagine there could be great interop where you can just drop in a .gleam file in your elixir code base with zero hassle attached, and have parts of your code base that are completely type safe, and let Elixir handle all the risks of IO and other effects. But, this might just be my wishful thinking.

For what it's worth, I spoke last year about using Gleam to develop a type-safe core for a LiveView application: https://www.youtube.com/watch?v=UCIcJBM_YDw I think that what you're looking for is already possible today, and that things only get easier over time.

I agree it's possible. The pertinent question is: how easy and ergonomic it is to do? Friction kills good innovation very often.

Re: Erlang/OTP 24 highlights

#98

Post by pdimitar »

mindfulmore wrote: post #55
akoutmos wrote: post #50

Earlier quoted context omitted.

As someone who has been programming with Elixir for my day job for the past few years, I find this aspect of the language to be super pragmatic and productive. It's a nice feeling to not have to chase new language features and syntax and focus more on the problem at hand. In addition, I've never felt limited by the language given that the underlying constructs are so powerful (message passing, immutability, pattern m…

Curious, do you use typespecs and dialyzer? If so, how do you find it? Elixir checks pretty much every box I'd want in a language, but after dealing with nil in Ruby for years and having fun with TypeScript... I'm feeling more drawn to working with type systems.

Dialyzer and typespecs are better than nothing but not with much because they can introduce a lot of friction along the way, for not much benefit.

As another poster said, it can catch the very occasional potential bug but to me at least it's rarely worth the hassle.

I miss static typing after I got back to Elixir from Rust but the BEAM will likely never be statically typed.

To that end, I found utilizing metaprogramming to generate normal and property tests to be much more productive use of my time, with a measurable impact to boot.

Re: Erlang/OTP 24 highlights

#99

Post by linkdd »

mindfulmore wrote: post #55
akoutmos wrote: post #50

Earlier quoted context omitted.

As someone who has been programming with Elixir for my day job for the past few years, I find this aspect of the language to be super pragmatic and productive. It's a nice feeling to not have to chase new language features and syntax and focus more on the problem at hand. In addition, I've never felt limited by the language given that the underlying constructs are so powerful (message passing, immutability, pattern m…

Curious, do you use typespecs and dialyzer? If so, how do you find it? Elixir checks pretty much every box I'd want in a language, but after dealing with nil in Ruby for years and having fun with TypeScript... I'm feeling more drawn to working with type systems.

I generally verify types only at the boundaries of my application (or very critical modules) using norm[1].

Either you have a strict type system that does not have an "any" type (yes, I'm looking at you Typescript), or you have a flexible type system like Python/Erlang/Elixir and you do runtime type checking whenever it's needed.

I'm writing more Typescript code than I would in Javascript for almost no type safety benefits (but for documentation, it's awesome).

[1] - https://github.com/keathley/norm

Re: Erlang/OTP 24 highlights

#100

Post by CRConrad »

travisgriggs wrote: post #25

> there are still 260k lines of code added and 320k lines removed So a net reduction of 60K lines of code? And yet functionality was added to the system as well. That's praiseworthy IMO. Imagine if "we did more with less" infected much of software development today.

> So a net reduction of 60K lines of code? And yet functionality was added to the system as well. That's praiseworthy IMO.

Yup.

> Imagine if "we did more with less" infected much of software development today.

Taken to its logical conclusion this should mean that the ultimate piece of software, that does everything and does it perfectly, is 0 LoC.

Hmm, fells like I need to check my logic here...

Post reply on HN