Thoughts about the cutting-edge of server programming | Hacker News Reader

Thoughts about the cutting-edge of server programming

4 pointsfeylikurds17 comments

I am currently working on a project to develop a secure mobile app using micro-services written in Go, Node.js, and Lua targeted at both Android and iOS. I am writing the back-end which will be cloud-based. I thought it would be a good idea for me to share some of my experiences.

Micro-services are the coming absolute standard in server architecture. Dividing a program up into smaller pieces has always be one of the principles of computer science, but to take it one step further and to have different parts of the program in different machines use to be only in the realm of super-computing. Cheap cloud-computing allows everyone to easily create their own clusters, and micro-services are the best architecture.

Of course our queries are RESTful, but we chose to use a simplified form. The requests are URL-queries, and it seems that the lowest common denominator for how long they can be is 2k characters (to be accessible to all browsers). The responses, though, are always in JSON.

Go is an incredible language whose standard library has enough components to satisfy 90% of one's needs. One can think of it as an improved C, so it lacks inheritance, function overloading, and generics. I hope someone creates a fork called Go++. I did some tests, the Go HTTP component was 80% as fast as Nginx, but they were only simple page loads, since Nginx's scripting language is not that complete.

Node.js is the most powerful way to do server-side scripting. Tens of thousands of packages means that one hardly has to write any code. And the speed is pretty decent, but do not even try to do anything CPU intensive. Node.js is JavaScript which is compiled with the V8 Engine and single-threaded.

I also realized the differences between concurrency and parallelism. When there is only 1 CPU, it is not possible to have parallelism. Parallelism includes concurrency, but concurrency is not parallel.

> Node.js is the most powerful way to do server-side scripting

not really.

By the way, have a look at http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-... . Elixir/Erlang excels at concurrency and allows you to build large-scale distributed backends easily, with many additional benefits (fault tolerance, ...).By the way, "Microservices" and "Actors" for parallelism and concurrency aren't really discussed in the erlang/elixir world, since this is the natural way to code. The "cutting edge" to do massive backends is actually decades old, battle-proven and guaranteed to work, this is what erlang actually was designed for.

Many many Big systems today are using the Erlang VM for their critical backends, like Call of Duty or Whatsapp.

Please do not give undue preference to Elixir over Erlang.

Other than that, I agree.

I used both, Elixir/Erlang and Erlang/Elixir. And Both variants exactly one time. The only small preference is that I used the Elixir/Erlang variant as the first one, but hey, one could argue that coming from Go/Node, elixir may be easier to get started. :)

What are "Elixir/Erlang" and "Erlang/Elixir" supposed to mean? I understand adding the slash for OTP, as those are shared traits. Perhaps their use of BEAM, though that's secondary.

Common language shortcut for "OR", at least for my understanding it seems-

"Micro-services are the coming absolute standard in server architecture."

I worry when I read comments like this.

Micro-services are an architectural style that should be used appropriately, not religiously, no matter what your favorite blog is telling you.

Spot on. And there is a fairly large overhead. A lot of the places speaking about the wonders of micro-services deal with <100 micro-services (about the number you would get if you converted a small-medium sized app). Lets see what happens when you get 10k micro-services.

> Tens of thousands of packages means that one hardly has to write any code.

this is exactly what's wrong with the Node community.

I think that the Go++ you search exists already: Rust. (no offense, but Rust has everything you need plus what Go has already)

Agreed, Rust is superior to Go in almost any way. Especially when stuff becomes more than a 30-lines-snippet, Rust shines.

I haven't yet found a supported Rust answer to goroutines, though -- am I missing something?

std::uv ? lightweight threads similar to go-routines, greenlets of gevent (Python), or Node.js.

EDIT: Mea culpa, it used to have. (ref. http://stackoverflow.com/questions/29428318/why-did-rust-rem...)

Well, you can always build your own interfaces to achieve a similar result. But why do you need go-routines ?

By the way, at least, Rust tries to handle concurrency the most he can (by analyzing if data race can occur, at compile-time for example).

What do you need more ?

The goroutine model allows a lot of tasks to be handled in parallel without the application developer having to worry about it. So, for example, a web framework can have one goroutine per request and scale very well. That is what I would love to see in Rust, although I know it isn't likely right now since a lot of the ecosystem is still maturing.

Oh, I see what you're saying. Yes, me too. And I may end by giving a try to implement such lib.

Anyway, like you've said, the ecosystem is still maturing. But the more people are interested in Rust, and the more libs we will have.

The advantage that Go has with regard to green threads is that the language and its standard library are built around them. There's no easy way to introduce them into a language via a library with the same level of simplicity.

I'm curious if you writing a "mobile app" that works in the browser, why you labelled it Android/Ios? I do love the optimism abound that you think your app will need to scale so largely. It is better to build in scale from the beginning, rather than as an afterthought.

Hi, you mentioned Lua in the first paragraph but didn't go into any detail about how you are using it. Can you expound on that?

Reply on news.ycombinator.com