7 ms·

There aren't any abstractions in any language or library that don't leak everything about what they are trying to hide as well as everything about their own imp

There aren't any abstractions in any language or library that don't leak everything about what they are trying to hide as well as everything about their own implementation. That's just life. It's impossible to hide complexity. Whatever wraps one thing will be strictly more complex than the wrapped thing was.

whateveracct 7y ago
This just isn't true! Haskell's json/sql marshalling do not use runtime reflection but instead ad hoc polymorphism, so when I create (or even derive automatically!) a marshalling instance, it is pretty easy for me to reason about what will happen statically. Haskell's Generic & newtype-deriving go a long way here, and are good examples of principled abstractions that do not leak. Haskell's conduit (and other streaming libraries) is another good example. I use them to create programs that process things in constant memory, and when I compose them (e.g. with operators like =$= or .| in conduit), the resulting program streams in constant memory. I have built entire systems (CLIs, batch jobs, event processors, etc) on top of this abstraction and conduit itself has never leaked.
- wronghorse 7y ago
  I believe Rust's serde library is similar when it comes to JSON. It also gives you the option to choose how strictly you want to enforce the types.
pmarreck 7y ago
This is funny because after almost 4 years of working with Elixir and watching Go from arms’ length, I literally see NONE of the criticisms regularly leveled at Go. This is not an exaggeration. In fact, Elixir has few criticisms at all to begin with, and it’s driven very large sites already at this point. (Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.) Not intending to start a language war, but your argument is basically the beaten wife claiming this is just standard treatment from husbands. This is my counterexample.
- anthony_doan 7y ago
  Elixir is a fantastic and small language. Jose Valim kept it reasonable. It just have so much depth with concurrency. The actor model is amazing and easy to think about too. I'm not entirely sure they overlap completely but the concurrency model is superb. I will probably only use Elixir for web application from now on (unless they don't have packages for certain API). Chris have made web development possible and many awesome people have contributed (POW package is just lovely).
  - swat535 7y ago
    Elixir is Erlang anyway. The only difference between the two is basically syntax and a couple of bonuses in the Elixir STDLib, most of which wraps existing Erlang functions. You're praising Erlang's concurrency model, there's no such thing as Elixir concurrency model.
    - PopeDotNinja 7y ago
      I tell people Elixir is just pretty Erlang.
    - anthony_doan 7y ago
      Yeah I understand that but not many people do Erlang from Elixir from my experiences. Also I find Elixir community is better for me as a web developer than Erlang. But it's also inescapable to ignore Erlang when you dive deeper into the actor model. Several good actor model books are Erlang only. Unfortunately many people, including myself, ever actually do anything hardcore with Actor Model. There is a good blog post about several skill stages of erlang/elxir and OTP was at the very top in term of few people actually uses it. I can't recall it the author =/. Actually, I like Elixir package management system and command line tool is much better. They recently have the release command line tool. Elixir have several more differences?
- Thaxll 7y ago
  The reason is because Go is very popular where Elixir is not, if Elixir was standing where Go is now it would be pretty much the same, I guaranty you that.
voldacar 7y ago
heh. someone hasnt used a monad.
- rictic 7y ago
  There is no way to avoid leaking implementation details, it's just a matter of how much you leak. Even monads leak their performance characteristics.
  - whateveracct 7y ago
    *sometimes and not always State, for example, doesn't leak. You never worry about the fact that it's a function `s -> (s, a)` and it gets optimized away like nuts.
    - rictic 7y ago
      This is an example in favor of the fact that abstractions can't paper over performance characteristics. Users may depend on them. In the unlikely event that there was a change to the implementation of the State monad, or to one's compiler, such that the State monad was not optimized away, it would be disruptive to users. It would probably be treated as a bug, even if the only change in behavior was in additional CPU and memory usage. This is a corollary of Hyrum's Law.
OceanSpray 7y ago
"It's impossible to reach absolute zero, so it's also impossible to drink chilled beverages."

whateveracct 7y ago

This just isn't true! Haskell's json/sql marshalling do not use runtime reflection but instead ad hoc polymorphism, so when I create (or even derive automatically!) a marshalling instance, it is pretty easy for me to reason about what will happen statically. Haskell's Generic & newtype-deriving go a long way here, and are good examples of principled abstractions that do not leak. Haskell's conduit (and other streaming libraries) is another good example. I use them to create programs that process things in constant memory, and when I compose them (e.g. with operators like =$= or .| in conduit), the resulting program streams in constant memory. I have built entire systems (CLIs, batch jobs, event processors, etc) on top of this abstraction and conduit itself has never leaked.

wronghorse 7y ago
I believe Rust's serde library is similar when it comes to JSON. It also gives you the option to choose how strictly you want to enforce the types.

pmarreck 7y ago

This is funny because after almost 4 years of working with Elixir and watching Go from arms’ length, I literally see NONE of the criticisms regularly leveled at Go. This is not an exaggeration. In fact, Elixir has few criticisms at all to begin with, and it’s driven very large sites already at this point. (Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.) Not intending to start a language war, but your argument is basically the beaten wife claiming this is just standard treatment from husbands. This is my counterexample.

anthony_doan 7y ago
Elixir is a fantastic and small language. Jose Valim kept it reasonable. It just have so much depth with concurrency. The actor model is amazing and easy to think about too. I'm not entirely sure they overlap completely but the concurrency model is superb. I will probably only use Elixir for web application from now on (unless they don't have packages for certain API). Chris have made web development possible and many awesome people have contributed (POW package is just lovely).
- swat535 7y ago
  Elixir is Erlang anyway. The only difference between the two is basically syntax and a couple of bonuses in the Elixir STDLib, most of which wraps existing Erlang functions. You're praising Erlang's concurrency model, there's no such thing as Elixir concurrency model.
  - PopeDotNinja 7y ago
    I tell people Elixir is just pretty Erlang.
  - anthony_doan 7y ago
    Yeah I understand that but not many people do Erlang from Elixir from my experiences. Also I find Elixir community is better for me as a web developer than Erlang. But it's also inescapable to ignore Erlang when you dive deeper into the actor model. Several good actor model books are Erlang only. Unfortunately many people, including myself, ever actually do anything hardcore with Actor Model. There is a good blog post about several skill stages of erlang/elxir and OTP was at the very top in term of few people actually uses it. I can't recall it the author =/. Actually, I like Elixir package management system and command line tool is much better. They recently have the release command line tool. Elixir have several more differences?
Thaxll 7y ago
The reason is because Go is very popular where Elixir is not, if Elixir was standing where Go is now it would be pretty much the same, I guaranty you that.

voldacar 7y ago

heh. someone hasnt used a monad.

rictic 7y ago
There is no way to avoid leaking implementation details, it's just a matter of how much you leak. Even monads leak their performance characteristics.
- whateveracct 7y ago
  *sometimes and not always State, for example, doesn't leak. You never worry about the fact that it's a function `s -> (s, a)` and it gets optimized away like nuts.
  - rictic 7y ago
    This is an example in favor of the fact that abstractions can't paper over performance characteristics. Users may depend on them. In the unlikely event that there was a change to the implementation of the State monad, or to one's compiler, such that the State monad was not optimized away, it would be disruptive to users. It would probably be treated as a bug, even if the only change in behavior was in additional CPU and memory usage. This is a corollary of Hyrum's Law.

OceanSpray 7y ago

"It's impossible to reach absolute zero, so it's also impossible to drink chilled beverages."