Wrocloverb 2017: Elixir vs Ruby - unanswered questions

s promised in the last blog post - I am trying to answer some of the questions that were asked by the Ruby community during the ‘Wrocloverb 2017’ conference, and we’re supposed to be asked during the ‘Ruby vs Elixir’ discussion panel. Sadly the panel was too short to have all the questions answered.

Wrocloverb 2017: Ruby vs Elixir discussion panel (unanswered questions)

Q: Is it a good time to make a jump from Ruby to Elixir?

A: It is definitely a great time to make yourself more familiar with one of functional languages. With more and more cores packed into a single chip it becomes important to run tasks in parallel, and this is much easier to achieve when there is no shared state.
As for the Elixir itself - recently a new version of Elixir has been shipped (1.4) and the language itself seems to be mature. Community is growing, there are companies hiring people who know Elixir - all that to me is a sign that yes, it is a good time to make a jump into Elixir.

Q: What could be the negative consequences of switching from Ruby to Elixir? ;)

A: It may happen that similarly to others you will end up switching to Elixir for good - bad that’s not necessarily a bad thing, right? :-)

You may lack some of the tooling or gems you’re used to. Elixir + Phoenix is not as mature as RoR, so not that many packages are available. Community is smaller. You may not find exact replacement for some of the gems, or what you’ll find will not cover all the use cases. It may take you some time to be productive with Phoenix and delivering your first Elixir+Phoenix app could take more than doing the same in RoR - but that’s only due to the fact that it is going to be brand new to you, the same would be true if you wanted to switch from Elixir + Phoenix to RoR.

Q: When refactoring existing RoR app to Elixir, which part of the app would you recommend to start with?

A: The question is why refactor working app? If this is due to performance related problems - the obvious is that what is bottleneck should be refactored first.

But rewriting whole application using different platform is always a big task. To properly utilize Elixir’s advantages it could be important to rethink how things work and rearchitect some parts of the application. This is especially important if we want to achieve higher level of fault tolerance.

Sadly, there is no silver bullet for that, as each application is different and each app has unique set of its own problems.

Q: What would be the good and bad use case for using mnesia?

Mnesia faq should help: http://erlang.org/faq/mnesia.html if you decide to go with mnesia you could be interested in ‘amnesia’ a mnesia wrapper for Elixir: https://github.com/meh/amnesia

Q: What projects is Elixir good for?

A: If you need scaling, fault tolerance - Elixir is a good fit. The types of projects that could benefit from Elixir are:

  • web servers
  • backends (servers) of different kind, especially if the whole system is designed as distributed
  • chat server backends (LiveChat or WhatsApp are great examples how well these technologies fit)
  • all the systems that require extra stability / fault tolerance

A: Yes, Erlang’s virtual machine is running garbage collector but it works differently than the one you will find in JVM or. Net. First of all - Erlang applications may have very many (literally thousands) of heaps. All those heaps are being garbage collected independently. You may find more info on that under the following link: http://evanmiller.org/why-i-program-in-erlang.html

Q: Are there any good libraries for interacting with relational databases? (if so - which would you suggest?)

I may suggest to use Ecto (https://github.com/elixir-ecto/ecto) created by Plataformatec (the company that Jose Valim - creator of Elixir - works for).

If ecto doesn’t seem like a good choice for yourself - try one of the libraries listed in the ‘ORM and datamapping’ section under the awesome Elixir repository: https://github.com/h4cc/awesome-elixir/

Q: Why Elixir is “sold” to us as “new better Ruby” while its underlying principles are totally different? Won’t it result in Elixir programmers that do not understand Elixir (like Rails programmers that do not know Ruby)?

A: Elixir is not a better Ruby. The only thing that these two languages share to some extent is syntax. Please mind that even in this area there are significant differences. Elixir us functional programming language, while Ruby is not. That is a huge thing, and has enormous impact on how applications are developed.

Elixir + Phoenix is not even remotely similar to the relation of Rails and Ruby. It is not something uncommon that even technical people say ‘Ruby application’ while they actually think of RoR application. Rails is extremely important for the Ruby world, and I will risk the thesis that without Rails (or similar framework) Ruby would be nowhere near as popular as it is right now.
Ruby’s niche is web application development. Period. Yes, it is used sometimes as purely scripting language (OpenSuse’s YaST), there are also libraries which allow crating desktop apps using Ruby, but those are not areas in which Ruby shines and is popular.

Elixir is a whole lot different story. Elixir is not that specialized as Ruby. Apart from being most frequently used for backend development, there is no special niche that is most suitable for Elixir (which is a bit different for Ruby as Rails and web application development is extremely important in Ruby world). The only good advice is: if you are planning to write a server of any type - Elixir could be a great fit for that (even though it doesn’t necessarily has to be a web server).

Unfortunately there is a sad trend of not knowing good enough the technology that one uses - but that’s no specific to Rails or any other technology. Some frontend developers don’t know Javascript well enough.

Q: Are there any hardware-interaction Elixir libs or patterns that would potentially open a path for Elixir to IoT world - wouldn’t rails be better for a deployment on a smart watch?:)

A: one of the projects aiming at the IoT area / embedded systems is nerves: http://nerves-project.org/ - have a look at the introductory video into nerves from Elixir Daze conference: https://m.youtube.com/watch?index=8&list=PLE7tQUdRKcyZV6tCYvrBLOGoyxUf7s9RT&v=TjlbXQ88eEc

There is a 2-part article on building IoT using Elixir:

Of course Elixir - due to the way it can handle large number of incoming connections - is an excellent choice if you plan to build the server part for the IoT solution.

Q: Is there a huge difference between tools available for Elixir and Ruby (IDEs, plugins, etc.)?

A: I would say that Elixir has almost as good support as Ruby. There are plug-ins for Atom, Visual Studio Code, Vim, Emacs, IntelliJ - and these are only the editors / IDEs that I’be tried on my own.

There are a lot less packages available. Same as some tools (but on the other hand Erlang / Elixir offer some unique tooling that is not available for any other platform / language).

Don’t be afraid, Elixir is us not a language which appeared 6 months ago. It is suitable for production ready systems.

Q: Should new comers start with Elixir or Ruby? As most of the talk today that happens is about scaleable, high throughput web apps. Is scaling relevant to everyone?

A: You forgot about fault tolerance :-)
No, not everyone needs scaling. That’s true. But it is also true that you don’t have to design application in such a way that it becomes fault tolerant and scalable. It doesn’t come for free with Elixir. If you don’t need it - you don’t have to overcomplicate things. You could built simple web application using Elixir + Phoenix as well as using Ruby on Rails.

The last difference would be functional programming vs OOP. Some say that fp is harder to learn than OOP. That is not necessarily true. Have a look at http://haskellbook.org - this book has been co-authored by person who was taught Haskell as her first programming language. What’s more - she has started teaching Haskell her 10 year old son :-)

So back to the question - I think that it is the best moment to get submerged in the world of functional programming, and Elixir is one of the most interesting languages (with very bright future when it comes to jobs availability) to be used for learning fp. Go get it, and start some fun using it!

Q: What applications or common problems are not good fit for Elixir? So if we have multiple micro-services should be kept in Ruby?

A: Even though Elixir is a general purpose programming language it is not the best fit for every type of application.

I am not sure how well would it perform on extremely small devices, devices having only 16KB of memory and a very weak cpu. On the other hand Elixir plays well on RaspberryPi, BeagleBone and Chip (the “world’s first $9 computer” - as it is advertised).

One of the field that is not the Elixir niche is game programming. The other would be numerical computations - why compete with R or Python - both languages are de facto standards for data scientists. I wouldn’t Recommend Elixir / Erlang to cope with CPU intensive tasks such as number crunching which may require a lot of processing power.

Elixir could be used instead of Python for system scripting, but I don’t think it is a good idea. Python is usually part of every Linux distribution, and Erlang and Elixir are not…

I am not sure how well Elixir copes with desktop application programming, but I would probably go with something else.

I wouldn’t use Elixir to write some system extensions (kernel modules, drivers etc).

Q: Is Phoenix going into Rails direction and will it suck in like 5 years?

A: Hard to predict what happens in 5 years time. Big percentage of converts to Elixir have background in Rails - it is possible that Phoenix will not be shaped as ‘Rails for Elixir’ but rather a framework that is just inspired by Rails. That is actually happening right now in the Elixir community. Instead of just copying solutions z community is trying to find the best approach for solving particular problems.

Neither Elixir nor Phoenix are perfect. I am sure than in 5 years time there will be some things to argue about, I am sure there will be approach to create another framework that would be considered alternative for Phoenix. Thesw are all things that will happen for sure. I just hope there will be very few people saying that ‘Phoenix sucks’.

Q: What are the bad parts of Erlang / Elixir?

A: It is going to be się making different for each and every developer. For me personally there are couple of things that I could call disadvantages:

  • raw processing speed - if you’re in need for CPU cycles you will probably have to think of some other language (Rust?)
  • Elixir NIF (Native Implemented Function) these are usually written in pure C and consumable from within Elixir. Everything would be cool if not the fact that poorly implemented NIF could bring the whole Erlang / Elixir virtual machine down. This could be pretty surprising for someone who learnt that in Erlang / Elixir processes could be ‘resurrected’ thanks to supervisors, so failing process should not be a problem.
  • Erlang is very mature, but Elixir is still quite young, and that means there are not as many libraries as for example NodeJS packages, Python eggs or Ruby gems.
Q: How many of your past projects would fit more to use elixir instead of ruby?

A: I had a chance to write software for the biggest companies operating in the financial area. I am pretty much sure that couple of systems I have helped to create could greatly benefit from rewriting in Elixir.

At some point of my career I had a task to design an architecture and develop a game server. At that time I have decide to use Python + Tornado, but today I would probably go with Elixir.

The RoR apps I have created were quite simple and didn’t have any sophisticated requirements. I could rewrite them in Elixir but without any architectural changes there would be no gain from that. If I was already an Elixir + Phoenix expert I would probably choose Elixir anyway, I even for the very simple, classic web applications. Why? Why not? :-) there is no disadvantage of choosing Elixir - no extra appetite for resources etc.

Only one drawback could be with hosting - RoR is by far more popular than Elixir+Phoenix so it could be more tricky to find a good hosting for apps written in Elixir.

Q: If I would want to create a chat app, why would I want to use Elixir instead of Node?

A: It all depends. Have you heard of LiveChat (https://www.livechatsoftware.pl/)? They are offering chat capabilities as a service, and are inexpensive if they biggest companies of that kind worldwide. They have made a decision to rewrite their backend (originally in C++) in Erlang. Why? They wanted something reliable and still well performing.

I have tried to crate small chat applications using JavaScript based technologies and from my experience the best fit for that was MeteorJS.

Why Elixir and not NodeJS? Mainly because it possible to guarantee fault tolerance when using Elixir. Scaling would also be easier to achieve. The question is if this is something that is required by chat application. It is a different situation when a chat is a tool for client facing marketing, and different of this is just a platform to exchange picture of kittens :-)

Oh, and please mind that WhatsApp has its backend written in Erlang B-)

End note

I have tried to be objective as much as I could, but I am an enthusiast of Elixir and fp. Some time ago I was actually thinking of getting into the RoR world as my primary technology, but after discovering Elixir I started having doubts and… decided to actually concentrate on Elixir and Phoenix.

Wrocloverb 2017: Elixir vs Ruby

I had a chance to spent couple of hours on the annual Wrocloverb conference this weekend. One of the most anticipated events during the conference for myself was “Elixir Panel”. I had high hopes for great, open discussion on the platform that seem to attract more and more people from Ruby community.

Unfortunately this was not that great as I expected. My biggest complaint was the bias, but let me start from the very beginning.

The panel itself was in the form of “experts have voice”. There was very little involvement from the audience (apart from one person, who at some point joined experts, or should I rather say replaced Roberet. Unfortunately I do not recall this person’s name).

The “Elixir side” were two developers having background in Ruby (as well as in Elixir):

  • Hubert Łępicki
  • Michał Muskała

“Ruby side” was represented by two Ruby, Rails experts from Arkency (the company behind Wrocloverb):

  • Andrzej Krzywda
  • Robert Pankowiecki
    First thing, and first bias: AFAIR neither Andrzej nor Robert have any hands on experience with Elixir. That means that on Elixir side there was good understanding of Ruby/Rails applications, but on the other hand - the “Ruby side” was very lacking in terms of ‘What Elixir is’ (saying that ‘Elixir is Erlang based functional language’ is just a simplification).

Questions

It all started with scalability (which is a selling point for Elixir) and performance. At the moment Elixir seem to perform a bit better than classic Ruby (so not JRuby, or Ruby run using Graal + Truffle). There is a lot of effort to make Ruby perform better and better. What struck me was that a claim that ‘performance is not an issue’. Well, I think it is actually the opposite. In todays world it is quite common that app popularity may spark right out of the blue. App performance is important as it allows more clients (customers) to use the app the same time, and that makes cost of a single request cheaper.

Discussion on scalability lasted for good 10-15 minutes. At some point I have heard a comment “what else is there in Elixir apart from scalability” ;)

  1. Elixir community is not great.

To me that was really bold statement. Recently I have seen some talk from Elixir conference, and on one of the slides it was pictured where do people come from when migrating to Elixir. I am not sure about the exact number, but the vast majority of people come from Ruby+Rails. So… if Elixir community is not great, that would mean that… RoR community is not great :>>>

I would say that Erlang/Elixir community may be a bit different than Ruby’s. I have the feeling that there are quite many Erlang developers who are twice as old as some of the Ruby devs. It may not be true that there are so many experienced users of Erlang, but I still have a feeling there are definitely more Erlang devs in their 50s than people of the same age in the Ruby community. Erlang has been around for ‘a while’, it is doing great again, inspires other languages - such as Elixir etc. I may suspect that some of the people being in their 50s or even 60s may behave a bit differently than people who are in their mid 20s. Does that automatically mean that Erlang developers are not friendly? I wouldn’t say so - but personally I have a very little experience with Erlang community so far.
To sum up: yes, Erlang community may be a bit different, maybe not be that dynamic, but for sure is not hostile. Elixir’s community is actually a lot similar to Ruby community, and from my experience it is extremely friendly.

  1. I have attended Erlang/Elixir meetup and they were talking for 1,5 hour about authentication. Hey, Elixir People! - Devise is already there in Ruby for years!

Well… that’s funny again. Erlang/OTP is very mature platform on top of which Elixir is built. Phoenix is a web framework for Elixir. Elixir and Phoenix are quite new comparing to Ruby+Rails. And that means that some of the concepts still has to be ‘borrowed’ from other languages/platforms. The same thing happened to Ruby - it took some time for Rails to emerge.

  1. Apart from scalability why would I use Elixir?

From my perspective it could be just a matter of taste. If you’re more into the functional programming paradigm - give Elixir a try. If you are interested in actor model, being able to write applications in a bit different way, make your application fault tolerant (or just want to learn how it works in Erlang, but Elixir’s syntax is more appealing) - give Elixir a try.
Sometimes it is good just to try something different. You don’t necessarily have to switch, but such an experience will definitely broaden your knowledge and make you a better developer.

  1. Why use Elixir/Erlang with their actor model if I could use Akka + Scala/Java (nad JVM is less exotic than BEAM)
  2. Why use Elixir/Erlang if we may have actors in Ruby?

Akka’s and Erlang/Elixir’s implementation of actors are a bit different from what I’ve read. It was alread pointed by Michał that there is some problems with actors being blocked sometimes when using Akka. This doesn’t happen with Erlang/Elixir actors (process).
The other important thing worth noting is that actors (processes) and all the mechanisms used to maintain them are core part of Erlang/Elixir. This is different with Akka, as this is ‘just’ a library. There is no extra support for such a paradigm (actor model) into the JVM itself.
If someone wants just to try out the concept it is good enough to use the favorite programming language to play with actors. No need to switch to Elixir or Scala+Akka. Introducig actors could bring some benefits to your application(s), but if you expect extra stability and fault tolerance in your Ruby application just because you’re using Ruby’s implementation of actors (and there is no special support for this paradigm in Ruby VM) that will simply not happen.

  1. Ecto+Phoenix are small in terms of LoC. Rails is big. In x years Phonix & Ecto will definitely grow.

Well, that may or may not be true. It all depends. Thinking this way would mean that Rails is (was) no better than other frameworks (as you can’t keep your awesomeness thorough the years). I think that many people were using Rails for quite a long time, and right now some of them are helping make Ecto+Phoenix better. It doesn’t mean that Ecto+Phoenix will be perfect, no - there will be definitely some things to argue about :) But what I personally think is that there is a chance to learn on experience of others. There is a chance that Ecto+Phoenix may actually improve in some areas in regards to Rails.

  1. Tooling in Elixir? Is it mature?

It has been said that there are not many great editors/IDEs with support for Elixir. It has been also noted that this will be addressed during the summer 2017, as Microsoft invented protocol of interoperation between editor/IDE and Elixir will be implemented.

Personally I encourage you to give Emacs/Spacemacs + Alchemist plugin a try. From all those editors that I have tried out already, this combo seems to be the most mature, and the most convenient. There are plugins for Atom, Visual Studio Code, Vim (these are the ones I tried out) and many other editors. There is also a plugin for IntelliJ if you prefer a full blown IDE instead of ‘just an editor’ - I haven’t tried IntelliJ with Elixir plugin on my own.

It is always possible to have better tooling, so this is a bit of a ‘neverending story’ for us, developers. On the other hand it is worth mentioning that Erlang/Elixir provide some interesting tools - for example nice process monitor - which I believe may not be available on other platforms. So yes - tooling differs, but it changes for each and every platform (for better, of course!).

  1. I have x years of experience in creating Rails apps. AFAIR there were just as little as y projects that could benefit from scalability (or better performance).

Well that is actually quite simple - you just don’t touch different niches when using Rails. The good example that were mentioned during the talk were: game servers, IoT. I do understand that each and every application may have a complex business logic, and this is what becomes the most important requirement - to have things coded in a way that makes business happy. Sometimes it does happens that there are also important non-functional requirements to be met. Some of these could actually be scalabilty or performance.

But… if you don’t question your choices (some of them may have been made quite some time ago) so how do you progress? Why not just check what some other, hot, not-so-mature technolgies have to offer? What if there is really something out there? You may just be unaware how some other tech could improve your life as a developer.

  1. Success story: “thanks to Rails app could be shipped in a short time. Later as the cost of a request is high - that business needs to close. But at least we got our foot into the business…”

Is it a success story actually? Doesn’t that make Rails an Ruby a PoC platform? A platform which is great for prototyping, but actually is not that great when it comes to running business depending on it? We’re not all running such a big systems as Twitter or LinkedIn, but there are well known stories of migrating from RoR to other platforms and languages only due to the fact the those other technologies offered better performance (or scalability).
That question is really one that you can argue about for hours…

  1. It is easier for people to become stars in Elixir community.

I dont really get this one. It was the same with Ruby/Rails 10 years ago. Each and every technology has its own ‘immature’ years, where many libraries are yet to be created (or simply need to mature).
The other thing is: if you realize that there are no (yet) developers who started their journey in software craftmanship with Elixir - does that mean that all we - Elixir lovers - are just attention seekers? ;) Does that mean that only ‘weak’ developers take the Elixir path - as it is so easy to become ‘a star’ in Elixir community?
Another thing - please note that one of the experts was Michał, who not only contribute to Ecto and a person who actually is in the middle of writing a book on Elixir. Taking all that under considertation - don’t you think it was actually rude, as it was actually argumentum ad personam. This question made me somewhat… uncomfortable. I know that Michał didn’t take it personally, but still, it was weird/strange question.

  1. Elixir community is anti-Ruby…

Well, that strange, as I am following Elixir community for ~9 months right now, and haven’t spotted such a hostile approach against any technology. Frankly speaking I felt that it was Ruby community on Wrocloverb who was… a bit anti-Elixir. This is what I found strange. I had the feeling (from previous attendances to this conference) that it was actually open to different approaches, languages and frameworks. It was the case with all the JS ecosystem (ClojureScript, React, many other technologies/frameworks), but the important thing to note here is that all the technologies warmly welcomed by Ruby community during Wrocloverb were actually technologies which could be easily consumed by Ruby developers to enhance their apps. There was no real Ruby competitor mentioned on the last 3 editions of Wrocloverb - or at least I don’t remember such a situation. This is where Elixir differs in comparison with ReactJS - Elixir is not something one incorporates into Rails/Ruby app. Elixir is also not a language that most of the Ruby devs find appealing (even though its Ruby inspired syntax). But the biggest thing here is that it seems that Elixir community grasped a momentum, and there is a lot of hype on Elixir right now. I suspect that some of the Rubbyist feel that Ruby/Rails may not be as popular in the future as they are right now. But instead of learning more about ‘the enemy’ is it so wise to be anti-Elixir? ;)

Summary

One thing that I didn’t particularly like was the bias. It was not as objective as I could (should?) have been. The strange thing was that after the panel finished, the moderator made a comment being happy that not as many people wanted to still experimet with Elixir as at the beginning of the panel.

If I were to sum the panel up it would boil down to: dissappointment. I expected interesting, open discussion on possibilities. What I got was quite a boring, cliche driven panel. A panel that (I belive) aimed to assure Ruby developers that Ruby still is THE LANGUAGE and that Rails is still THE FRAMEWORK. I am afraid that’s not really true. I don’t expect Ruby/Rails to disappear in the nearest future, but I don’t think it will stay as popular as it is/was. And this is not only due to emergence of Elixir+Phoenix - Rails today is just one of many web oriented frameworks that it is pleasure to work with. Rails inspired a lot of others, and no longer is the coolest kid on the block.

It is a good summary to point out that at the beginning of the discussion audience was asked if they were willing to try Elixir. At the end the question was asked once again. Not that many hands were floating in the air ;) Was it really ‘mission accomplished’ as moderator joked? I personally think that this panel discouraged some developers from trying Elixir. Why would you try someting different if your language and framework are… perfect? ;D

It is sad, that so many interesting questions were left unanswered (for example, question about mnesia). This panel could be of much greater benefit to all those who are not (yet) convinced that they should try Elixir, those who would take the extra effort to broaden their horizons.
This post already grew more than I expected, so I will try to answer some of the questions that are interesting, but due to the time constraint didn’t have a chance to reach experts.

I think that Wrocloverb 2017 lacked ‘an intoduction to Elixir for the masses’ type of talk. It could be quite hard for those, not being exposed to what Elixir is, follow the discussion on Elixir and Ruby. I am afraid those Ruby devs, who just hoped to get some key info on Eixir were left dissappointed.

Note: this is all written in a hurry, so I do apologize for all the typos or errors, poorly phrased sentences etc.

Elixir: setting up environment part 2: documentation

In my last post (which was prepared some time ago) I have described how to use asdf for Erlang and Elixir version management.

There is one important thing that I have not covered: documentation. Erlang and Elixr both come with documentation included. For Elixir it is all simple as using iex and its h helper (read more about it: https://hexdocs.pm/iex/IEx.Helpers.html).

For Erlang - there are manpages available. As always - things a bit more complicated when someone uses versions managers (such as asdf/kerl etc). First of all, you can’t expect that it would be possible to access Erlang’s manpages usin system ‘man’ - unfortunately this is not how things work (maybe if you install Erlang using repository instead of version manager such as asdf…). The other important thing is that documentation for Erlang is not properly installed when using asdf-erlang. Issuing erl -man mnesia (mnesia being name of the module) results in ‘No manual entry for mnesia’ instead of proer manual page being displayed.
I have found a temporary solution for that: http://stackoverflow.com/a/42053208

The proper solution would be to have documentation files downloaded, extracted and copied as part of the installation process. The manual workaround works for me at the moment, and I haven’t found enough time to try and enhance asdf-erlang to be capable of taking care of installing proper version of Erlang documentation.

It has been discussed that Elixir’s iex helper should be able to display documentation for Erlang modules (https://github.com/elixir-lang/elixir/issues/3589). Unfortunately it seems that at the moment there is no working solution for such a behavior. There are some alternate solutions, but I haven’t tried any yet.

Interesting solution for viewing Erlag/Elixir documentation is Zeal (http://zealdocs.org). It is available for Linux, MacOS and Windows, and allows easy browser Erlang and Elixir modules. For some it may be much more convenient to use Zeal instead of using erl or iex depending if module is part of Elixir or Erlang.

Elixir: setting up environment

One of the first things that is required when starting with new (programming) language is… to have compiler/interpreter installed and prepare the environment. Cliche…

I am happily using nvm (for NodeJS) gvm (for Go) and rvm (Ruby) for quite a long time, and I started looking for something similar for Elixir and Erlang.
I wasn’t very lucky at first, as my first approaches were not really successful. It was mainly due to the fact that I am happy user of fish shell, and I don’t want to give up using it (even in favor for zsh).

I think I am this kind of a person who really tries to makes everything complicated ;) Even though I could have Elixir and Erlang easily installed issuing something as simple as sudo apt install erlang elixir I am not really keen on doing that. Two reasons:

  • in most cases versions of the compilers/interpreters in system repository are really not the latest (and that gets worse and worse as time passes by)
  • in such a scenario (installing programming language using system repository) it is not possible to have many different versions of a specified compiler / interpreter installed. And sometimes it is a must (maintenance of some old application etc.)

asdf to the rescue!

Back in summer 2016 I was quite successful using hybrid approach. I have used asdf (github.com/asdf-vm/asdf) for Erlang and kiex (https://github.com/taylor/kiex) for Elixir. Asdf was required only to get specified version of Erlang (as this is required by Elixir). Asdf was not accessible for me via fish - so I had to use bash for asdf and to have Erlang version of choice installed. Luckily kiex was running all fine under fish. The whole thing was not super convenient (switching between fish and bash etc.) but it worked.
The whole thing didn’t bother me that much, and I have been using such approach for quite a while. Today - as I was trying to set up environment on another machine - I have realized that asdf does support fish shell right now :) What a nice surprise. It all became so easy right now.

Asdf seems to be much more flexible than the other version managers that I am using. Asdf does not focus on one particular language. There is a concept of plugins for asdf which allow it use asdf for managing versions for many different languages. Installing plugin(s) is the second thing you will have to do right after you have asdf installed. But if you get to that point, installing new version of Erlang becomes as easy as:

asdf install erlang 19.2

which (to me) is as simple as sudo apt install erlang but, of course, using asdf has advantage of installing specific version(s)!

Asdf is very simple but powerful. All your version management is literally under your fingertips.

So, if you’re like me, and you like to have 100% control of the versions of compilers installed - please try asdf. This is a great tool!

I am actually thinking if it would be a good idea to try asdf for managing NodeJS, Go and Ruby versions (oh, and I am planning to get my hands dirty a bit with Clojure and Rust in the nearest future, and asdf supports these as well…)

Caution: dependencies

It is essential to study erlang plugin home page. It brings a lot of info on dependencies that are required to have Erlang offer everything. I haven’t paid enough attention first, and ended up with environment I wasnt able to run obser (or debugger). This particular issue is easily fixed by installing dev version of wxwidgets library (and rebuilding Erlang, unfortunately…).

So if you encounter “wxe_driver.so” related error whenever you try to launch observer/debugger - you know what to do :)

Elixir

Having Erlang installed, and being familiar with asdf, bringing Elixir on board is piece of cake (assuming you have elixir plugin for asdf installed first):

asdf install elixir 1.3.4

Elixir installation is much, much faster than Erlang.

Disadvantages of asdf

The only disdvantage of asdf I can think of right now is that installing new version of Erlang does take time. Why? It is not as simple as just retrieving binary from some repository. Source code for specific version is being downloaded and then built. It all take several minutes on my machine - but hey, how often do you install new version of your favorite compiler? Personally I think that flexibility described is worth waiting from time to time to have a specific version of the language installed. It is important to note that removing version previously installed is almost instant.
Note: after adding additional libraries (wxgtk-dev among others, so that I can start observer and debugger) compilation time now takes significantly longer. It is the price I am still willing to pay for the flexibility that asdf brings.

After a quick break from writing this blog post, I realized that there is one more thing which I don’t particularly like about asdf. Installing a new plugin requires one to go to asdf project site on github and check what is the plugin repo url - when you have it, a simple asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git (for Elixir) will do. I’d rather have possibility of doing all that via command line. But that a really minor thing.

Sidenote:

I have also tried using kerl (github.com/kerl/kerl) for Erlang and kiex (github.com/taylor/kiex) for Elixir, but it was not all that convenient as asdf with 2 plugins. I am not sure if it was due to the fact that I wanted kerl and kiex to run under fish shell… but as asdf works so well for me right now - I am no longer looking for any alternatives.

Summary

I am happily using asdf with Erlang and Elixir for quite some time, and frankly speaking I started thinking of giving up on other solutions, such as nvm, gvm, rvm etc. Why would I bother with so many different tools/scripts if I may have just one (plus couple of additional plugins)?
The advantage of having asdf replacing all other version managers is that I don’t have to remember about differences in command line arguments / switches.

One thing may may not be that easy to achieve using asdf with its NodeJS plugin: having specific version of NodeJS installed with all the plugins from current (or yet another installed version). I am using this approach quite often, as I have to have some global pacakges installed (for example: to make hexo, yeoman work). Using nvm this is as simple as: nvm install v7.4.0 --reinstall-packages-from=v7.0.0. It sees that asdf-nodejs (https://github.com/asdf-vm/asdf-nodejs) doesn’t support such a behavior.

Linkr - description of the project

This week I have been preparing for starting work on my Linkr project. I have been thinking about functionalities, and what mechanisms the project should support. What I have planned so far is:

Milestone 1:

  • any user should be allowed to add a link (URI) + short description of the resource
  • any user should be able to search (the search mechanism should look for the search term in the description and the URI itself)

Milestone 2:

  • user should be allowed to add tags
  • user should be allowed to sort filter links by tags

Milestone 3:

  • user should be allowed to create an acount - i.e. only registered users should be able to add new links (that whould be a change to what is M1)
  • only owner should be able to change description of the link (I think it should not be possible to remove added links)

Milestone 4:

  • user should be able to see only links of tags of interest (global filtering for logged in user)

Mileston 5:

  • ‘likes’ - users should be able to sort links starting with those which were given the highest rank in the category. I am not sure how the sorting should actually work. I guess it should not sort all the links within particular tag - that would be a nonse, as it could happen that old link were displayed on the top all the time. Maybe it should be as follows: “sort by date first (descending) and then after the ranking”?

Milestone 6:

  • users should be allowed to use rss/atom - so that they’re constantly updated with new links being added

Milestne 7:

  • users should recieve email notification on new links - this option should be configurable, so that it is possible to receive a notifaction in following scenarios:
    • no notifications at all
    • after there is a new link added
    • daily
    • on a specific day/time of the week (I am not really sure about that. I am not 100% sold to that idea, as I don’t know if such a flexibility is important. It may as well be fixed as - Friday 6PM GMT or something alike)

If I were to sum the whole idea of the project - I’d say that it is something like ‘delicious for a group of people’. I have a strong feeling that this could be useful for a group of people who may be exploring a specific area of knowledge, and this would be a nice thing to share their finding among the group.

Why Elixir?

In my first blognote related to this years edition of “Get Noticed” I have mentioned that I am planning to develop web application using Elixir & Phoenix. Why Elixr?

I have a chance to develop web applications using variety of technologies: C# + ASP.NET & ASP.NET MVC, Python + Tornado, Ruby on Rails, JavaScript + NodeJS + Angular, Meteor (using Blaze as the frontend technolgy). Some technologies were more and some were less “developer friendly”. If I were to sum up what technolgies were the most fun to use I would say: RoR and JavaScript frameworks. MetorJS was a bit more fun, but NodeJS + Angular + MongoDB is something more solid, and still used even today (apart from the fact that teams are migrating from Angular 1.x). C# + ASP.NET/ASP.NET MVC were a bit less fun, altghough ASP.NET MVC was much better and I liked it a lot more than classic ASP.NET. What I didn’t particularly like about MS tech stack was that it was more of a blob than just language + technology stack. What I mean is that it is rather impossible to create something more complicated NOT using Visual Studio. Generators (as yeaoman, rake etc.) were not available at that time, so there was not a chance to use something else for working with code than Visual Studio. Everything was IDE driven. If there was a need to add additional fields to a database, or create new tables - all these actions were invoked from withing the IDE. It was so much different to the approach I could take develiping applications with pure JavaScript or Ruby. Having powerfull command line tools I felt I had more control over the process of application development. And I also had the feeling that I understood better what is happening and why.
So - the first thing would be “openess” or simply - technology being open source. Or even free - in terms of leaving all the decisions to the user.

Scalability

My personal opinion is that web applications are facing different problems that 10 years ago. Succesful applications right now often get extremely popular in a very short time. This means that it is important to design application with scalability in mind. And that is not so easy. The number of problems one has to face when it comes to designing scalable app is huge: beginning with responsiveness of the frontend itself, scalability of the workers, session management, and (probably the most complicated) picking up proper approach related to data storage. These are all non trivial problems.

Elixir is based on Erlang virtual machine. Erlang on the other hand is a language developed in 1986 by Swedish company Ericsson. Erlang was born alltogher with OTP - Open Telecom Platform - which was used to to control switches (as far as I understand at the beginning the aim was to control and connect phone calls). Erlang is being described as general purpose, concurrent, fault-tolerant & functional programming language. The concurrency in Erlang is achieved by using actor model, which is extremely interesting concept. In short - Erlang is capable of spawning hundreds or even mant thousands of processes in a very short time. These processes are much lighter than OS processes, and are controlle by Erlang VM. Important thing is that Erlang comes with a lot of tooling for controlling processes. Elixir as a language based on Erlang benefits from all that.

As I see it nowadays - scalability becomes more and more important in the are of web applications development. Elixir seems like a perfect fit here. Why not Erlang itself? Well - partially because Elixir syntax seems more appealing to me.

Functional Programming

I have a strong feeling that functional programming is one of the most important concepts that each and every developer should deeply grasp. I was taking some Scala and Haskell courses back in the past, but I lacked a proper “battlefield” to test my knowledge. I want to make an effort this year and develop my skills in the area of functional programming. What better opportunity than creating an application using functional programming language?

Mature technology

I have already mentioned that the technology Elixir is based was created back in the 1986. It means that it is more than 30 years old. Quite a lot of time to prove its maturity.

Friendly community

What is unique in Ruby community is its openness and friendliness. I had zero problems solving problems I bumped on, when developing my RoR applications. A lot of resources are available, and people in general are very happy to help someone who is not familiar with the technology.
I have the feeling that the same is true about Elixir community. Maybe it is due to the fact that a lot of people who are interested in Elixir have Ruby background, but I am not sure if this is the (only) case.

Hype

Hype may not be the best word… I have a strong feeling that there is a lot of interest in Elixir. Not only from the developers but also from companies. More and more companies are evaluating Elixir and check if it is a good fit for their needs. I see a constant rise in interest of hiring people who are familiar with Elixir. And this interest is no longer only from the companies located on the West Coast of US - there are more and more companies using Elixir located in Europe. I treat the whole adventure as an investment for the future.

Get Noticed 2017 - start!

Some as last year - this year another edition of “Get Noticed” initive is being started. The whole idea is quite simple - to blog about a project - software that will be developed during the next couple of months (all starts beginning of March 2017, ends in May).

Last year I tried to take part in it, but due to some unpredicted things happening - I was not able to devote enough time for it, and didn’t manage to finish the application. I hope this year is going to be different and that I will be able to share quite a lot of thoughts & decisions related to application development.

My idea for the application is still the same - I want to create a simple web application that will allow people to share links to interesting resources. That’s it. Simple stuff. I hope that as time goes by I will implement more and more features for that.

So… as the idea for the application itself stays the same as last year - you may want to read a post about it from last year: Let them know you

One thing is changing this year though - I have picked different language (or should I actually say - technology stack?). Last year my choice was to use Ruby+Rails. I was a total newbie with Rails&Ruby at that time, and apart from going through some tutorials I haven’t created any application on my own using RoR.

So what’s my techonlogy of choice this year? Wel… this year it is going to be Elixir+Phoenix. I haven’t made any other decisions yet. I am not sure what storage I am going to use. I am not sure if I am going to use ReactJS, AngularJS, VueJS or any other fancy technology for the frontend itself, or if I leave it as a pure Phoenix frontend. I hope to make all that decisions while developing the application, and will try to document my choices here - on my blog.

Let them know you!

Interesting idea has spread in Poland among software developers recently - it is called “Let them know you” (“Daj się poznać” in Polish). It is all about developing an open-source project, and blogging about it for ~3 months (roughly twice a week).

I thought that as I don not have a lot of time - it is the best idea to join it!

Couple of years ago, I was working for a company which had a very cool thing happening - it was called “Something new, something interesting, something cool”. It was a weekly digest emails containing links to articles, blog notes etc. which were found interesting/worth sharing by some developers. These links were then put into an email by one person, and sent to all interested within the company.

I was so bought by this idea that I have even started doing this on my own in one of the companies I was working next. At some point I have realized that doing it all manually was the biggest disadvantage of the whole idea. I happened to forgot about including some links. I have also forgtten couple of times to send the email…

There were also other problems:

  • there was no easy way to search through all the links that have been sent
  • newcomers were usually not aware of this initiative at all - someone had to tell them about it
  • when a new person wanted this email digest to be send to them - I had to update the distribution list… again a 100% manual process

Taking all these things under consideration - myself and my friend Cyryl(github: https://github.com/cyplo blog: https://blog.cyplo.net) started thinking about starting a project that would solve some of those problems. In the end of 2014 we have created a scaffolding of the Ruby on Rails project, but… after the initial couple of commits we have ‘forgotten’ about it, and for about a year we haven’t contributed to it at all. Recently I have decided to resurect the project, and push it forward. And the “Let them know you” initiative seems to be the perfect opportunity to be more devoted in working on the project.

The github repository is located under the following location: https://github.com/curalink/curalink

AngularJS 2 workshop

Last Saturday I have attended AngularJS 2.0 workshop organized in Wrocław. The event has been organized by DevMeetings (http://devmeetings.pl), started ~9 am and finished rougly 6 hours later.

Hosts were employees of LiveChat (https://www.livechatinc.com/). One of them - Wojciech Kwiatek - gave a talk on AngularJS2 based on their experience at one of the local tech groups. LiveChat decided to switch to AngularJS2 couple of months ago - even though AngularJS2 was not stable at all at that time (they have jumped on the AngularJS2 bandwagon when the whole thing was still in alpha!). It seems they are still pretty happy with the decision. I know that they have been looking at ReactJS as well, but decided that ReactJS may not fit that well into their usecase, and they would need to create a framework from many libraries on their own - so the ‘completeness’ of AngularJS2 was also important.
It was great that hosts had real experience with AngularJS2, and not only “played with it” at home :)

Two skeletons of the apps were prepared - one using gulp, and the other utilizing webpack. If you would like to have a look, the webpack version is freely available on github: https://github.com/wkwiatek/angular2-webpack2

The whole agenda was as follows:

  1. Introduction to AngularJS2
  2. Components
  3. Events
  4. Pipes
  5. Services and Dependency Injection
  6. Forms
  7. Http+Rx.js
  8. Routing

It was quite a lot of stuff (mostly brand new to most of the attendees) and I don’t think a single person has managed to finish all the tasks. I have personally go through the first 6 of them, but haven’t touched Http+Rx.js & routing at all.

I especially liked how forms are implemented in AngularJS2 - that is a common thing for web developers to create, and it is not of minor importance. We had interesting discussion on forms in ReactJS at one of the last local tech group meetings. Yes… forms are things you just can’t escape from :)

What I lacked a bit was how to structure the whole application. I have spotted that many attendess just took the “finished? go with the next task” approach, and had most of the code in single .ts file. I just wanted to avoid that, and spend some more time on re-structuring the application, so I had everything (classes, components) in separate files.

Summary:
I am happy I have attended the event. I only read about AngularJS2 before, and apart from tiny snippets, I have not written any AngularJS2 code. This was the best opportunity to get more familiar with the technology, create something bigger, and get the ‘feeling’ of the new, upcoming and technology.

The event was another opportunity to do some more coding in TypeScript. I am not sure if I like it or not… on one hand it seems to mee just too much of a ‘C# for JavaScript developers’ type of approach, I realize that there is additional effort required to have type definition for all the libraries you use. But on the other hand - I think that TypeScript may allow for further improvements of JavaScript performance (thanks to type annotations and optimizations that could be possible to achieve thanks to it).

Thanks to Wojciech Kwiatek, his friend from LiveChat (sorry, forget the name) and DevMeetings team for making this event happen!

My personal rant against GeekWeekWro

Last year the first edition of the GeekWeekWro (http://geekweekwro.pl) iniative has taken place in Wroclaw. I wasn’t really bought by it, and the same is this year - I don’t understand what is the point of having it (having GeekWeekWro).

I have couple of doubts, qestsions regarding this idea:

  1. What is the purpose? What is the aim of it?
  2. What extra value does that bring? What does it improve within local tech-communites?

The answer for the 1st question is… “I don’t know”. Even worse, you won’t find any goals of it on its own website (date: 3rd of March, 2016). The only thing you can find is as follows (translation from Polish by me):

GeekWeekWro #2 to tydzień pełen wiedzy, technologii i przede wszystkim zabawy!
Od 11 do 16 kwietnia 2016 po raz drugi będziecie mogli wziąć udział w spotkaniach grup, które działają we Wrocławiu!

Translation:

GeekWeekWro #2 - a week full of knowledge, technology, and more importantly - fun!
During the week of 11 - 16 of April 2016, you will have the chance to take part in tech group meetings in Wroclaw!

Well… that’s all true, but… can’t we take part in the tech group meetings in other months? When no GeekWeekWro is on schedule? Well… sure you can! Most of active group participants are doing it thorough all the year!
So… there is nothig that GeekWeekWro improves. There is no gain for the community. There is nothing ‘extra’ that happens during this ‘special’ week.

Unfortunately, there is one thing that GeekWeekWro makes worse: it introduces clashes between events.

(Sidenote):
When I settled down in Wroclaw in 2012, there were not many actively functioning tech groups. I was complainig a bit about it, but someone told me to put some effort and improve the situation. Since then I have been active member (and co-organizer) of the .Net group (I have given several talks), together with my friend Adam I have started AngularJS group (I am still main organizer), I am founder and leader of the functional programming group and I co-organize local Go Language group. I am not putting all these things in here to show you how awesome I am - I just want to point that in the area of how local tech communities work - I know what I am talking about.

Let’s get back to the problem of clashing events. As an organizer I tried hard to avoid situation when the newly started group will clash with another one (that is probably more established already). I know that others (organizers) are thinking alike. Why would we put people in a position of choosing between attending meeting of group A vs attending meeting of group B if this is not necessary? I would like everyone to have opportunity to show up on as many events as possible. It should all be only personal limit, not something that myself (other organizers) are doing on purpose.

So, if you think about cramming many events during a single week - it is obvious that there will be no choice, but to choose which event to give up from. Is that the goal of the GeekWeekWro? To limit, to restrict people from attending many events during the month that GeekWeekWro takes place? If so - well… job well done!

I don’t see any way as how to improve this situation. In my opinion the whole idea is flawed. I don’t see any benefits of GeekWeekWro, but I can easily see disadvantages of having it. I clearly see how it negatively affects local community, and makes things worse than usual. I hope it will not get very popular (and I hope for it only because I want to be able to attend as many events as I usually do). The groups I am the main organizer of will definitely NOT join this initiative. And I am more than certain, that some others share my views and will thank me for that (for not introducing even more clashes between events).

I have discussed ‘the problem of GeekWeekWro’ briefly during the last meeting of the local Python group. My friend Paweł suggested that it could have been much better idea to have several groups meeting in one place, each group giving 1 talk only. That could help integrate local community much better than what GeekWeekWro is currently doing.
Unfortunately, I still can see couple of problems:

  • how to create ‘packs’ of groups? Matching JS/front-end focused with Go/.Net/Java - will that work for everyone?
  • when to meet? For some people some days are simply ‘no-go’ days. In case there are many groups having a meeting on this particular ‘no-go’ day - such a person will not be able to attend a single event out of x they ususally attend
  • can we prepare such ‘joined’ events in such a way so that these are interesting for many people?
  • some groups are quite popular, and you may easily expect 50+ people attending - what if there are 4 groups meeting at the same place, same time? How do we find venue(s) for such meetings? It seems to mee that mostly due to this fact, this is not something we may organize.

Besides - do we really need this kind of event to ‘integrate local tech groups’? Most of the groups are easy to find on meetup. If someone thinks some particular group could be of her/his interest - there is no other option as to go and check for yourself. That’s it. You don’t need GeekWeekWro for that. You don’t need GeekWeekWro, so that people unaware of existence of such groups will read about ‘how many tech oriented groups we have in Wrocław’. That is a pure nonsense. Anyone from the IT industry must have heard about local communities - either from work mates, colleagues, or via electronic channels. Those who are unaware - are probably not the target anyway.
And hearing in the ‘news’ or reading about tech groups on websites that have nothing to do with tech community - is this of any value? For the community?