Nice writeup! ZeroMQ is not written in Erlang. You probably confused with RabbitMQ, which is.
Comparing Elixir and Go
41–50 of 202 posts
Re: Comparing Elixir and Go
#42I think a good way to increase creativity and productivity is to use the right abstractions of thought and craft.
Every good(non leaky) abstraction expands the creative envelope further and lends itself to creation of new higher order abstractions for the next generation.
Having coded in imperative languages like Java, Python and C++, I had been on the lookout for a practical general purpose language which provides good abstractions/high expressiveness. Elixir appealed to me more than Go in that regard. It's been six months since I started writing Elixir and it's been a pleasure.
Re: Comparing Elixir and Go
#43> 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…
There has been nice study by Motorola exactly on this topic C++ vs. Erlang implementing telecom software. Study slides are online at http://www.slideshare.net/Arbow/comparing-cpp-and-erlang-for...
Interesting result from this study - erlang implementation is not only more robust but also faster.
Re: Comparing Elixir and Go
#44Earlier quoted context omitted.
Remember any specific examples/patterns? Curious to see how bad it could be...
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.
Re: Comparing Elixir and Go
#45I 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.
Re: Comparing Elixir and Go
#46Earlier 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.
> Many of these issues you list can be overcome by good coding practise.
The enterprise is not the space for it, specially among companies whose bread and butter is not to sell software.
The only measures of quality management cares about, are "does it work" and "delivers what customers pay for", anything else are just costs that need cutting.
Re: Comparing Elixir and Go
#47I 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 function have to process at least n items? Or it uses parallel processing to get a speedup there?
Re: Comparing Elixir and Go
#48This 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 similar idea to a rope: https://en.wikipedia.org/wiki/Rope_(data_structure)
Re: Comparing Elixir and Go
#49I 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.
Re: Comparing Elixir and Go
#50I 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 I create an immutable string "hello world" why would it be passed by copy; it can never be changed only garbage collected.
The BEAM seems to do magic here and do much less work than you might think when creating "new" things.