Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

611–620 of 648 posts

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

#611

Earlier quoted context omitted.

> we can still just pick a small subset Unless you have to work with legacy code or libraries.

Then some poor soul gets to wrap the old patterns into the new patterns! But seriously, if modern C++ has one thing going for it, it has a great backwards compatibility and forward refactoring story. I'm not a huge fan of the "evolved" syntax, and I rarely use C++ anymore, but I like modern C++ substantially more than C++03, which was where I first cut my teeth as a programmer.

> Then some poor soul gets to wrap the old patterns into the new patterns!

This isn't always an option. Google's C++ guidelines generally forbid using exceptions, but concede that you might have to if you're dealing with existing code, particularly on Windows.

https://google.github.io/styleguide/cppguide.html#Windows_Co...

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

#612
post #546

Earlier quoted context omitted.

Blaze/Bazel has its flaws (including poor integration into the world outside google), but what are you comparing it against? Any general purpose build system I've seen that is not bazel based and not nix is a flaming pile of garbage: almost nothing else can even figure out a correct dependency tree, let alone which parts of it have changed and need recompilation. Bazel also uses a familiar, readable and yet concise s…

> The only compelling alternative to gRPC I am aware of is capnproto (which is derivative, but in some ways nicer) I would argue that while Cap'n Proto's serialization is derivative of Protobuf, the RPC protocol is wildly different from gRPC. > but it has far less eco system maturity and mindshare. That's certainly true. (I'm the author of Cap'n Proto.)

Yes, sorry I was imprecise, it would have been better to have written "derivative of protobuf". To the extent the RPC part is derivative, it's probably mostly derivative of E?

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

#613

Earlier quoted context omitted.

You should come join the fun! In order to deploy a web app in 2020, one must write his frontend using react and typescript that would transpile the code into a nicely bundled and minified javascript and css files along with thousands of your 3rd party dependency libs. Yes, you heard that right! I just counted the number of libs on the node_modules in one of my small side project and it's over 1000s. You might also wo…

And here I am, making a career writing LOB web apps in Rails, and getting to MVP in weeks instead of months (or even years). Guess I'm really missing the boat!

My pet theory is developers crave challenges. If their project is not challenging enough to stimulate their mind, they will introduce more and more complexities until the project is hard enough to keep them intellectually stimulated. Thus, software development will never converge into a single tech stack as smart developers that got bored as hell working on crud apps will invent new stuff to make their work more interesting and meaningful.

In 5 years react and kubernetes will be considered legacy tech and we will march on to other new shiny tech.

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

#614
post #70
post #47

I run k8s in production and I think this is a really bizarre axe to grind that sort of smells like someone who got upset by how steep the kubernetes learning curve is. Which, in a way, is understandable. > 1) Add hundreds of new failure modes to your software In my entirely anecdotal experience, it removes error modes. It turns out that just because k8s offers a feature (it offers many!) doesn't mean you're required…

What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.

I'm personally fine with yaml, but specifically k8s yaml config is definitely not concise!

Compare roughly equivalent Compose/Swarm and k8s configs, and you'll see that the k8s one is about 8x bigger.

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

#615
post #70

Earlier quoted context omitted.

What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.

> What's wrong with the YAML? Nothing at all. Until you start 'templateizing' it (looking at you, Helm). It's definitely better than JSON (it can even have comments, imagine that). Most people don't bother reading the spec or even examples though, and don't realize how good it actually is.

> Nothing at all. Until you start 'templateizing' it (looking at you, Helm).

This scourge affects JSON too, such as Azure's ARM templates, which also crowbar logic into the format. An abomination!

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

#616
post #540

Earlier quoted context omitted.

Maybe you're right - it's not unsuccessful after all, it really is a bullshit project... Now _every_ part of the OS is in a container! Wheee! https://en.wikipedia.org/wiki/Container_Linux (for those who don't know, it was renamed from CoreOS to Container Linux)

Would you please stop posting flamebait and unsubstantive comments to HN? You've been doing it a lot, and we ban such accounts. https://news.ycombinator.com/newsguidelines.html

1. I repeated an argument made in the article itself. That cannot be considered flamebait.

2. I've always expressed strong opinions in my posts. Sometimes this results in multiple upvotes, sometimes in multiple downvotes.

3. About being "unsubstantive" - I underscored the main concept/rationale for Core Linux, and linked to its Wikipedia page. You could argue that it's not substantive _enough_, but when you phrase it this way it's as though you merely dislike the fact that I repeated the inflammatory term from the article.

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

#617

Earlier quoted context omitted.

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…

When it comes to spending hours unwrapping code, gotta love js that has undocumented heavy use of string based property access for things like imports. Like the worst of both functional and OOP combined, and generally no IDE support to be had.

Implementation approximate, but otherwise true story, both LHS and RHS:

`let { statefulMutatingAccessor } = require(obj["prop."+tree+".subtree"])`

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

#618
post #530
post #497

Earlier quoted context omitted.

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

Thank you for taking the time to explain that, it is much appreciated.

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

#619

I don't really use k8s nor etcd, but one sentence in the article really stood out to me: > I would go so far as to say that Kubernetes is the worst thing to happen to system administration since systemd. I know it's popular to shit on systemd, but as a casual user, I honestly don't get it. I've written about a dozen systemd unit files over the years, and each time it's been a pleasure. Write a few lines describing wh…

I personally have no beef with systemd and completely agree with you that having a simple and standard way of composing services/daemons is a wonderful thing, and one that was sorely lacking for a veryong time indeed.

My impression from the systemd debate is that those that are against it feel that way because of the breadth of systemd - it's much more that "just" about service units.

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

#620
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.

Almost nobody does Javascript without a build step these days, unfortunately. I miss those simpler days.

I would say nobody at tech or hip company.

A lot of fortune 500 companies with some developers who missed the trendy stuff still do it that way. I made a medium size website (30 pages) in React with pure javascript and dependencies being script tags in index.html to vendored files.

So not even JSX. I did it that way because it was the easiest way to develop and deploy in that environment

Post reply on HN