Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

Post reply on HN
Print view View original

431–440 of 648 posts

Re: Etcd, or, why modern software makes me sad

#431

Post by lemmsjid »

wrsh07 wrote: post #317
lemmsjid wrote: post #289

Earlier quoted context omitted.

The problem, I think, is that the article presents all of its views as almost self evidently true. If you distill it down, the complaint is that etcd added gRPC. I think it was a good move for an infrastructure piece like etcd to add gRPC. Now I can just grab a generated client in a language of my choice. There's certainly valid critiques of gRPC / protocol buffers but I've found things like gRPC and Thrift to reduce…

I agree with you. I like grpc. But I also think that the original author has a point: for many solo developers it's an extra dependency that they have to learn, and they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.

Yep! That's the nuanced argument I'd look for, as opposed to 'gRPC bad, they added it because they're from google!'

Simplicity wise my favorite scenario is where if I'm using Python I can pip install an interface (or maven, or NPM, etc. etc) which is the versioned, supported interface for a component. REST + Swagger can help a lot there. So can gRPC. But I can also get how your favorite scenario might be to explore a REST API and build your own client.

Re: Etcd, or, why modern software makes me sad

#432

Post by amiga-workbench »

linuxftw wrote: post #371
js8 wrote: post #319

Earlier quoted context omitted.

> It's almost like there's no good representation in the open-source world for the solo developer or small team. IMHO, there is a simple solution to this - release the software under the GPL license. Then no corporation will want to touch it.

AGPL would be more apropos in this day and age of "SaaS all the things."

https://opensource.google/docs/using/agpl-policy/ They're absolutely allergic to it.

Re: Etcd, or, why modern software makes me sad

#433

Post by cytzol »

inopinatus wrote: post #424
cytzol wrote: post #337

Earlier quoted context omitted.

> What security do you gain by being in a container instead of on a server without a container? I'm not a container guru, but... this is obvious, right? You have to break out the container, which is an extra layer. In order to get root on the server, you need: • Without container: application vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root) • With container: application vulnera…

Containers share a platform. They increase attack surface by supplying a vector to any neighbour, by being something that can be attacked at all, and by requiring another control plane that requires credentials, making it a social engineering opportunity as well as being another component that itself can be vulnerable. They are not an additional shell of defence, they do not reduce your blast radius.

> They increase attack surface by supplying a vector to any neighbour

Could you explain what you mean by this? I'm still not getting it.

Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, and an attacker who manages to exploit an RCE vulnerability gets access to the port "for free"; if they're both in containers, then they can only see the ports I specify, and it's really easy for me to specify them.

This literally does seem like an additional shell of defence to me! What sort of attack would it make worse?

Re: Etcd, or, why modern software makes me sad

#434

Post by abernard1 »

wrsh07 wrote: post #317
lemmsjid wrote: post #289

Earlier quoted context omitted.

The problem, I think, is that the article presents all of its views as almost self evidently true. If you distill it down, the complaint is that etcd added gRPC. I think it was a good move for an infrastructure piece like etcd to add gRPC. Now I can just grab a generated client in a language of my choice. There's certainly valid critiques of gRPC / protocol buffers but I've found things like gRPC and Thrift to reduce…

I agree with you. I like grpc. But I also think that the original author has a point: for many solo developers it's an extra dependency that they have to learn, and they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.

> they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.

If you're talking latency, to this day gRPC in dynamic languages is still slower than most fast json implementations in _latency_.

It is simply not correct to talk about "performance" this way.

If you care about CPU allocation and not burning 70% of your CPU on JSON parsing, then sure. Most companies don't care about that, and I/O is 3 orders of magnitude a bigger problem than in-process parsing for those problems.

Re: Etcd, or, why modern software makes me sad

#435

Post by lemmsjid »

abernard1 wrote: post #327
lemmsjid wrote: post #289

Earlier quoted context omitted.

The problem, I think, is that the article presents all of its views as almost self evidently true. If you distill it down, the complaint is that etcd added gRPC. I think it was a good move for an infrastructure piece like etcd to add gRPC. Now I can just grab a generated client in a language of my choice. There's certainly valid critiques of gRPC / protocol buffers but I've found things like gRPC and Thrift to reduce…

> Now I can just grab a generated client in a language of my choice. But you can't curl the state of your infra component without creating a program and downloading the client artifacts. This is a very big step backward from an operability standpoint. > because there's a thousand interpretations of REST out there ...but there weren't a thousand different interpretations of the etcd API out there: there was exactly on…

Yeah I don't disagree, I was mainly pointing out that there isn't a black and white 'grpc = bad' argument.

Especially since I believe grpc does take steps to mitigate some of the RPC issues you'd have with, say, Thrift. For example having the REST gateway so you can support the curl scenario without any extra work. (For example when building my own Thrift-type services I would do extra work to have a mini REST API for status and other operational curling uses)

As to the second part of your argument about there now being a second API, and how that is not necessarily a good thing, I quite agree and can't really speak to the etcd use case, other than that I don't think it's some property of 'Xooglers' to do such a thing to an open source component. I've spent my career using open source components: I've had lone developers who change their APIs willy nilly to fit the pet peeves of their own organization; I've had large companies own an open source component and have it be very disciplined about version migration; I've had lone developers be similarly disciplined; I've had companies make open source projects really complicated.

Re: Etcd, or, why modern software makes me sad

#436

Post by dynamite-ready »

mattigames wrote: post #396
gcbw3 wrote: post #238

Earlier quoted context omitted.

describe the steps to release the simplest ever code in javascript to production: write a js file, host it, done. The same thing in TS adds at least one step (not to mention the rest of the tooling you will want) So while a prefer it over JS, there's no arguing that it is more complex as now you require a build step for a language that only exist because people wanted a language without a build step.

Browsers should just bite the bullet and add TypeScript support.

You can have that with WASM.

But then if that's an option, I think Typescript will be the last language I migrate to, because Typescript development culture, tending as it does towards overcomplicated solutions to simple problems, is unpalatable to me.

I'm drawn to the idea of using Rust over WASM as a frontend language, and I think I'd rather choose that approach to develop any browser UI where type safety is critical, provided there is no discernable difference in performance (when compared to TS over WASM).

Re: Etcd, or, why modern software makes me sad

#437

Post by gavinray »

munchbunny wrote: post #249
IggleSniggle wrote: post #186

Earlier quoted context omitted.

TypeScript is a funny one. I love the language, but at the same time, I totally agree with the premise that it is unnecessary complexity! And yet I swear by it. I can't explain why there's not more cognitive dissonance there. JavaScript taught me to love async, then functional programming, and TypeScript taught to me to love static types. I'm now desperately wishing for a world of OCaml/Haskell, but where are you goi…

You choose the tool chain to fit the anticipated team. If that team is just you, then who cares? Pick the easiest thing for you. But if you’re an expert in the tool chain and you anticipate new people hopping on, then the on-boarding process should definitely be one of your considerations. The argument for simpler tool chains for simpler projects is that the time it takes to on-board should not outweigh the time save…

I used to make the same argument, about not using TS for prototyping, but the tooling is so good that at this point, I generally just change the file extension to ".ts" and write no manual types for the mistakes and type-hints + intellisense the compiler and language server provide.

Re: Etcd, or, why modern software makes me sad

#438

Post by vlowther »

ninkendo wrote: post #282
dnr wrote: post #215

Earlier quoted context omitted.

The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.

> IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries What a strange comment. "The benefit of this protocol is that it's so complex that nobody understands it, so they have to use an existing implementation."

What a weird slippery slope argument. There is a world of difference between "so complex that nobody understands it" and "I can telnet to port 80 and fetch a webpage using keyboard and fingers"

Re: Etcd, or, why modern software makes me sad

#439

Post by IggleSniggle »

nikitaga wrote: post #296
flatline wrote: post #233

Earlier quoted context omitted.

What is unnecessarily complex about TypeScript? It's JavaScript, with static typing plus type inference, and pretty nice generics. The ecosystem of modern JS surrounding it is horribly complex but TypeScript itself seems like a fairly straightforward programming language.

Offtopic but what's nice about Typescript generics? Typescript doesn't even let you specify variance. It's one of the unsound parts of the language's type system in fact.

You cannot explicitly specify covariant vs contravariant, but TypeScript absolutely does allow you to express these relationships. Unless I misunderstand you.

That said, the type system has come a very long way even in just the last year. The biggest improvements imho being around recursive types (which was one of the biggest holes for a long time imo), literal types / literal type inference, and tuple types.

It's not complete by any means, but it's improving quite rapidly.

Re: Etcd, or, why modern software makes me sad

#440

Post by gcbw3 »

BrainlingPdx wrote: post #430
gcbw3 wrote: post #250

Earlier quoted context omitted.

> "megacorporations" are the faceless evil enemy There are some irony on the text, but to understand this is very naive. The critic is at malicious/dumb people who latch to technologies without understanding them. For argument sake, see how many people are defending coreOS etc, and how they claim to have decided to like it based on their superb expertise, yet they will likely fail to explain to you chroot or anything…

So your response to him pointing out that the author talks in absolutes, and tries to shit on any tech he doesn't like...is to talk in absolutes and shit on tech you don't like, with little jabs and dumb in jokes? Very convincing.

Lol. did it fall too close to home?

Read my comment again and you will notice there's not a single comment against or in favour of tech. Not even an adjective next to tech, only to people.

The comment is exactly that some people can't tell the difference between two completely identical techs, just because they buy the marketing of one of them, despite it being a brand on top of the first.

Post reply on HN