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

71–80 of 202 posts

Re: Comparing Elixir and Go

#71

Post by tormeh »

owaislone wrote: post #64
maxpert wrote: post #17

I think it's comparing apples with oranges. They are two different species a compiled vs VM based language, one is a functional styled vs other has duck-tapping. Only thing I can see common is GC and a somewhat but very different concurrency programming paradigms, with message passing. Erlang and BEAM is an aged old giant with battle tested proven reliability, while golang is young lad with the flash like abilities e…

I think it's a fare comparison. Much more than Rust vs Go which we see all the time. Technically, Rust and Go are more similar to each other than Go and Elixir but Rust and Go are intended for different areas. Go and Elixir on the other hand will compete directly as both have been built to write exactly same kind of software.

Hoare (Go) concurrency is for concurrency within one computer - actor (Elixir) concurrency scales over many computers. This is because actor concurrency is compatible with the realities of networking, and most actor implementations (scala, Erlang/Elixir) provide network transparency.

Re: Comparing Elixir and Go

#72

Post by coldtea »

IanCal wrote: post #62
coldtea wrote: post #58

Earlier quoted context omitted.

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

This could be true in some restricted cases, but can't be in general. If the username came from the database, it's going to be stored in memory before this function is called, and so concatenating must require building a new string.

It can require building a new string. But what is argued is that it wont require building several new strings incrementally for each concatenation.

E.g. no:

A + B + C + D -> AB + C + D -> ABC + D -> ABCD

And for immutable strings, it might not even require to build a new string at all, even if the string is in memory: it can just use a string data structure pointing to the various parts.

(

Re: Comparing Elixir and Go

#73

Post by esra »

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…

Just be aware that there are libraries that don't work with io lists, like erlang's http client httpc, in that case you need to flatten the io list.

Re: Comparing Elixir and Go

#75

Post by brightball »

sudhirj wrote: post #31

> The biggest difference between the two languages is that compilation for the destination architecture has to be done on that same architecture. The documents include several workarounds for this scenario, but the simplest method is to build your release within a Docker container that has the destination architecture. @brightball Go has had first class support for cross compilation for a while now, no?

I need to clarify that I was talking about that being an Elixir limitation. The previous paragraph talks about Go being able to cross compile no matter what system it's on but the one you highlighted still doesn't read well.

Re: Comparing Elixir and Go

#76

Post by manualwise »

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.

This article has some performance comparisons between Crystal and Elixir in the comments: https://blog.codeship.com/an-introduction-to-crystal-fast-as...

Re: Comparing Elixir and Go

#77

Post by manualwise »

nazri1 wrote: post #65

The page (like many other pages nowadays) breaks page down - if I press the page down key I then have to scroll up a few lines because the text are obscured by the always-visible "FREE SIGNUP" banner at the top.

I'm responsible for this blog. Thanks for the feedback, we'll work on getting this fixed!

Re: Comparing Elixir and Go

#78

Post by [deleted] »

sudhirj wrote: post #31

> The biggest difference between the two languages is that compilation for the destination architecture has to be done on that same architecture. The documents include several workarounds for this scenario, but the simplest method is to build your release within a Docker container that has the destination architecture. @brightball Go has had first class support for cross compilation for a while now, no?

[deleted]

Re: Comparing Elixir and Go

#79

Post by brightball »

julio83 wrote: post #29

The other trade-off that comes from mutable versus immutable data comes from clustering. With Go, you have the ability to make remote procedure calls very seamlessly if you want to implement them, but because of pointers and shared memory, if you call a method on another box with an argument that references to something on your machine, it can’t be expected to function the same way. I would be happy to know how we ca…

I might need to rework that sentence. I was trying to say that clustering can only be seamless with immutable data and that, while Go has great RPC support built in that it won't ever be able to cluster naturally.

Re: Comparing Elixir and Go

#80

Post by pjmlp »

Ralfp wrote: post #57
pjmlp wrote: post #30

Earlier quoted context omitted.

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.

I wrote my first compiler using Turbo Pascal for MS-DOS at the age of 17, before getting into the university.

A CS degree just makes it easier.

Post reply on HN