sagichmal

Well said.

Docker doesn't have any infrastructure for managing configs. Nor secrets. It doesn't have log shippers or storage -- and "to file or syslog over TCP" are definitely not the recommended ways! The only thing it really "does" there is process isolation.

Lol.

> Anything that "runs a binary somewhere" will essentially become docker given enough time.

Docker... doesn't do nearly any of those things?

It's fine at medium and large scale, too, as long as the service doesn't change its API very much, and/or it doesn't have too many consumers. It only breaks down when managing change becomes too difficult. IMO way way too many people opt in to the complexity of IDL-based protocols without good reason.

Sure, but that utility also carries massive costs: the infrastructure and tooling required to work with those schema definitions, especially as they change over time. It's certainly not the case that the benefits always, or even usually, outweigh those costs.

Tried it. Definitely not ready yet, and the scope may be large enough that it won't ever get there. Also, many of its design choices are fundamentally in tension with statically typed languages.

I think you can probably formalize JSON API schemas in a useful way, but JSON API ain't it.

> The flip side (IMHO, at least), is that simple build-chains are underrated.

Wow, yes! Yes!

IDLs represent substantial complexity, and complexity always needs to be justified. Plain, "optimistically-schema'd" ;) REST, or even just JSON-over-HTTP, should be your default choice.

Great. Let them do that. The important thing is that they're not getting their message in front of whoever happens to be scrolling the Reddit front page. That's enormously more harmful.

> That's just your opinion and you treat it like some universal axiom.

It's OK that some things involve subjective judgment.

> So, deplatforming (silencing) a group is okay, but doing the same for other group is not okay based on some arbitrary criteria.

This is such a lazy argument, because it's trivially defeated. Yes. Exactly this. In the same way that e.g. jailing one group (the guilty) is okay, but doing the same for another group (the innocent) is not okay.

> Deplatforming solves a problem.

Yep!

> IMO it makes things even worse since these groups will congregate in secret much further away from the public eye where they can perpetuate unbalanced and unhealthy ideas.

The whole point of deplatforming is to prevent those stupid ideas from having a general audience. Sunlight is not always the best disinfectant.

Eliminate? No.

Reduce to the point of practical irrelevance? Yep.

Deplatforming works.

> The boundaries between teams are not necessarily the minimal interface.

No, but they are the inevitable interface.

On the contrary, every instance where there is more than one way to do something is a failure of the language. It's OK, all languages have failures, but the ideal is pretty clearly a set of precisely orthogonal features, where there is neither repetition nor exception.

> Reading Go means that I keep having to read idioms (as posted in the article) and parse them back into the actual intent,

What? I never have to do this...

> I can't easily navigate to the definition of a function . . . I usually don't have tooling that can jump to definition

What? You command-click on it... ?

> jump-to-definition becomes impossible as soon as interfaces are involved, because structural typing makes it impossible to know what is an intentional implementation of that interface

What? You obviously can't jump-to-definition of an interface, but in what way is this a limitation?

> However, when pinning, when one of your static dependencies is broken due to a change outside your control (e.g. hardware, operating system, security issue making it unusable, or something else), the user's only recourse is to call the developer to fix the software.

In practice, this happens so infrequently it can be ignored as a risk. (When it does happen, users generally don't expect the software to continue to work.)

> dynamic linking has at least one extra advantage...

You don't seem to be acknowledging the downside risk to dynamic linking which motivates the discussion in the first place. An update to a dynamically linked dependency which breaks my delivered artifact is an extremely common event in practice.

Honest question: have you ever worked as an application developer? Responsible for getting working artifacts to users as a means to an end?

Pinning dependencies absolutely and unquestionably works better, and for longer, than dynamic linking, for this use case.

> Is the pypi package awscli an application or a library?

Hopefully a library! As hopefully the AWS command-line interface is maintained and distributed separately from any SDK that powers it...

> It says "knowledge" not "code". This is an important distinction.

Yep. Though the same pathologies exist even with this framing. By that I mean it's easy to misdiagnose what the "knowledge" actually is. Even totally identical types and behaviors can be distinct in the knowledge sense if they exist in different contexts.

Previously:

https://news.ycombinator.com/item?id=25236552 Micro – a self hosted cloud platform for API driven services development (2 months ago)

https://news.ycombinator.com/item?id=25044604 Micro 3.0 is a platform for cloud native development (3 months ago)

https://news.ycombinator.com/item?id=24999682 Micro 3.0 Released (3 months ago)

https://news.ycombinator.com/item?id=24999036 Show HN: Micro 3.0 (M3O) – a platform for cloud native development (3 months ago)

https://news.ycombinator.com/item?id=23081544 Announcing: M3O – A Micro services development platform (9 months ago)

https://news.ycombinator.com/item?id=23067233 Micro Server (9 months ago)

https://news.ycombinator.com/item?id=23070042 Show HN: Micro Server – run and manage microservices locally and in the cloud (9 months ago)

https://news.ycombinator.com/item?id=22200647 Show HN: Micro v2.0.0 (12 months ago)

https://news.ycombinator.com/item?id=21562859 What is Micro? It's just the future of microservices development (1 year ago)

https://news.ycombinator.com/item?id=21491378 Show HN: Go Micro – A Go microservices development framework (1 year ago)

https://news.ycombinator.com/item?id=19545615 Micro – the microservice toolkit 1.0.0 release and beyond (2 years ago)

https://news.ycombinator.com/item?id=12178690 Micro – A microservice ecosystem (4 years ago)

https://news.ycombinator.com/item?id=11930775 Show HN: Micro – a microservice toolkit at Go Meetup London [video+slides] (5 years ago)

https://news.ycombinator.com/item?id=11710611 Building Resilient and Fault Tolerant Applications with Micro (5 years ago)

https://news.ycombinator.com/item?id=11706540 Building Resilient and Fault Tolerant Applications with Micro (5 years ago)

https://news.ycombinator.com/item?id=11564021 The Micro Bot – ChatOps for Microservices (5 years ago)

https://news.ycombinator.com/item?id=11518847 Micro architecture and design patterns for microservices (5 years ago)

https://news.ycombinator.com/item?id=11471004 Micro on NATS – microservices with messaging (5 years ago)

https://news.ycombinator.com/item?id=11327679 Show HN: Micro – a microservice toolkit (5 years ago)

It's not necessarily idiomatic or nonidiomatic, it's just a pattern that's appropriate in some circumstances and not appropriate in others.

If you want best-effort asynchronous job processing semantics, then it's totally appropriate to use something like what's described in the article -- ideally with a lot less code :)

If you want request-response, then, yeah, this isn't appropriate, and I agree that you should do whatever work in the request goroutine, blocking as necessary.

The documentation for package app kind of says it all:

https://pkg.go.dev/github.com/mattermost/mattermost-server/a...

This is atrocious stuff.

This is one of the worst open source Go projects that exists, unfortunately.

> globals in Go modules. Seems like a bad practice to me.

It is, and good packages don't have them.

The stdlib is kind of a mess. One kitchen, many cooks, and everyone was learning how to put a five-course meal together as they went. There are some great bits -- package io and ioutil, for example -- but a lot of it is full of what we now understand are bad ideas, and the compatibility promise prevents anyone from doing anything about it.

There is much better code to read. I second the recommendation of HashiCorp's stuff. Stay away from Docker and especially Kubernetes.

Polymorphism doesn't require casting or union types or whatever it is you're describing.

Interfaces absolutely express a type of polymorphism: any concrete type that satisfies the interface can be used in its place. What makes you think otherwise?

> Essentially, what I am claiming is the Golang is a bad language for metaprogramming

That's definitely true, and an explicit choice. Thank goodness!

Some people say this, but when they do, other more senior people quickly interject and say it's a bad idea.

> Many say, "Pass the database connection in the params." ... How can you write tests for logic without having to instantiate a DB?

You define and use an interface to model the DB, and use that as the mock point. Basic stuff.