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

81–90 of 103 posts

Re: Erlang/OTP 24 highlights

#81

Post by lawik »

elcritch wrote: post #72
lawik wrote: post #62

Earlier quoted context omitted.

I've had interesting exchanges with a guy who does work on CouchDB. That is built with Erlang and should scale quite well in what sounds like a resilient way. Haven't dug in. Horizontal scaling of the DB seems like a problem in many architectures. For SQL I'd be looking at CockroachDB as it is Postgres-compatible and is built with scaling out in mind. Haven't tried it though. Most of my work hasn't needed that for th…

I love the notion of co-located processing and data, but most of the data stores dont quite embrace it. Well actually Riak does quite well if you're fine with a dynamo like kv store. The riak library is actually pretty nifty for distributed computations. But with Basho out of business it's harder to justify. Plus KV stores really aren't as usable as good ole sql. In that realm there's ActorDB, but I've not been able…

Hadn't heard of ActorDB. Interesting. But is it alive? Seems inactive.

Re: Erlang/OTP 24 highlights

#82

Post by all2 »

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'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.

Re: Erlang/OTP 24 highlights

#83

Post by hinkley »

bananabreakfast wrote: post #52
nullgeo wrote: post #46

Earlier quoted context omitted.

Recently I read somewhere that writing long prose is easy but writing something succinct takes way longer. I think that translates to writing code as well.

Brevity is the soul of wit.

Laziness is the father of efficiency.

Re: Erlang/OTP 24 highlights

#84

Post by hinkley »

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 that's where people swing back to DAMP, or at least the rule of 3.

I'm not trying to fractally compress my code. I'm trying to make it succinct. Those two things are very different. Now if I could only convince a particular coworker of that...

Re: Erlang/OTP 24 highlights

#85

Post by elcritch »

lawik wrote: post #81
elcritch wrote: post #72

Earlier quoted context omitted.

I love the notion of co-located processing and data, but most of the data stores dont quite embrace it. Well actually Riak does quite well if you're fine with a dynamo like kv store. The riak library is actually pretty nifty for distributed computations. But with Basho out of business it's harder to justify. Plus KV stores really aren't as usable as good ole sql. In that realm there's ActorDB, but I've not been able…

Hadn't heard of ActorDB. Interesting. But is it alive? Seems inactive.

It seems dead and it relies on some (older) rebar stuff. And the custom "actor" syntax would probably break Ecto..

Re: Erlang/OTP 24 highlights

#86

Post by ijlx »

bwanab wrote: post #54
nullgeo wrote: post #46

Earlier quoted context omitted.

Recently I read somewhere that writing long prose is easy but writing something succinct takes way longer. I think that translates to writing code as well.

“ I only made this letter longer because I had not the leisure to make it shorter.” Blaise Pascal

Ironically that's quite a pithy statement.

Re: Erlang/OTP 24 highlights

#87

Post by bostonvaulter2 »

latch wrote: post #39
rubyn00bie wrote: post #37

Earlier quoted context omitted.

`mix test` _is_ fast for me... I've only seen slow tests when folks are misusing timeouts (generally speaking); what problem are you seeing?

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…

Are you sure that you're not including application startup in that 10 second measurement? I've seen code bases where horde or some other clustering was enabled in the test env and causing a ~5 second delay on application startup.

Re: Erlang/OTP 24 highlights

#89

Post by sivakon »

rubyn00bie wrote: post #29

OMG, YES! The JIT is here... and holy crap, if you haven't tried it yet... it's awesome (everything feels snappier). I'm particularly stoked for the receive optimizations and process aliases. BEAM just gets better and better. It's a good time to be an Erlanger/Elixirist...

I just ran programs from computer language benchmarks with OTP24. Every program ran considerably faster almost 30% speed up.

Re: Erlang/OTP 24 highlights

#90

Post by igouy »

tiffanyh wrote: post #49

BeamASM vs HiPE? Since BeamASM doesn't support HiPE - has anyone seen benchmarks of BeamASM (JIT) vs HiPE. I've searched and searched and can't find such analysis. (Super excited the JIT work is seeing light after 10+ years)

fwiw elapsed seconds

    Erlang/OTP 23 [erts-11.1] [hipe]
    Erlang/OTP 24 [erts-12.0] [jit]

    binarytrees,hipe,1,7.531
    binarytrees,erlang,1,11.768

    binarytrees,hipe,2,4.172
    binarytrees,erlang,2,5.149

    fannkuchredux,hipe,1,59.079
    fannkuchredux,erlang,1,73.151

    fasta,hipe,1,57.006
    fasta,erlang,1,50.843

    fasta,erlang,2,20.209

    knucleotide,hipe,1,92.662
    knucleotide,erlang,1,80.360

    knucleotide,hipe,3,86.793
    knucleotide,erlang,3,70.949

    mandelbrot,hipe,1,118.623
    mandelbrot,erlang,1,48.756

    mandelbrot,hipe,2,101.211
    mandelbrot,erlang,2,46.154

    mandelbrot,hipe,3,87.793
    mandelbrot,erlang,3,44.633

    mandelbrot,hipe,4,84.878
    mandelbrot,erlang,4,44.976

    nbody,hipe,3,140.025
    nbody,erlang,3,100.630

    pidigits,hipe,1,8.791
    pidigits,erlang,1,8.008

    pidigits,hipe,2,8.515
    pidigits,erlang,2,8.673

    pidigits,hipe,3,7.935
    pidigits,erlang,3,7.748

    regexredux,hipe,6,42.757
    regexredux,erlang,40.402

    revcomp,hipe,1,25.622
    revcomp,erlang,1,23.070

    revcomp,hipe,3,188.990
    revcomp,erlang,3,155.024

    revcomp,hipe,4,122.507
    revcomp,erlang,4,106.456

    spectralnorm,hipe,1,92.347
    spectralnorm,erlang,1,62.519

    spectralnorm,hipe,2,11.176
    spectralnorm,erlang,2,11.460
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Post reply on HN