←back to thread

Ergo: Erlang-inspired event driven actor framework in Go

(github.com)
175 points nateb2022 | 4 comments | 12 Sep 24 11:06 UTC | HN request time: 0.001s | source
Show context
Xeoncross ◴[12 Sep 24 13:58 UTC] No.41521050[source]▶
> Zero dependencies

This is something seldom attempted, but I congratulate you. Go is one of a few languages that really is batteries-included. Just about anything you could need is included in the stdlib.

replies(4): >>41521157 #>>41521657 #>>41521695 #>>41521859 #
pjmlp ◴[12 Sep 24 14:56 UTC] No.41521695[source]▶
Still doesn't have half of batteries that Python, Java and .NET include.
replies(4): >>41521882 #>>41521931 #>>41522719 #>>41531371 #
philosopher1234 ◴[12 Sep 24 15:15 UTC] No.41521882[source]▶
No doubt that is true, but are there particular batteries you’re thinking of?
replies(1): >>41522679 #
pjmlp ◴[12 Sep 24 16:33 UTC] No.41522679[source]▶
GUI, dependency injection, huge collection libraries, dynamic runtime Interoperability, distributed objects, compiler plugins, custom runtime schedulers,... for example.

Some of the above will never be in Go due to how the community and language designers are philosophically against them.

replies(1): >>41523824 #
limit499karma ◴[12 Sep 24 18:14 UTC] No.41523824[source]▶
> dependency injection

It's been a while since I played with the furry thing but is that even possible in Golang?

replies(1): >>41524462 #
pjmlp ◴[12 Sep 24 19:16 UTC] No.41524462[source]▶
I was speaking about Python, Java and .NET standard libraries.

In Go you can naturally do it, by using the manual constructor approach, however there is no magic auto wiring like you can do with attributes and compiler plugins, plus standard libraries infrastructure for locating services, from those three ecosystems above.

replies(1): >>41525199 #
limit499karma ◴[12 Sep 24 20:31 UTC] No.41525199[source]▶
Well, in my head DI at this point requires the magic bits. Otherwise it is (as you say) just constructor args.
replies(1): >>41528758 #
1. pjmlp ◴[13 Sep 24 07:10 UTC] No.41528758{3}[source]▶
Except that there are many ways to do DI, magic is not necessarly required, other than much welcomed development experience.

However Go doesn't like magic, thus that isn't something that will ever happen on the standard library, like on Python, Java, .NET.

replies(1): >>41529749 #
2. limit499karma ◴[13 Sep 24 10:13 UTC] No.41529749[source]▶
I guess we have to disagree here. The key word here is "injection". Dependency initialization, setting, passing, etc. none of these are 'injection'. But yes, Go lacks the necessary metadata mechanisms and per what you are saying it still does.
replies(1): >>41530896 #
3. pjmlp ◴[13 Sep 24 13:05 UTC] No.41530896[source]▶
Injection doesn't mean automatic, or magic.

And if one goes back 20 years, constructor based injection was the norm, the magic only came later thanks to Aspect Oriented Programming, yet another tool that Go will never adopt.

replies(1): >>41531612 #
4. limit499karma ◴[13 Sep 24 14:33 UTC] No.41531612{3}[source]▶
Sure, but I don't recall it being called "injection". Obviously we are in agreement that dependency references are introduced via some mechanism. Also AOP came [after] Java J2EE and Spring. However I will concede that there is a distinction between 'inversion of control' and general DI.