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

521–530 of 648 posts

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

#521

Post by nikitaga »

IggleSniggle wrote: post #439
nikitaga wrote: post #296

Earlier quoted context omitted.

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 no…

It appears that function parameter bivariance is still a thing? [1] Although there seems to now be a flag to make this one use of variance correct.

I would assume even Array is still bivariant as well...

Both of those are horribly unsound, just for convenience. Sure convenience and compatibility are Typescript's ultimate goals, but to actually praise it for its generics? That's very strange.

> TypeScript absolutely does allow you to express these relationships

How would you express a class with covariant or contravariant type params in Typescript?

[1] https://www.typescriptlang.org/docs/handbook/type-compatibil...

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

#522

Post by dayjobpork »

mvanga wrote: post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

When you fine some cool tool you can: 1. Use as is. 2. Make behind the scenes changes that don't alter functionality. 3. Make changes that add functionality. 4. Make changes that remove existing functionality.

4 is the problem. It's like joining a car club then keeping pushing to have petrol cars banned. It is really shitty to find a cool tool that you can use, then try to force remove features that existing users use.

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

#523

Post by chillfox »

lemmsjid wrote: post #289
mvanga wrote: post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

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." Except when you can't because no client is available in your favorite language. Then it is a lot harder than a rest api would have been.

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

#524

Post by alexose »

bfb09 wrote: post #514
alexose wrote: post #510

Earlier quoted context omitted.

The reason it seems like an attack is due to the hostile tone of your comments, the burner account, and the unfounded/unsourced accusation that USDS left its partners behind. I apologize if you just wanted to discuss the merits of a startup-minded approach to government IT, but I'm honestly skeptical of your motivations. USDS ruffled many feathers among the entrenched IT interests, and I've seen what the propaganda r…

Perhaps my beef with your cadre is assuming that questioning its merits is AFS propaganda coming from someone who’s never set foot south of Embarcadero and assuming everyone who mentions principals has an axe to grind. You’ve painted a lovely caricature of who you think your opposition is, but you’re looking in entirely the wrong direction. Hint: Two FAANGs. I don’t speak on the telephone with underhanded accusations…

Heh, ok. I know when I'm getting trolled. What was that main account of yours, again?

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

#525

Post by a1369209993 »

incompatible wrote: post #454
chris_wot wrote: post #411

Earlier quoted context omitted.

I'm genuinely curious - do you really have to do all of that? Why not just ignore the frameworks and technologies that overcomplicate things and use what works best for you? I am wondering why someone just hasn't forked etcd if it is truly so awful now.

Forking is the answer, if you don't like the where a particular group is going with an open source project. Fork an old version, and perhaps you will find some others who prefer it that way.

Nope! The original group will sue you for trademark infringement, despite that they're the ones peddling a broken knockoff version. (See, eg Python, Firefox, GIMP, etc; I don't pay much attention to webapp-related stuff, so I don't have more proximate examples.)

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

#526

Post by zokier »

swagonomixxx wrote: post #368
zokier wrote: post #361

Earlier quoted context omitted.

> In the meantime, the simpler version of the software is long gone The thing is that with free software the old software is almost never really long gone. It's still out there, free for your perusal. That is the beauty of free software, it's always additive process. But it does also put responsibility on the user to pick the patches they want, either themselves or by proxy. Ultimately you are responsible for the fre…

While this is technically true, using old, unsupported versions of software (such as etcd) in production is a recipe for disaster, especially when you start running into problems with it. I think, in the case of etcd, it would have been better for the k8s folks to fork the project and add whichever features they felt were needed to be able to use it for k8s. Instead, it seems like they swarmed the original project an…

It's not unsupported if you support it yourself or hire/contract someone to support it for you

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

#528

Post by chillfox »

incompatible wrote: post #454
chris_wot wrote: post #411

Earlier quoted context omitted.

I'm genuinely curious - do you really have to do all of that? Why not just ignore the frameworks and technologies that overcomplicate things and use what works best for you? I am wondering why someone just hasn't forked etcd if it is truly so awful now.

Forking is the answer, if you don't like the where a particular group is going with an open source project. Fork an old version, and perhaps you will find some others who prefer it that way.

yes, but that generally doesn't stop someone from feeling annoyed.

While I do like cheering for annoyed people to fork projects it's not always practical for a number of reason like:

- The project is large and really requires multiple people to maintain.

- It's written in a programming language that the person is not familiar with, or interested in (they might even dislike it).

- License issues.

- Their work might prevent them from working on open source projects due to intellectual property concerns.

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

#529

Post by duncan_bayne »

lemmsjid wrote: post #428
duncan_bayne wrote: post #370

Earlier quoted context omitted.

> Now I can just grab a generated client in a language of my choice. No, you can just grab a generated client in a language of your choice if that language happens to be supported by protobuf. This is a massive regression from the openness of HTTP REST APIs.

That would have been a critique of Thrift, and a valid one, but gRPC has an http gateway interface with semantics for how the RPC calls map to REST calls and JSON. As long as that is supported, then there does not need to be a regression.

Sure, if the provider of the gRPC service wishes to also offer an HTTP gateway, that's true.

But it's trivially true in the case where the provider does so wish (as it would be true of any protocol with a fully-functional HTTP gateway infront of it), and it's untrue in the case where the provider doesn't.

And the provider has to do extra work:

"[offering an HTTP gateway] required adding custom options to gRPC definitions in protobufs, and add an additional container running this reverse-proxy server." ( https://wecode.wepay.com/posts/migrating-apis-from-rest-to-g... )

This still seems like a massive regression in openness to me.

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

#530

Post by jcheng »

melq wrote: post #497
kelnos wrote: post #470

Earlier quoted context omitted.

It's funny that you consider that complex; I consider that a pretty normal, expressive type signature that gives the compiler critical information about how I expect to use that function, which in turn allows it to completely squash several classes of bugs I might write. But I love strong type systems; people who prefer weak type systems would likely consider things like this to get in their way.

Could you elaborate on this point for someone who isn't familiar with typescript (or javascript, for that matter). I'm no stranger to strongly typed languages but that function signature seems pretty complex to me. By elaborate I mean explain what's going on in that signature, and what the critical information it supplies is?

It's from the TypeScript 4.0 beta blog post[0], which describes it as:

> partialCall takes a function along with the initial few arguments that that function expects. It then returns a new function that takes any other arguments the function needs, and calls them together.

The type signature looks like:

  type Arr = readonly unknown[];
  
  function partialCall(f: (...args: [...T, ...U]) => R, ...headArgs: T) {
First of all, know that in TypeScript, colon separates a variable or parameter name from its type. So in C or Java you'd say "Date lastModified", in TypeScript it's "lastModified: Date".

Now, looking at it piece by piece:

  function partialCall
declares a function named partialCall.
says that this is a generic function with type parameters T, U, and R (the first two of which must extend Arr, that is, a readonly array of objects whose types are unknown).

This function's first parameter is:

  f: (...args: [...T, ...U]) => R
The name of the parameter is `f`, and the type of this parameter is `(...args: [...T, ...U]) => R`. This means that `f` must be a function whose return type is R, and its parameters must match `...args: [...T, ...U]`.

The `...` in `...args` makes it a rest parameter[1] (variadic parameter in other languages). The type of `...args` is `[...T, ...U]`, which you can think of as the concatenation of the T and U arrays. (It's a bit strange to see `...` in a type specifier, I can't recall having needed this before.)

  ...headArgs: T
says that the `partialCall` function itself is also variadic, and its arguments are gathered up into headArgs. The type of headArgs is T.

I don't know if I'd call this normal or clear compared to the signatures I encounter daily, but it's pretty elegant for a higher-order function that takes a function with any signature, and some arguments that match the given function's parameters, and returns a function with the matched parameters removed. And the implementation of partialCall is just this one line!

  return (...b: U) => f(...headArgs, ...b)
[0]: https://devblogs.microsoft.com/typescript/announcing-typescr...

[1]: https://www.typescriptlang.org/docs/handbook/functions.html#...

Post reply on HN