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

Erlang: The coding language that finance forgot (2022)

efinancialcareers.com

Post reply on HN
Print view View original

121–130 of 155 posts

Re: Erlang: The coding language that finance forgot (2022)

#121

Post by linux2647 »

innocentoldguy wrote: post #94
aynyc wrote: post #81

Erlang isn't dying but not many people care for it in capital market. Looks at the traits of Erlang, it's designed for telecom environment which is almost opposite of capital market. 1. Fault tolerance is almost all hardware driven. Capital market participants spent billions of dollar building reliable private networks. 2. Distributed in trading doesn't mean what FAANG are doing. Trading systems for example usually r…

The company I currently work for switched from Java to Elixir/Erlang because developer productivity was so much higher. Being able to turn around features and fixes in a fraction of the time has been quite valuable for us.

What industry/domain is the software you write in?

Re: Erlang: The coding language that finance forgot (2022)

#122

Post by sodapopcan »

sodapopcan wrote: post #78
haspok wrote: post #35

Maybe the title would have been better like this: "PROLOG: The coding language that finance forgot." Erlang (the language) is rooted in Prolog, and many of its best traits can be traced back to this fact. That everything is a pattern, and you can pattern match pretty much anything is rarely found in other languages, for example. Elixir made a mistake in my opinion when it went with a Ruby-like syntax. Also, there are…

What's the mistake in going with a Ruby-like syntax? I don't necessarily disagree in terms of wider adoption (though I personally really really like the syntax) though the context is unclear around your statement.

No one can clarify? Did I get downvoted for saying I like Ruby syntax or that I didn't understand the context? I don't understand how pattern matching and Ruby syntax have any correlation. I've never heard of any pattern matching possible in Erlang that was made impossible in Eilxir due to Ruby-like syntax. Am I wrong?

Re: Erlang: The coding language that finance forgot (2022)

#123

Post by lispm »

capableweb wrote: post #95
stevan wrote: post #79

Earlier quoted context omitted.

In the 70s Ericsson programmed their telephone switches in a proprietary language called PLEX. It had hot code swapping, so when Joe Armstrong started working on Erlang to replace PLEX in the 80s this was a requirement. Dropping a few thousands of calls just to do an update simply wasn't an option.

On the other hand, even the first versions of lisps (as far as I can gather at least) had `eval`, meaning a running program could accept external output and update itself. And this was in the 60s. The question remains :)

Lisp would also be able to compile code to assembler, run an assembler and load the generated code into the runtime.

I would think (without knowing too much about Erlang's mechanisms) that the mechanisms of Erlang are quite different from what a Lisp runtime typically does. The Lisp runtime is just one process. Erlang is concerned with multiple processes, which are strongly isolated.

Re: Erlang: The coding language that finance forgot (2022)

#124

Post by frellus »

TuringTest wrote: post #57
mikl wrote: post #24

The reason Erlang (and Elixir) are interesting are not the languages themselves (although Elixir is a very nice language in my opinion), but the runtime behind them, BEAM. The BEAM is the brainchild of the excellent engineers at Ericsson, the product of decades of R&D into building performant, scalable and reliable software for their telephony products. It scales like a dream, runs your application on all available c…

What's the license for the BEAM runtime? I've found that Erland and Elixir are both Apache License, but I can't find out whether the bytecode they generate can be executed in a fully open source environment.

It's Apache 2.0

Reference: https://github.com/erlang/otp/blob/master/erts/AUTHORS

Re: Erlang: The coding language that finance forgot (2022)

#125

Post by somekyle2 »

newswasboring wrote: post #107
weatherlight wrote: post #97

Earlier quoted context omitted.

Everyone always talks/jokes about, "Rewrite it in Rust," think about all the business applications over the years that had been rewritten to Java, just because. Usually under the guise of, "Kids coming out of college will have an easier time wrapping their heads around Java," than some other lang. In my time as an engineer, I've seen quite a few Scala and Clojure apps, get rewritten in this manner. This is all antido…

I sometimes wonder if this logic makes sense. I'm currently leading a fully inexperienced team where my main challenge isn't delivering products but qualified people. I have to make them learn so many company specific and codebase specific things that feels like learning a new language would be a least of it. This is of course colored by my language learning loving lens, so I can't be sure about this.

I've been on teams responsible for components written in more niche, powerful languages by previous employees who were deep in that particular language community. The author was really smart, the code was good. It was a big headache. First off, different build setup, different runtime, couldn't use most of our standard libs, so it was an island. It being in a language most people didn't know well meant it mostly only got updated as necessary; we certainly had people who could read the code and make tweaks with some comfort, but it was mostly just tweaks because nobody had the depth to really engage with the high level design idioms. It being a niche lang/community, it moved fast, so after a year or so our tool was apparently using deprecated practices; in our supported languages, teams did large-scale fixup across repos for new versions, but this being a special lang/toolchain, it was on us. Eventually, I believe it got rewritten, somewhat simpler, in one of our supported languages, and it was fine.

Maybe this is a success story: someone made a useful tool in a weird language and we used it successfully for at least a year. Maybe it wouldn't have been made or would've been worse or more expensive if they'd been forced to write it in a supported language. Maybe it would've needed to be rewritten anyway.

My view is a simple one; as one of the leads responsible for it, it was a special case bit of code, something people tried to avoid touching. Nothing about it required a niche language technically, so the added difficulty of working around that was friction and risk. It wasn't that people couldn't learn the language; they could, we had lang PhDs. It's just better if you can keep people where they have existing expertise, and spend your learning points on solving problems users care about.

Re: Erlang: The coding language that finance forgot (2022)

#126

Post by jjtheblunt »

djtango wrote: post #89
college_physics wrote: post #82

Finance means different things to different people. Are we talking about trading "finance" (including high frequency trading), investment banking "spreadsheet" finance, consumer or corporate "database" finance or maybe even (the horror, the horror) "defi" cryptofinance? What is true is that finance in almost all its guises is a world apart in terms of information technology. Closed and proprietary, ultra expensive an…

Wasn't WeChat built in Erlang as well?

I think WhatsApp was Elixir

Re: Erlang: The coding language that finance forgot (2022)

#127

Post by weatherlight »

holsee wrote: post #73
codesnik wrote: post #42

Earlier quoted context omitted.

I personally don't find this binding once behaviour problematic in any way, but Elixir specifically addresses this (it creates another variable with the same name, though)

I wish they didn't tbh, it makes me sad. Not allowing rebinding does provide a little bit of encouragement towards factoring things better, but I have seen manys a `X1` `X2` in my time :(

its a bit of a smell, but good elixir code doesn't have to worry about rebinding for bindings in the same scope.

Jose Valim goes on as to why he made that design decision from the following: https://groups.google.com/g/elixir-lang-talk/c/w83lKZs4YS8/m...

    I will post the same answer from before: I like the explicitness of pattern 
    matching. In Elixir, as soon as I see ^foo, I know I am matching. If there is 
    no ^, I know the previous value regardless if it there is one or not, will be 
    discarded. If pattern matching is not explicit, I always need to know if a 
    variable was previously defined or not to know what is going to happen. To me 
    this behaviour is non negotiable. In my experience, it is more likely to run 
    into accidental matches than into accidental rebindings.

    Another possible limitation to the suggestion above can be related to macros. 
    Let's suppose you have a macro that stores a value in a hygienic variable:

    defmacro do_something(a, b) do
      quote do
        var!(hello, Hygienic) = calculate_something(unquote(a), unquote(b))
      end
    end

    Someone may call this macro multiple times but we always care about the last 
    value 
    of hello. If we make a distinction in between being assigned once and then 
    multiple times, the macro simply won't work. Or the macro developer would need to 
    work around this behaviour by inspecting the environment or we would need to 
    provide some sort of functionality that does it for you. Maybe this behaviour 
    could be built-in in var! or maybe we'd need to introduce something like:

    defmacro do_something(a, b) do
      quote do
        set!(hello, Hygienic) = calculate_something(unquote(a), unquote(b))
      end
    end

    We can see how this is getting complex:

    1. Use = to define variables
    2. Use ^ for pattern matching
    3. Use := for rebinding
    4. Use set! in macros when you don't care if a variable was previously defined or not

    It is also interesting to point out that the := operator won't work for rebinding 
    inside clauses. For example, how would you make the rebinding below explicit?

    x = true
    case false do
      x -> :ok
    end

    Of course, there are interesting consequences for making a distinction in between 
    defining and rebinding a variable by introducing something like the := operator. 
    We could have better control of the scope to provide better warnings or even make 
    it easier to implement imperative for loops:

    x = 0

    for i  15

    But the fact Elixir have different ways for variables to be introduced in the 
    scope, adding more rules can make the overall system very complex.

Re: Erlang: The coding language that finance forgot (2022)

#128

Post by weatherlight »

holsee wrote: post #68
loftsy wrote: post #38

I've written some Erlang and found the syntax awkward. One example of this is that variables can only be bound once. This means you end up writing: Val = SomeFunc() Val1 = Func2(Val) Val2 = Func3(Val1) Yes I know you can use the functional style to minimise having to do this but you still end up seeing this pattern in real code. Kubernetes has done a good job of replacing OTP. That said I think Erlang is still an int…

Sounds like a good old foldl may or may not have brightened up your day (with the "functional style" you mentioned) e.g. Pipeline = fun(Functions, Initial) -> lists:foldl( fun(Function, Acc) -> Function(Acc) end, Initial, Functions ), Initial = SomeFunc(), Pipeline = [Func0, Func1, Func2, Func3], Result = Pipeline(Pipeline, Initial). At a certain point I grew to not mind the punctuations `; , .` I often miss language…

seems more complicated than the following elixir code.

    Val
    |> SomeFunc()
    |> Func2()
    |> Func3()

Re: Erlang: The coding language that finance forgot (2022)

#129

Post by vineyardmike »

adenozine wrote: post #84
haspok wrote: post #35

Maybe the title would have been better like this: "PROLOG: The coding language that finance forgot." Erlang (the language) is rooted in Prolog, and many of its best traits can be traced back to this fact. That everything is a pattern, and you can pattern match pretty much anything is rarely found in other languages, for example. Elixir made a mistake in my opinion when it went with a Ruby-like syntax. Also, there are…

Have you seen gleam.run? It’s pretty neat. I preferred the alpha syntax, which was ML-inspired, but it’s decent in its current incarnation. I’ve always though the beam was really nice for building programming languages, and clearly that is true, as there are now more than a dozen targeting it.

Thank you for this! I love elixir and Erlang but I hate elixir’s syntax, so Gleam looks really cool!

Are you aware of other beam-targeting languages?

Re: Erlang: The coding language that finance forgot (2022)

#130

Post by topaz0 »

freedomben wrote: post #113
Lio wrote: post #7

Earlier quoted context omitted.

It's only a word but the very fact the article refers to Erlang as a "coding language" and not a "programming language" is enough to give it a cheap, amateurish feel from the start IMHO. I'd just ignore it as low quality click bait if I were you.

It may indicate that it was written by someone who is relatively young. The teenagers I know (including my own) all say "coding", never say "programming". I suspect the latter sounds "old" to them. Since the young tend to be amateurs, I whole heartedly agree that it sounds amateurish. It probably is, and we're probably getting old.

"coding", sure -- I say that all the time too. But "coding language" is something I have never heard.
Post reply on HN