121–130 of 159 posts
Earlier quoted context omitted.
why is that a perceived benefit By contrast, Kubernetes has at least 1000x more developers working on it
1000x developers sounds like a huge red flag. It’s way too complex already.
For comparison, IIRC WebKit had like 500 contributors as of five or six years ago.
* for the umpteenth time i daresay that hn needs to grow a sense of humor sometimes...
Lighten up folks.
I don’t care about Kubernetes, but someone might read this post and decide that it is a good idea to “simplify” an existing project by rewriting it in 17000 lines bash script. And some hapless person will be stuck maintaining and debugging it. It could be me, or you, your friend. You don’t want this to happen.
tbf the maintainer of Simplenetes throws an incredible amount of shade against Kubernetes
That's shade?
Earlier quoted context omitted.
You can't be talking of Spring Framework!? That's a 2000's solution (in particular Hibernate) trying to stay relevant.
Asking to learn, but if you were to start a Java application in the following two scenarios: 1) Monolith with some CRUD, API, persistence to a DB + search. 2) Scalable backend with an API, persistence to a DB + some caching what would you use these days?
Earlier quoted context omitted.
Where?
- "Let's put the Dev and Ops back into DevOps." - "Simplenetes doesn't go there because that is when DevOps becomes MagicOps." - " You enjoy the simple things in life."
The easy stuff:
- Non-exported variables are by convention lower_case, while exported variables are UPPER_CASE.
- Function names are by convention lower_case.
- There's a "quite" signature string and variable; should it be "quiet"?
- The lines like `local hosts=` can be simplified as `local hosts`. You can also join such lines, as with `export`, into `local foo bar baz …`.
- `[[` is generally considered more reliable than `[` (there are a bunch of posts about this on Stack Overflow and Unix Stack Exchange).
- Naming scripts .bash rather than .sh lets `shellcheck` inspect them without telling it which shell to verify against. You do check these files using `shellcheck`, right?
- Variable names like `list` and `tuple` are unhelpful; what do they actually contain? Also, they should probably be actual arrays rather than a space-separated string to avoid relying on word splitting, and to allow entries with whitespace in them.
The scary stuff:
- All the string packing and unpacking also makes me nervous. That's not simpler than using JSON/YAML, it's just a different kind of complexity.
- Reusing the same variable a bunch of times in the same function makes it really easy to end up with the wrong value at some point. Better to split stuff into more functions or rename the variables to make them single use.
- `set -o errexit -o pipefail` would be good to have for safety.
- `kill -9` anything[1]
- Why are some of the variables inside functions not local? They effectively end up being globals, which makes for really difficult debugging.
The good stuff:
- Using local variables everywhere.
- Descriptive error messages.
- Returning early in case of errors.
All in all, Bash is not a good language for any system of this size, no matter how diligently you program. The error handling isn't comparable to most mainstream languages, the data types are incredibly limited, and there's no native support of recursive languages like JSON. You've done a great job, but I'm afraid a system like this is doomed to failure from these facts alone.
[1] https://mywiki.wooledge.org/ProcessManagement#I.27m_trying_to_kill_-9_my_job_but_blah_blah_blah...