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

61–70 of 202 posts

Re: Comparing Elixir and Go

#61

Post by filmor »

coldtea wrote: post #58
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.

What is different in Erlang is that strings are a bit messed up in that they are linked lists of numbers. What you are suggesting (constructing the actual string in-place) works fine in Erlang, too, but has a bit of a funky syntax:

    welcome_user(Username) ->
        >/binary, Username/binary, >/binary >>.
However, the main advantage of using io_lists instead is that `["Welcome", Username, "!"]` has constant complexity with regard to the length of `Username`.

Re: Comparing Elixir and Go

#62

Post by IanCal »

coldtea wrote: post #58
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.

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.

Re: Comparing Elixir and Go

#63

Post by digitalzombie »

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.

Erlang isn't purely functional... the time function is an example. To be pure, iirc, a function call have to return the same result everytime, there's a one to one mapping for each parameter there's a unique value. time() is an arity 0 (no parameters) and yet it return different value every time you call it depending on the time currently.

You can mutate by making a new copy, you modify the old one and save it to a new variable. The old variable is unchanged.

If you set x You can also keep state by passing an accumulator via function parameter, it's also how you to tail call optimization. It's a weird pattern and I haven't use functional paradigm enough to give one on top of my head.

Re: Comparing Elixir and Go

#64

Post by owaislone »

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.

Re: Comparing Elixir and Go

#65

Post by nazri1 »

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.

Re: Comparing Elixir and Go

#66

Post by owaislone »

jondubois wrote: post #47
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.

I just had a thought; if arguments always get cloned by value every time they are passed to a function, doesn't that mean that the time complexity for an insertion operation in Elixir can never be better than O(n)? According to this answer http://stackoverflow.com/questions/11055391/time-complexity-... it claims that for dictionaries it's O(log n). How is that possible if mutations are not allowed? Wouldn't the funct…

If you are only dealing with Immutable structures that no one can really change, there is no point in passing by value. You can always pass by reference. The language will not allow any code to modify it. Instead a new variable will have to be assigned if the function changes the values. So, it can always be pass by reference until a change needs to be made aka copy on write.

Re: Comparing Elixir and Go

#67

Post by IanCal »

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.

> I need to have a look at Erlang/OTP. It is a bit of a hidden, alien gem.

I'd recommend it. I think even in the worst case, it's interesting and can change how you approach problems in other languages.

In the best case, it'll fit some problem you have suspiciously well and you'll be left wondering why it only took you a couple of days, a tutorial and 50 lines of easy to understand code to solve a really annoying problem you had.

If some of the syntax or tooling feels like it's getting in your way, Elixir looks like a nice setup on top. Personally I think erlang is fine as it is, though I do want to experiment with Elixir.

Re: Comparing Elixir and Go

#68

Post by eternalban »

giovannibajo1 wrote: post #39

I think the part about cooperative/preemptive multitasking isn't saying it all. Go multitasking is based on the compiler inserting switchpoints on function calls and syscall boundaries. But this affects the scheduling of a single OS-level threads executing that specific goroutine. The number of OS-level threads that the Go scheduler uses can arbitrarily grow, and OS-level threads are preemptively multitasked. So I th…

> I think the part about cooperative/preemptive multitasking isn't saying it all.

That's still not the entire story:

GC & tight loops in Go: https://github.com/golang/go/issues/10958

Per process vs per runtime GC: https://news.ycombinator.com/item?id=12043088

Re: Comparing Elixir and Go

#69

Post by eternalban »

kjksf wrote: post #8
EduardoBautista wrote: post #2

> It has since expanded into numerous other areas, such as web servers, and has achieved nine 9s of availability (31 milliseconds/year of downtime). I definitely want to read more about this.

This is how myths are created and perpetuated. This claims from a study of a particular model of Ericsson's ATM switch whose software was written in Erlang. A can tell you for sure that: * Ericsson has other switches and other telecom equipment whose software is written in C++ * other companies (Nokia, Cisco, Alcatel etc.) also built similar complex telecom equipment whose software was in C++ I'm going to bet that at…

Not disagreeing with you, just adding a bit more info. I'm nearly sure that the fault-tolerance magic of Erlang happens at the library (OTP) level with supervisors.

Re: Comparing Elixir and Go

#70

Post by pjmlp »

andy_ppp wrote: post #53
wuschel wrote: post #44

Earlier quoted context omitted.

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

It is.

Just like the type systems from Algol family of languages.

Every time a language outsources safety to an external tool, the majority of developers and their employers don't care about it.

Had lint been part of the compiler, like clang did it, instead of external tool, C code would have been much safer than it ended up becoming.

Post reply on HN