Hacker News Reader

Comment by thedance | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

I tell people Elixir is just pretty Erlang.

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?

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.

Erlang is a stable language that has been around for a long time (almost 35 years now). It's used for way more mission-critical code than golang is ever likely to be used for. It's weird syntax and performance tradeoffs are very well known, but you still won't see anywhere near the number of complaints that you see against golang.

Erlang is less and less used in telecoms and it's the only place if was really used, lot of things have switch to C/C++/Java.

As for the reason why it has less complains it's pretty simple no one uses Erlang and it's a niche, it's not a generic purpose language. I can't even tell a single known application or library written in Erlang.

Ah yes. Whoever's heard of Whatsapp, Pinterest, Discord, and Goldman Sachs? https://codesync.global/media/successful-companies-using-eli...

IBM Cloudant runs everything CouchDB which is written in Erlang as does Amazon for SimpleDB. WhatsApp and a bunch of Pinterest are written in Erlang (they may actually be in Elixir, but on BEAM).

To my knowledge Ericsson still writes most things in Erlang. Yahoo uses it for a couple large services. My company use PagerDuty which is also written on BEAM.

I'm sure there are many, many other things in not familiar with, but claims of Erlang's demise are greatly exaggerated.

Erlang is mainly used in the control plane at Ericsson -- you'd never write a DSP in it for example. Most code is sadly not Erlang.

Just like Go only matters mostly to Docker and K8s shops.

ejabberd is one that I had installed at some point.

If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go. What you see on the internet is the union of everyone's complaints and frustrations. Each individual sees only some of those, maybe even none depending on the type of work they're doing. And the ones that are generally happy don't tend to post big rants, so the overall impression of an outsider can be pretty skewed.

> If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go.

That's bullshit. When I worked in the Ruby on Rails space, I saw critisms quite often... for example of the "one size fits all" way-too-large-surface-area library design (see: ActiveSupport) or the "fat model" design trend at the time... I even PRODUCED some of these criticisms myself. Heck, the bug that made me leave the space took a month to track down and had to do with nondeterminate behavior when merging a Hash with a HashWithIndifferentAccess (this was not my code, I would have not written it the way it was written, but it was a bug I was assigned to of someone else's code) because the Ruby language did not see these as two distinct "types" and simply went ahead as if they were both regular Hashes, which caused HWIA keys to get overwritten unexpectedly/nondeterministically... that was the last straw at the time.

And when I worked in .NET/ASP prior to that, I saw (and witnessed) MANY criticisms of the language and API such as how easy it was to produce difficult-to-test spaghetti code.

And while all this was happening I was also working on frontend code in JS and needless to say there have been A LOT of JS criticisms over the years and I've seen most of them.

So yeah, maybe try again with less BS. The biggest criticism I can produce of Elixir (and more generally the BEAM VM) is that too few people understand its advantages and too many people actively misinform others about it. (OK, one more criticism, but it is a more general criticism of functional immutable languages: A handful of algorithms perform suboptimally in a language that does not even permit mutation, relative to a language that does.)

I think you might be reading an unintended meaning into that sentence. I'm talking about the experience of using Go vs. what people write about it, not about your experiences with other languages (which I have no intention of invalidating). I was pointing out that sometimes one can get a skewed perspective of the typical experience by reading blog posts and things (which by definition are written by the more vocal members of a community).

I did use Go professionally for about five years, and read lots of criticisms of it (and still do out of curiosity). Most of them struck me as just not a big deal in practice. When I had to write some list-processing code that could be greatly simplified with generics (a few times per year), I just sighed and typed it out and moved on to a more interesting thing. When I had some repetitive error-handling code, I refactored it or wrote some helper functions. The dependency stuff was annoying when starting a new project, but once you pick a dependency manager/vendoring tool it's fairly straightforward (and of course now this is included).

Certainly, the language and ecosystem has warts and frustrating things. Maybe Elixir has fewer warts, I don't know. But overall the experience of using Go is fairly smooth and boring and productive. The things that people like to complain about don't really register in day-to-day usage. That's not BS, that's my personal experience.

Well, you might have the Stockholm syndrome. :D But yeah, we all have to deal with some idiosyncrasies with our languages/tools of choice. It’s inevitable.

For the record, I really love Elixir but it’s quite easy to swallow/ignore errors there as well. (To translate one of the Go’s criticisms.)

So I get what you’re saying. But IMO the outsiders’ perspective is valuable because it outlines stuff we have gotten used to, and they might not be willing to do that.

So such criticisms might be minor for you and me but they add much-needed nuance in the long run, I believe.

Fair enough.

And truth be told, a lot of the issues I encountered in the languages I mentioned were from other people’s flawed code designs, not my own.

I've been using Go for years. It works, but it's mostly despite bad design issues and because of network effects/money+time put into the project. Not impressive at all.

You can find rants on any language because nothing can ever be perfect. Everything has pros and cons. https://yourlanguagesucks.com

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

heh. someone hasnt used a monad.

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.

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

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.

Reply on news.ycombinator.com