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

Simple Systems Have Less Downtime

gkogan.co

Post reply on HN
Print view View original

71–80 of 271 posts

Re: Simple Systems Have Less Downtime

#71

Post by elbear »

emerongi wrote: post #47

The author is not arguing for simplicity per se, but about being able to insert a human into a system that is normally automated. The example about the ship's steering system is perfect, actually. The system is not "simple" (if I were on a ship and the steering failed, I would be clueless), but it provides plenty of interjection points where a knowledgeable human can step in and either debug or fix the issue. It's th…

How would a steering system that is simpler than that look like?

I think a key element is that this system is composed of parts that have one input. That allows a human to replace a component that failed and provide that single input to the next component in line.

Re: Simple Systems Have Less Downtime

#72

Post by aguyfromnb »

papito wrote: post #54

Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.

Sure,but the value of Instagram came from the fact it was a good idea, well executed,at the right moment in time. I'm not sure they managed to solve a ton of complexity with a small team.

Re: Simple Systems Have Less Downtime

#73

Post by XorNot »

tsimionescu wrote: post #55
monus wrote: post #7

Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well. This applies to programming languages, too.…

Go is actually a pretty complex language, more so than Java for example, in my opinion. It has all sorts of primitives that you need to get used to, special rules for how the built-in types work, there are all sorts of rules to see what creates a copy of a struct and what doesn't, pointers have at least three completely different use-cases (optionality, mutability, and avoiding copies), several rules for what can and…

I do wonder what the trade off would've been in Go if something like: a := b was guaranteed, under all expressible circumstances, to create a completely new copy - regardless of the content of b, unless it was explicitly a pointer.

It does frequently feel like this could've been solved by making basic slice assignment always go as a := b[:], and adding some type of syntax and checker where you needed to confirm that you were doing a not-completely immutable copy.

Re: Simple Systems Have Less Downtime

#74

Post by modo_mario »

monus wrote: post #7

Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well. This applies to programming languages, too.…

>On the other hand, Go (and Rust supposedly, but I don't have experience) is simple.

I was reading most if this yesterday which seems to disagree: https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...

Re: Simple Systems Have Less Downtime

#75

Post by XorNot »

ThePhysicist wrote: post #17

I don’t know, most systems like the container ship he/she described just seem simple but are actually pretty intricate inside. The logic behind them might be easy to understand, but the devil is in the details. A combustion engine is also simple conceptually: make stuff explode in a closed chamber to move a rod, convert that the movement to a rotation of a shaft. Super simple, yet I doubt I could debug many problems…

This seems like an oddly appropriate metaphor though - engines aren't super-complex once you know what everything does, but the biggest problem in car mechanics is just getting access to the specific part you need to measure or look at.

Re: Simple Systems Have Less Downtime

#76

Post by varjag »

upofadown wrote: post #63
hyperion2010 wrote: post #25

The only language that I have worked with that realizes that in the real world simple is _always_ a lie, is common lisp. It is the only language that has actually embraced the fact that its designers/committee were not geniuses and provided the tools for dealing with the complexity of the system. When unix tools fail, hope that you are on a system where it is possible to get the symbols and/or the source code, and ev…

>Lisp All those complicated lists? Forth is even further down the path to ultimate minimalism. Really only one data structure, a stack with binary values on it...

The point wasn't about minimalism.

Re: Simple Systems Have Less Downtime

#77

Post by lallysingh »

monus wrote: post #7

Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well. This applies to programming languages, too.…

No comment on Go. One pattern I've seen are tools that make easy things easier, but make hard things impossible.

Which is fine until the built system needs to grow. Then the pain hits.

Re: Simple Systems Have Less Downtime

#78

Post by dandigangi »

aguyfromnb wrote: post #72
papito wrote: post #54

Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.

Sure,but the value of Instagram came from the fact it was a good idea, well executed,at the right moment in time. I'm not sure they managed to solve a ton of complexity with a small team.

Has to be true. They were dealing with major scale pre-purchase. Also... talented set of engineers.

Re: Simple Systems Have Less Downtime

#79

Post by numlock86 »

> Modifications before additions.

> When new requirements come up, the tendency is to add layers on top of the existing system—by way of additional steps or integrations. Instead, see if the system’s core can be modified to meet the new requirements.

I like the mention of this as it is - at least to me - really counter-intuitive.

Re: Simple Systems Have Less Downtime

#80

Post by ptx »

vntok wrote: post #51
ailideex wrote: post #21

Earlier quoted context omitted.

Linux is incredibly simple compared to Windows once you actually your computer as a computer instead of as a really poorly made gaming console.

Try talking Grandma over the phone to help her share her photo directory with Aunt Jeanine, on the same PC. No command line allowed, and you know she can only focus on that type of task for 4, maybe 5 minutes top.

I can't imagine any system where you'd have a good chance of succeeding in that scenario without some kind of remote administration tool. Remote controlling a user over the phone is difficult, unreliable and time-consuming.
Post reply on HN