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

Comparing Elixir and Go

blog.codeship.com

Post reply on HN
Print view View original

51–60 of 202 posts

Re: Comparing Elixir and Go

#51

Post by jondubois »

fetbaffe wrote: post #49
cryptica wrote: post #45

I still don't understand what all the hype is about pure functional programming. Sometimes mutations are useful. There are lot of good programming design patterns which depend on mutations. Also, always copying objects by value every time you call a function seems very expensive; especially if you're dealing with very large objects/structs/maps/strings which have to be processed by many functions.

You only need to copy the data if the consumer of the data changes it, i.e. copy-on-write.

That sounds a bit better than I thought but it still doesn't change the worst-case complexity.

Re: Comparing Elixir and Go

#52

Post by yxhuvud »

sudhirj wrote: post #28
andyfleming wrote: post #4

How does Crystal lang compare to the two? I know the syntax is more similar to Elixir, but the format seems closer to Go in the sense that it compiles to a binary.

Swift would be a better comparison - both Crystal and Swift are general purpose languages that compile via LLVM. Neither has any special story for concurrency (yet). Go and Elixir/Erlang on the other hand, change your approach to programming.

What are you talking about? Crystal has a concurrency solution in their Channel implementation. They are not yet running in parallel, but it most definitely implement concurrency.

Or in other words, it is very inspired by the Go concurrency solution.

Re: Comparing Elixir and Go

#53

Post by andy_ppp »

wuschel wrote: post #44
pjmlp wrote: post #34

Earlier quoted context omitted.

Basically: - Code either "C code compiled with C++ compiler" or C++ OOP Spaghetti like in the CORBA/DCOM days before JEE was a thing. - functions/methods that span several screens - barely any kind of testing - due to emphasis on C style programming, lots of fun tracking down pointer misuses - re-implementation of code that is already part of C++ standard library, even the ones from C - lots of copy-paste on the same…

Many of these issues you list can be overcome by good coding practise. Although I understand that the framework/languages used allowed for these bad feats. I wonder how Rust with its focus on memory safety could play out in such scenarios. I need to have a look at Erlang/OTP. It is a bit of a hidden, alien gem.

Ha the borrowing checker as a barrier to bad coders! I like it ;-)

Re: Comparing Elixir and Go

#54

Post by fetbaffe »

jondubois wrote: post #51
fetbaffe wrote: post #49

Earlier quoted context omitted.

You only need to copy the data if the consumer of the data changes it, i.e. copy-on-write.

That sounds a bit better than I thought but it still doesn't change the worst-case complexity.

Depends on the scenario, if you know a value never changes, you can share that between variables under the hood, as the article explains with the example about sorting arrays.

Passing around complex mutable structures feels more like procedural programs.

Re: Comparing Elixir and Go

#55

Post by keymone »

IanCal wrote: post #40

This is more for people looking at erlang/elixir than a critique of the blogpost or a suggestion for a change. > Within Elixir, there is no operator overloading, which can seem confusing at first if you want to use a + to concatenate two strings. In Elixir you would use instead. When this popped up, it reminded me of something people try to do often and then have issues with performance. You probably do not want to c…

This is a great advice.

Erlang was the first functional language i really learned and i can definitely attest to the pains mainstream developers go through when switching the paradigm. In fact with Erlang you're jumping two paradigms at once - functional/immutable and actor model of concurrency.

Eventually it clicked and i think learning Erlang was single most impactful thing on my way to becoming "a better developer".

Throw away your best practices of procedural/oop world and unlearn your optimization tricks when diving into functional/immutable. It's a totally different way of thinking about problems.

Re: Comparing Elixir and Go

#56

Post by danielnesbitt »

cryptica wrote: post #45

I still don't understand what all the hype is about pure functional programming. Sometimes mutations are useful. There are lot of good programming design patterns which depend on mutations. Also, always copying objects by value every time you call a function seems very expensive; especially if you're dealing with very large objects/structs/maps/strings which have to be processed by many functions.

Pure functional languages often do not use the same data structures common in imperative languages. Instead there's an emphasis on persistent structures that copy on write while sharing as much data as possible.

For instance, prepending to a linked list results in a new head node, but nothing is actually copied. Appending requires a full copy. A developer has to be aware of where the limitations of these data structures are, but I think that's true of using any library in any language.

https://en.wikipedia.org/wiki/Persistent_data_structure

Re: Comparing Elixir and Go

#57

Post by Ralfp »

pjmlp wrote: post #30
timClicks wrote: post #23

Earlier quoted context omitted.

Pretty significant detail though, as no one has done either.. also "anyone" is fairly strong, building decent compilers and interpreters is pretty difficult

Anyone with a decent CS degree should be able to produce working compilers and interpreters, otherwise it wasn't a decent degree. Of course, writing very good ones is a different matter.

You are now commiting the moving the goalpost fallacy, arguing first that something is irrevelant because it may be changed larter, and then moving on to argue that every CS degree guy could just write it.

Re: Comparing Elixir and Go

#58

Post by coldtea »

IanCal wrote: post #40

This is more for people looking at erlang/elixir than a critique of the blogpost or a suggestion for a change. > Within Elixir, there is no operator overloading, which can seem confusing at first if you want to use a + to concatenate two strings. In Elixir you would use instead. When this popped up, it reminded me of something people try to do often and then have issues with performance. You probably do not want to c…

>Now it's going to have to construct each string, then create a new string with all three. More creation & copying means things get slower.

There's nothing about the ++ syntax that makes it necessarily so. The compiler/interpreter could understand that we're getting a concatenated string and automatically only create one.

Which is the case in several languages.

Re: Comparing Elixir and Go

#59

Post by jordwest »

cryptica wrote: post #45

I still don't understand what all the hype is about pure functional programming. Sometimes mutations are useful. There are lot of good programming design patterns which depend on mutations. Also, always copying objects by value every time you call a function seems very expensive; especially if you're dealing with very large objects/structs/maps/strings which have to be processed by many functions.

This is something I think Rust solves very nicely.

The ownership model gives the benefits of immutability (no shared mutable state and race conditions) without the need to copy most of the time.

Re: Comparing Elixir and Go

#60

Post by coldtea »

pjmlp wrote: post #30
timClicks wrote: post #23

Earlier quoted context omitted.

Pretty significant detail though, as no one has done either.. also "anyone" is fairly strong, building decent compilers and interpreters is pretty difficult

Anyone with a decent CS degree should be able to produce working compilers and interpreters, otherwise it wasn't a decent degree. Of course, writing very good ones is a different matter.

>Anyone with a decent CS degree should be able to produce working compilers and interpreters, otherwise it wasn't a decent degree.

Which would be useless for production without several years of maturity, a tools ecosystem, and a community adopting them -- and of course continued support.

So this is mostly theoretical.

Post reply on HN