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

OTP 23

erlang.org

Post reply on HN
Print view View original

81–90 of 121 posts

Re: OTP 23

#81

Post by elcritch »

pmontra wrote: post #80
pera wrote: post #63

Earlier quoted context omitted.

> I mean, unlike in typical hard FP languages like Haskell or Elm What is a "typical" FP language? Are Scheme, Common Lisp, OCaml, SML, atypical? > mutable state is rampant in your average Elixir app I don't think this is generally true, or at least not on my experience, but I guess it may depend on what would one consider rampant.

Well, my main Elixir project is the backend of a web service. The input is JSON from the frontend and JSON or XML from a number of third party APIs. We process it, hit the db with select, update, insert and usually return a value. The same function with the same inputs usually returns different values because the db is stateful. What I like of Elixir is not functional programming, it's the extensive use of pattern ma…

Thankfully they didn't give it Java like syntax! The syntax is currently a bit more verbose and explicit on dealing with local/micro state which I now like, but without using 100 lines of boilerplate getter/setters. Using pipes gets one enough "OO" syntax feel.

While GenServer's store state they are, in my mind, more akin to microservices than Java/C++ Objects. They're like microservices, but without needing a separate service bus, global naming system (pg2), etc. Now I do wish Dialyzer/Dialyxer also had better support for checking GenServer handler's and messages, especially intra-process. You have a point the syntax their could be spruced up some perhaps. The process / GenServer paradigm kind of remind me of Smalltalk in a way, where you're passing messages that object may or may not want to respond to. That's not really possible with C++/Java objects.

Re: OTP 23

#82

Post by elcritch »

Looking at the changelog I don't see what the current situation with erl_interface is. I've been working on some `erl_interface` code using C [2] and Nim [1], and the headers warn that older `erl_interface` headers would be deprecated in OTP 23. All the release note highlights mention is a new `erl_call` program.

Anyone know about the status / rational for the `erl_interface.h` API?

1: 1: https://github.com/elcritch/einode/ 2: https://github.com/elcritch/einode/tree/master/tests/c-nodes...

Re: OTP 23

#83

Post by strmpnk »

elcritch wrote: post #82

Looking at the changelog I don't see what the current situation with erl_interface is. I've been working on some `erl_interface` code using C [2] and Nim [1], and the headers warn that older `erl_interface` headers would be deprecated in OTP 23. All the release note highlights mention is a new `erl_call` program. Anyone know about the status / rational for the `erl_interface.h` API? 1: 1: https://github.com/elcritch/…

Much of the erl_interface functionality prefixed with erl_ names has been deprecated since OTP 22 and has been removed. The API has shifted to newer ei_ prefixed functions. I believe there are some new deprecations in place as well which you can find the longer form release notes.

erl_interface itself is not going away but it is evolving with the BEAM VM. Deprecation warnings should be checked when compiling code on each major release to avoid surprises as features are usually deprecated for one release and then removed in the next release each year. The erl_interface documentation should be up to date with regards to new APIs and might be worth browsing again to get an idea of the what changes look like.

Re: OTP 23

#84

Post by dnautics »

mcmatterson wrote: post #30
dnautics wrote: post #28

Earlier quoted context omitted.

I think it's already there? Erlang/OTP 22 Interactive Elixir (1.10.3) defmodule Test do def matchme(value) do x = :foo %{^x => bar} = value IO.puts(bar) end end > Test.matchme(%{foo: "bar"}) bar :ok

My goodness, you're right (well, your example isn't, but the feature I'm talking about has been present since at least 1.8 (the earliest install I have handy): > > = > "abc" > > val "abc" I don't know how I'd missed that. (Your example demonstrates 'pinning' which has been a thing since always I think).

oh prior as in lexically prior. The example in the erlang release I believe uses something that looks like what I wrote. I use the sort of matches you are talking about extensively in network packet size matching for a project I'm working on.

Re: OTP 23

#85

Post by elcritch »

strmpnk wrote: post #83
elcritch wrote: post #82

Looking at the changelog I don't see what the current situation with erl_interface is. I've been working on some `erl_interface` code using C [2] and Nim [1], and the headers warn that older `erl_interface` headers would be deprecated in OTP 23. All the release note highlights mention is a new `erl_call` program. Anyone know about the status / rational for the `erl_interface.h` API? 1: 1: https://github.com/elcritch/…

Much of the erl_interface functionality prefixed with erl_ names has been deprecated since OTP 22 and has been removed. The API has shifted to newer ei_ prefixed functions. I believe there are some new deprecations in place as well which you can find the longer form release notes. erl_interface itself is not going away but it is evolving with the BEAM VM. Deprecation warnings should be checked when compiling code on…

Thanks! That's good info. The hardest part was that in OTP 22 the examples given used many of the deprecated erl_* apis. I was able to update the C examples (see the second link) to use non-deprecated ei_* api calls. Mostly small changes and a bit better buffer management. Though, I don't like the lack of buffer length check in even the newer ei_encode_* functions. :/ I added a 24 byte padding guessing most single item encodes are less than that, and then check variable length items for size. Still hard to use safely without a buffer overrun. I'll take a look and see what else may have changed. It's exciting seeing all the continual beam improvements!

Re: OTP 23

#86

Post by moviedo »

AlchemistCamp wrote: post #34
moviedo wrote: post #5

I'm currently learning erlang/elixir and I'm really enjoying the language constructs. I had originally taken a Programming Language Paradigms class in college with racket, and I really didn't appreciate functional ideas(i.e. syntax is my excuse). I'm now a really big fan of functional language idioms. Anyone interested should try the futurelearn class, https://www.futurelearn.com/courses/functional-programming-e... .

Interesting. Is FutureLearn something analogous to Coursera and edX?

Yes, very much the same as Coursera. Almost 1 to 1.

Re: OTP 23

#87

Post by 1_player »

dnautics wrote: post #20
organicfigs wrote: post #16

Earlier quoted context omitted.

I've wanted to work with Elixir for 5 years now. I attempted to go through The Pragmatic Programmer's Elixir textbook and couldn't make it through. This comment applies solely to me, I feel I didn't have the aptitude to pick up functional programming (and that's coming from someone who graduated in CS from a T3, had years of experience, and starting med school next month).

There's a reputation that functional programming is harder than object-oriented. I think this comes from the very difficult functional programming languages that exist out there. I think that can be an obstacle. People hear "fp" and think "hard". I personally find Elixir's functional programming is easier, because there are fewer things you have to deal with than object oriented. There are basically no constructs in…

Map and reduce are not hard if taught correctly.

You have a list of N elements and want to trasform it into another list of N elements -> map

You have a list and want to transform it into a single value -> reduce

Fin.

But hey, you ask, can’t a list be considered a single value? Yes, of course, so map can be implemented using reduce, making it the most useful FP construct

Re: OTP 23

#88

Post by dnautics »

pdimitar wrote: post #60
coderdd wrote: post #48

Earlier quoted context omitted.

Actor frameworks with message passing, just like direct mutation, don't compose. On Haskell, yes, you can just work off a thread and write shared buffers. But you are better off using STM or Async (these are a bit like futures), which compose, and you can write pipelines out of them.

Everything that you pointed out can be achieved in Elixir, quite easily too. If I understood you correctly. Not sure what you mean by "actor frameworks don't compose"?

Actor frameworks don't compose, because actors are an atomic compute unit. You can't really take a horse actor and a bird actor and turn them into a pegasus actor. There are non-trivial interactions between message handling logic that would prevent such a thing with some fairly trivial-to-generate breaking cases.

Maybe composition for compositions' sake isn't that important?

Re: OTP 23

#89

Post by dnautics »

skrebbel wrote: post #27
moviedo wrote: post #5

I'm currently learning erlang/elixir and I'm really enjoying the language constructs. I had originally taken a Programming Language Paradigms class in college with racket, and I really didn't appreciate functional ideas(i.e. syntax is my excuse). I'm now a really big fan of functional language idioms. Anyone interested should try the futurelearn class, https://www.futurelearn.com/courses/functional-programming-e... .

I never understood why people rave so much about functional programming wrt Erlang/Elixir, when its functional programming is clearly only a means to an end (fast and safe message passing requires immutable data, which requires FP) and not a driving design goal in its own right. I mean, unlike in typical hard FP languages like Haskell or Elm, mutable state is rampant in your average Elixir app, it's just spread out a…

> You just get such a small subset of the usual advantages of FP

Yeah but you're using that small subset in 90% of your code.

Look, this is not a thing to worry about in elixir:

    def p(my_array):
      do_something_with_this_array(my_array)
      return my_array
what is my array? I don't know. It could be anything. The company I work for just hired a sloppy python programmer that I don't want anywhere near my code, and you know what, if we change a section of our code to Elixir I am way more willing to have him work on our team.

Re: OTP 23

#90

Post by schadara »

organicfigs wrote: post #16
xutopia wrote: post #14

Though I am not working with Erlang or Elixir right now I am so pleased that this is seeing improvements. I had as much fun learning Elixir as I did learning Ruby ages ago. It's just a fun language with great construct!

I've wanted to work with Elixir for 5 years now. I attempted to go through The Pragmatic Programmer's Elixir textbook and couldn't make it through. This comment applies solely to me, I feel I didn't have the aptitude to pick up functional programming (and that's coming from someone who graduated in CS from a T3, had years of experience, and starting med school next month).

I did Ruby since 2011, and tried Elixir in December 2019. I really hated the verbose syntax compared to Ruby, which has a comparatively simple syntax. The next thing I hated in Elixir was the boiler plate for GenServers and having to deal with pids and named processes. However, this weekend, I rewrote about 2k lines of sloppy elixir that I hastily copy pasted, and condensed it down to around 700-800 lines in a few hours with barely any effort. It was easy because it's just functions calling functions. I guess I'm kind of a believer now. Besides that, Phoenix channels are very performant, which makes me think I might switch from Ruby to Phoenix permanently.

Try sticking through it.

Post reply on HN