Live data from Hacker News

Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

github.com

131–140 of 159 posts

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#131
post #130

Unsolicited review of sync.sh ahoy! 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 …`. - `[[` i…

Thanks for taking the time l0b0!

A lot of good points.

Coding in shell sure is a challenge, I try to avoid bashims where I can, that's why most scripts are .sh not .bash, since they run also with dash/ash (that's why preferring `[` over `[[`).

The only Bash requirement we have is the `podc` (pod compiler) since it parses YAML docs, I couldn't pull that one off without the more powerful Bash.

The code base as a whole absolutely needs testing and shellchecks all over the place to be labelled as mature in any sense.

Our other large shell project is Space.sh [1] where go overboard on testing, each module is tested under a bunch of distributions. [2] [3] Next step would be to do the same for Simplenetes.

Given that in shell that the only way to protect a variable from functions down the call stack accessing it is to redeclare/shadow it as "local" brings some murky waters.

BUT, isn't it amazing what is actually possible to do with Shell??

For me Simplenetes in the long run is not about it being written in Shell, I'm perfectly happy rewriting it in Rust if we get traction on it.

Simplenetes is primarily about having a simpler architecture of what a container cluster is and is not. I think many projects just get too complex because they want to fill every single use case out there, while the interesting part is saying no to things.

[1] https://github.com/space-sh/space [2] https://github.com/space-sh/space/tree/master/test [3] https://github.com/space-sh/space/blob/master/.github/workfl...

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#132

- No magic involved says the one with a single file 13k LoC shell script.

You are looking at the `./release/sns` file, which is the "compiled" release, it's like looking at the .exe (404 kb isn't that bad for an ".exe")

The source files involved are smaller [1].

[1] https://github.com/simplenetes-io/simplenetes/tree/master/in...

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#133
post #106
post #75

Earlier quoted context omitted.

i must say though, i'm not sure how i feel about a shell script "daemon"...

Daemon is just something running in a loop.

actually no. there are a bunch of properties to properly daemonize in unix. things like special handling for stdin/stdout/stderr, reparenting, signal handling... look it up.

classic rookie mistake to just call a program that doesn't exit a daemon...

proper daemons can stay up for years.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#134

The whole setup of github project looks like it is a serious attempt.

Woe to ye if hn decides your project is Not Fun

I don't understand your type of comment. If people involved with a project decide to advertise it on HN, specially following questionable clickbait methods, is it reasonable to demand that all posts must be exclusively comprised of high praises and compliments?

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#135
post #71

The amount of vitriol in this comments section is astonishing. Can we not share fun projects without the professional Kubernetes experts thumbing their noses? At the very least, it does seem now like the complexity of K8s’s code base is a point of very thin skin for the community.

The peoples who criticize that project should be remained why Unix even came to life.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#136
post #71

The amount of vitriol in this comments section is astonishing. Can we not share fun projects without the professional Kubernetes experts thumbing their noses? At the very least, it does seem now like the complexity of K8s’s code base is a point of very thin skin for the community.

Thank you aabhay for a nice comment. Seems like my click-baity title brought out some strong feelings :) I do actually like Kubernetes. I recommend it to clients, I assess candidates who are to work with it, but I do really think it is a Beast. Because it is. Kubernetes is like C++, extremely useful but it just keeps growing and nobody really knows all of it. While Simplenetes is like... Lua, batteries not included,…

You just described every other software project. ‘It keeps growing and nobody really knows it all’, story of my life.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#137

Earlier quoted context omitted.

A new Java application? Java is getting pretty long in the tooth. You might be better off building on top of Go or Rust, especially for those specific scenarios (Go in particular was designed to build network services.)

"Lol!", Thats what you would get in response when you tell that to the major enterprise customers.

When I did enterprise sales, we had another phrase for that: "No one ever got fired for buying IBM." (Coincidentally, I also worked for IBM, back in the day.)

While it's true that tech choices are signals that enterprises do use to determine quality, if you are relying on a particular choice of programming language to sell into major enterprises that's simply a mistake. (And enterprises have invested vast sums in technology written in c# or PHP, so clearly it's not all "lol" out there.)

Rust's and Go's capabilities of compiling into a single binary, without requiring a JVM that needs to be fed and cared for, make them a particularly compelling choice for enterprise deployments. Kubernetes itself is written in Go.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#138
post #134

Earlier quoted context omitted.

Woe to ye if hn decides your project is Not Fun

I don't understand your type of comment. If people involved with a project decide to advertise it on HN, specially following questionable clickbait methods, is it reasonable to demand that all posts must be exclusively comprised of high praises and compliments?

> specially following questionable clickbait methods

The title seems both true (for the author's situation) and falsifiable. I don't think it's clickbait.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#139
post #28

Earlier quoted context omitted.

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?

Not in any particular order (choose what fits your team): Kotlin or Java and a lighter framework (e.g. Javalin is to Spring as Sinatra is to Rails, with JDBI), a newer big framework (e.g. Micronaut, maybe Play, others), Phoenix/Elixir, Rails/Ruby+Sorbet, Go with libraries. Edit: I just did a google search for "Java Framework" and get a lot of useless top-N lists with old content retitled "in 2020" with hits like: Hib…

Cmon, you can't be serious, do you really recommend Play, Micronaut, etc. over Spring ecosystem? Also if you want the benefits of GraalVM you can stay in the ecosystem today with Spring Native, moreover if you are ideologically against Spring then you should go with Quarkus because that's the next technology by maturity/popularity. How can you not go with Spring when REST services are today a solved problem? Why do you want to turn it into a problem by adopting something else that is not battle tested? In the company that I work for, Spring is ruling the microservices layer and we have a combination of Scala and Python for data pipelines that are not related to the behavior of the business logic, they only know one thing and that is data. Hibernate has not been a problem for us, I can say that I totally recommend it when you have multiple people working on a project, rather than polluting the codebase with raw SQL.

If you really want something exotic in Scala that is impossible to express in Java, Go, Ruby, Elixir etc., then take a look at the Typelevel (cats, cats-effect, http4s, doobie) ecosystem or ZIO. If purely functional programming is your cup of tea.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#140

Earlier quoted context omitted.

"Lol!", Thats what you would get in response when you tell that to the major enterprise customers.

When I did enterprise sales, we had another phrase for that: "No one ever got fired for buying IBM." (Coincidentally, I also worked for IBM, back in the day.) While it's true that tech choices are signals that enterprises do use to determine quality, if you are relying on a particular choice of programming language to sell into major enterprises that's simply a mistake. (And enterprises have invested vast sums in tec…

Linux itself is written in C, though everything runs on it. Who cares about the language that Kubernetes is written in (by the way, it used to be Java but it was changed politically to Go)? If you are writing Java/Scala you can use GraalVM to achieve the same thing that Go does. If your service is mainly doing data processing, then Go won't help you there because its abstractions are too low-level or even non-existent. A Java service/app won't require a JVM if you you create a self-contained application package. Applications can be deployed on fresh systems with no requirement for the JRE to be installed. The advantage is that you control the version of the JRE used by the application and the disadvantage is that application updates are the responsibility of developer and self-contained applications do not have built-in support for automatic updates. Exactly why for services I wouldn't recommend it, and neither Go or Rust. I would never trade the state-of-the-art garbage collectors that the JVM provides me with the ones of Go or the borrow checker of Rust (though I would take Rust anytime over Go). I can't help myself but only think that you comment is straight from the 90s when it comes to the JVM ecosystem.
Post reply on HN