That’s excellent - it has the potential to solve half of Go’s problems. Still outstanding will be (1) the goal of making an (IMO) nerfed language and (2) the lack of error handling in the language.
dogweather
wanton7
Also in C# that is very short, just dict.Keys.Sort(). So yes it’s bit awful when you have to write lot of code to achieve something like this in Go. Hopefully added generics starts solving that. But I think it will take many years until generics are fully utilized in the language.
1
beepbeepbopbop
Go doesn’t really make any assumptions on what you need app and data structure wise, but does make a fair number of them when utilising the standard library for networking, database pools etc. It’s always been irritating that Go forces the user to write known structures, such as sets because Go strives for simplicity (when in truth, is anything but).
Anyone can walk through the excellent Go by Example and up out knowing how to write Go provided that you come from a C background, but I find that alone is insufficient in any sort of application design. While the messaging from Go is that there’s “one” way to do things, it’s hardly the case as pages such as Effective Go and CodeReviewComments · golang/go Wiki · GitHub are necessary to get some confidence in Go itself.
While Go is incredibly fast, it lacks robust in-built fault tolerance which is a deciding factor at scale. There’s an excellent video https://www.youtube.com/watch?v=40d26ZGfhR8 which illustrates the key differences between Go and Erlang; especially on what Erlang does (process isolation, in-code reloaded etc), which simply doesn’t exist in Go outside a third library. In short, the video concludes that tools such as Kubernetes smooth the edges with Go, especially around Go panics which can, if done incorrectly, can tear your entire application down abruptly. This reinforces my prior point; Go can be written quickly, but you have to be extremely defensive and write code to handle those instances, made somewhat worse by Go’s anemic error handling.
If you do decide with Go, you have to cater to the possibility of unexpected application shutdown and ingrain some sort of behaviour that kicks in when it occurs. It could be systemd, or Kubernetes, but you’re forced to acknowledge that runtime errors can propagate to application errors and have to plan accordingly. In Erlang, while this can happen, you have in-built measures in places to ensure that the application isn’t compromised in the presence of runtime errors.
4
mindok
Just a clairification on Nerves - it is still full OTP / Elixir, but bundled for embedded systems.
A couple of other points worth considering:
- Erlang & Elixir’s binary parsing approach using pattern matching is very powerful. If you are having to implement different control system protocols this approach can potentially significantly reduce effort. You can see a worked example here: Binary pattern matching in Elixir with PNG parsing example (first result from a google search)
- The BEAM was designed specifically to hold lots of concurrent conversations with extremely high reliability - it was built for telco switching systems. It isn’t good if 100,000 conversations get killed because of one mishap in one single conversation. Erlang/Elixir almost certainly gives you the shortest path to fault-tolerance while holding multiple “conversations” with multiple in-field devices.
- RabbitMQ - a pretty well known message queue infrastructure - is written in Erlang (same platform as Elixir). You can take a look at the source here: GitHub - rabbitmq/rabbitmq-server: Open source RabbitMQ: core server and tier 1 (built-in) plugins · GitHub. Again - speaks to the reliability and ability to do many things at once.
- While go has the big advantage of packaging pretty much everything into a single binary through the compiler & linker,
mix releasedoes an excellent job of bundling an Elixir application into a single folder for deployment. - The performance characteristics when a BEAM-based system is under load are generally quite attractive. Latency/performance tends to gradually fade as load increases, which means you have time to do something about it before it becomes a disaster. If I can recall the talk I’ll add the link! (@wanton7 mentions this in hist list)
- Batteries included - caching, queuing, multi-CPU concurrency, background jobs, web-serving, API creation / consumption etc can all run off the one codebase. While Elixir applications may not deploy as a single executable, they can deploy as a very simple stack.
- Serious engineers in the community. So I don’t know much about the Golang community (although I do know that there are some very talented folk in it), but the Elixir & Erlang community has, in my experience, been very open & generous, but also very thoughtful about how long-term, robust, low-hype, sustainable software should be built. It has a low presence on stack overflow relative to other languages (possibly downside when trying to convince pointy-haired bosses that it’s the right choice), but if you know where to look and make an effort to help yourself, help is never far away. The telco platform roots almost certainly have something to do with the serious side, but the Elixir ecosystem leaders such as José, Chris & @AstonJ keep it very human and welcoming.
If you haven’t watched this video yet, you should: https://www.youtube.com/watch?v=JvBT4XBdoUE - it really brings to life a few of the concepts covered in this thread and a very worthwhile investment of 42mins IMO.
Good luck with your project - it sounds pretty cool! I spent a few years working for an industrial control system vendor and do think Elixir could take a lot of complexity out of SCADA systems & similar where hard real-time isn’t needed. If you do go this route, I’d love to hear how you go.
13
Vlahunter
You make a lot of good points. For sure in case I would move forward with Golang I should have a complementary set of tools in order to achieve the necessary scalability, fault tolerance, etc. The reason Golang is in the evaluation process so far is the simplicity, the standard library and the very small produced executables as well the fact that the resources that a Go app needs are significantly less compared to any language that runs on top of a whole VM
0
Vlahunter
Woah!! I had to take some time to digest your response. All the points you make are very helpful to me, thanks for that. My 2 main concerns when it comes to Elixir are:
- The time needed for me first and my team afterwards to write code in a correct functional way
- The case that the apps will need a large amount of resources in order to run because the most important thing in such projects is stability and sustainability.
I will keep searching around the points you made and ofc let you know if I would move forward with Elixir on this one. For the record I see a lot of Apache, Eclipse and LF projects in a space close to the project I am researching but it’s tough to pick cause of multiple different factors hence the first thing that came to mind would be what I could possibly build myself first and if I see that I am reinventing the wheel, only then to research further on these projects.
0
wanton7
I tried to learn functional language called F# before Elixir. It was very hard and stopped before learning it. Tried Elixir and it was very easy to learn compared to it. Functional language is basically just functions and data and in my view Elixir is lot simpler than C# for example. Immutability takes some times to get used to, but it really makes code/data flow much easier to understand. It’s usually easy to find what is wrong by just looking at the data that is flowing from function to function. I feel like testing functional code is also much easier.
My background is that I started using C# in 2003 professionally. I think it takes about two weeks to start getting your head around how the language & platform works to start building things. If you come from non-functional language background and you are a senior programmer. I would also suggest that you don’t write any Elixir macros if you don’t absolutely need to.
3
mindok
On resource utilisation.. bear in mind that Erlang first appeared in around 1986 when the 386 was the dominant desktop chip and RAM was measured in single digit megabytes rather than double digit gigabytes. When I’m sick of Windows &/or Mac, I pull out my trusty old Thinkpad x220 running Kubuntu (11 years old, and has the best keyboard ever put on a laptop), and everything performs fine. There are others on the forum who can talk to performance on a Raspberry Pi.
While Erlang/Elixir do run on a VM with the inefficiencies that come from that, there are some pretty smart optimisations to maximise the work not done. For example, web applications end up being super-efficient and performant due to some architectural choices in the way “strings” are processed into output on the wire - see https://bignerdranch.com/blog/elixir-and-io-lists-part-1-building-output-efficiently/
3
Vlahunter
Yes I can believe that since according to the docs, this ecosystem is built to start and never stop as I get it. And in this regard I am interested in that aspect of course. Which means that as long as it could be able to provide this fault tolerance along with other good things others mentioned (for example background jobs/tasks) and keep the resources in a predictable manner this could be enough at least for my boss to give a thumbs up and for me to continue.
0
cmo
If your machine specs are 8GB+ of RAM what’s the concern with system resources? Is that box specifically for this task or will it be running a SCADA client or something as well?
How do you fulfill the robust requirement with Go?
Sounds fun, good luck!
1