Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

511–520 of 648 posts

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

#511
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…

I think everyone here remembers that time they wrote a simple HTTP server, that just works, and would continue to work today. If anything, I hope that we can recognize that there has been advancements in computing. Back in the day you would be open to attacks left and right. It was the wild west back in the day. Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone bre…

FCGI controlling Go programs, maybe front-ended by a load balancer and back-ended by MySQL/MariaDB/Postgres, can get an awful lot of work done cheaply.

FCGI is an automatic "orchestration system" - it starts up more instances as needed, restarts them if they crash, shuts them down when they go idle, and restarts them once in a while in case they leak some resource. It's like the parts of Kubernetes you really need.

Go is an OK language. Not a great language, but an OK language. It comes with almost everything you need for server-side applications. Also, the "goroutine" model means you don't have to fool with threads vs async. If a goroutine blocks on a lock, no problem; the CPU gets redispatched. If you need a million goroutines, that works, too. None of that "oh, no, the async thread made a call that blocked and screwed up the whole system".

MySQL/MariaDB/Postgres have been around for decades, and they work pretty well. You can have replication if you need it. (NoSQL seems to have come and gone.)

Get the stuff at the bottom right, instead of piling more cruft on top. It's cheaper.

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

#512

Earlier quoted context omitted.

> I think military tech has a problem that it's trying to keep out with commercial drive tech which operates on a scale that a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts. Not to excuse military contracting pork and cost padding, but this is a good point that a lot of people seem to miss. There's also the fact a military contract will be for a production run and…

Another huge factor is the service lifetime of military equipment. There are aircraft that were designed and created in the 1970s that are still in use today. Sure, many of the components and internal systems have been modified and upgraded, but much of the original design is still there and operating. >> a military contract will be for a production run and follow on support. When "follow-on support" has to last for…

B-52

First flight: 15 April 1952; 68 years ago

Introduction: February 1955

Status: In service

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

#513
post #497
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?

I would say, there is some complexity in reading (and writing) the thing. But there is probably not as much complexity in using it. And you are explicitly codifying the complexity in one place, that would presumably still exist in a dynamically typed language, just implicitly, and likely spread out across the code. This looks pretty nice to me at a glance, just like anything once you write a few of them and come across a few in the wild and take the time to pick them apart they no longer seem so scary.

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

#514
post #334

Earlier quoted context omitted.

I’m alarmed by you reading my admitting it’s a shame to actively lobby to disassemble what he’s built and walked away with a sense of attack instead of my deepest respect for him conflicting with my views on the environment he brought with him not necessarily being the answer. For better or worse, he’s the face of bringing Big Web out here, and I mention him to indicate that I know what I’m talking about. Your interp…

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, sorry.

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

#515
post #470

Earlier quoted context omitted.

There is complexity in the type system with signatures like ``` function partialCall (f: (...args: [...T, ...U]) => R, ...headArgs: T) { `

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.

[deleted]

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

#516

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.

There is complexity in the type system with signatures like ``` function partialCall (f: (...args: [...T, ...U]) => R, ...headArgs: T) { `

At least I can pick it apart and deduce it. I can even use the compiler to give me information about it via editor integration (all same editors have it now). So I’ve I’m unsure it might take a few minutes of investigation to completely understand the signature.

I’ve seen some JavaScript written so tersely it was nearly impossible to figure out without spending Possibly hours on unwrapping the code. That’s the value provided here.

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

#517

Earlier quoted context omitted.

All the JVM languages you list aren't transpiled. They target JVM bytecode just like Java. They're first class, even if Java obviously gets the overwhelming amount of VM level support. Engineers working on the JVM are definitely aware of and want to support non-Java langs.

Scala can target JavaScript. Kotlin is usually used with the JVM, but can target native machine code (and JavaScript too I think?). Transpile was the wrong word for me to use.

Ah, I wasn't thinking of the JavaScript flavors. I think "hosted" is how Clojure describes itself.

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

#519
post #360

Earlier quoted context omitted.

A decade is a long time in software engineering. Kubernetes would be obsolete by then. What do I need to revisit?

> A decade is a long time in software engineering. Is it? Code I wrote literally 20 years ago is still running in production, and I get paid to work on an app with plenty of code around that was first committed in 2009. If you build a system in k8s today, and it's a success, there's good reason to believe you'll be on k8s in 2030.

That’s pretty cool, really. I can’t really find studies on average software life time, so all I really have is anecdotes. I can’t imagine software running for that long on eg public clouds without any kind of major refactor considering how quickly technology changes today, and how aggressively cloud costs push companies to change. Specifically, I can see something like “Serverless” coming to maturity and completely changing the paradigm (again!) on how software is architected. But it’s possible I’m wrong and like you say, k8s will be around for much longer than I anticipate.

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

#520
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…

There was some generic big-company hate thrown in there, but the author really didn't say anything half as coherent in the OP as you did.
Post reply on HN