linkdd

Thank you for the feedback as well :)

> I'm better than most reading poorer copy but I consider your(unchanged) copy very good.

This is nice to hear/read, yet I'm a perfectionist who knows perfection do not exist. The pitch can always be improved and clarity/transparency is very important to us.

> Unfortunately without the words"audit", "WORM" and"incident search" present or prominent I'm not your market.

This proves my previous point, since we rely on Docker images to implement the monitoring/reactivity part, literally ANY workflow/business logic can be applied (but we've been told that it's hard to trust "it can do everything").

> But I could think of many thousands of publication sites longing for your tool, if those terms applied.

I'd love to get in touch with you about that, if you have time, you can find my contact info in my profile: https://news.ycombinator.com/user?id=linkdd

Thank you a lot for the feedback! We'll definitely do something about it :)

what's so wrong about sprinkling some jquery on a static website (generated with hugo or jekyll)?

On https://kubirds.com I use:

jQuery appear: https://plugins.jquery.com/appear/

jQuery fancybox: https://fancyapps.com/docs/ui/fancybox/

Do not put jQuery to the trash yet, it still have a long life ahead.

This already exist with the `with` expression, no?

This is great! It was about time!!

Add HTMX over any of them (me I use Python Django) and you're golden.

> Btw, I'm building easypanel.io

Looks awesome! Any plans on integrating with Kubernetes?

> I will draft something and get back to you for feedback.

My email is in my about -> https://news.ycombinator.com/user?id=linkdd

> What if we can standardize this process in some way?

Surely, this would be useful as part of a platform similar to Heroku where you plug your git repository and it would fetch such scripts and generate the Docker image.

It could be developed as a standalone tool that you integrate in your `git push my-heroku` hook, but I would not use it outside of that use case. Nothing beats copy/paste + some edits :)

> Also, we could have a configuration schema where people define the base images, copy glob patterns, etc.

Yes, copying files from stage to stage is quite a pain at the moment, that is why I have such a Dockerfile for every language I use, the copy glob pattern has already been done for 99% of my use cases.

You need to understand well your toolchain to know what to copy. For example, I did not yet write such a Dockerfile for Rust or Go, where I just do the usual "build + copy binary" multistage. No caching of dependencies :(

I have 3 dockerfiles that I reuse for every project, adjusting only little things:

They are all multi-stage dockerfiles to benefit heavily from caching layers and avoid running needlessly intensive steps.

[1] - Elixir: https://gist.github.com/linkdd/0a8d6e2019586d07c6587e42946a7...

This one suppose there is a Phoenix webapp, but most of the time I don't, so I remove the asset related steps.

[2] - Python/Django: https://gist.github.com/linkdd/4aac2c2efc4a51af6ca4b05f395de...

This one uses poetry and poethepoet (link in gist's readme) and other common libs that I use in every django project.

[3] - NodeJS backend: https://gist.github.com/linkdd/2a19e51f6158e53e89ff525544ac3...

This one uses yarn, I adjust the config files I add to the first stage depending on the project (quasar, vue3, typescript, ...)

---

They all use the same principle:

  - copy the config files into an empty layer (context)
  - copy the source code into an empty layer (src)
  - copy the test suite into an empty layer (tests)
  - copy the context layer files into a base image stage, install the production dependencies
  - copy the previous stage, and install the dev dependencies
  - copy the context layer, the dev dependencies, and the source code into a base image stage, run the CI steps (linting, etc...)
  - copy the context layer, the dev dependencies, the source code and test suite into a base image, run the test suite
  - eventually build the source code if the language needs it
  - build a final artifact from the built code (or the source code), the context layer and the production dependencies

If the Docker build passes completely, then the whole CI pipeline has been validated and the final docker image is guaranteed to be valid (according to your CI at least).

This works very well, and when i don't touch the yarn.lock, or poetry.lock or mix.lock for weeks, it speeds up drastically the builds on my machine and on the CI/CD pipeline.

Also, it allows me to migrate from one CI/CD solution to another (Jenkins, Gitlab CI, Github Actions, ...) without any hassle, as long as I can run docker build.

In a monolith they may be modules within a single application/binary instead of different services.

Nobody said a monolith can't be split in modules :)

IMHO, a well-written monolith is like a microservice architecture but without the network layer in between boundaries.

A few months ago I started a series of articles about Elixir, K8s and libcluser[0], but unfortunately I did not have time to continue it yet.

If you're using K8s, what I would suggest is:

  - create multiple releases of your Mix project[1] with specific OTP applications in each
  - one Docker container per release
  - one K8s Deployment per release
  - one headless K8s Service selecting the pods for all your deployments
  - use libcluster for automated cluster formation

Then, with node affinity/tolerations, you can control on which physical node you'll run it (if you want).

If you're not using K8s, you can use an Ansible playbook to deploy each distinct release on the target host, and you can use libcluster with a static cluster configuration. This will work the same.

[0] - https://medium.com/@david-delassus/elixir-and-kubernetes-a-l...

[1] - https://elixir-lang.org/getting-started/mix-otp/config-and-r...

Come to Erlang/Elixir (and OTP), you get the best of both worlds:

  - a mono repository
  - a single codebase for a single system
  - your micro services are supervisors and gen servers (and a few other processes) in a supervision tree
  - you decide which erlang node run which apps
  - your monolith can scale easily thanks to libcluster and horde
  - ...

Also, there is the midpoint between monolith and micro service, and this is called Service Oriented Architecture (SOA), you could have:

  - a DAL (Data Abstraction Layer) service
  - a Business Logic service (talking to the DAL)
  - an API (talking to the Business Logic service)
  - a Frontend (talking to the API)

Your API (or gateway, or whatever you want to call it) can serve as glue for third-party services (like Stripe, or anything unrelated to your business).

Microservices are a solution for an organizational problem, not a tech one. You need multiple teams to work on the same system without blocking each others. This is a solution for huge corporations, not your 2 pizzas team startup.

> all code goes under Apache 2 to maximise freedom of people to use that code for any purpose

GPL do not prevent using the code for commercial reasons, does it? IIRC, it just ensure that any derivative work is open-sourced as well. Which I would like to.

> rather than getting glory for it

It's really not about the glory, but more about ensuring that work done on the compiler can come back upstream, so that every one can benefit from it.

Usually I don't mind it, but in this case, if someone can do this better than me, I'd love to be able to learn from it.

Thank you for the links, I'll read them carefully :)

> but don't want to deal with the confusion around "Are binaries produced by the compiler bound to be GPL'd" kind of questions.

I'd like to avoid this as well :) But at the same time, I have a feeling that it would be best if all work done on the Letlang compiler could be OSS.

This.

I was able to read Erlang before knowing the name of the language. I discovered this language by looking at the source code of RabbitMQ, and I was surprised at how I could read it, knowing nothing about the language.

At first I thought atoms were variables defined somewhere (and I did not care where it was defined, the names were explicit). When I learned that they are in fact values, it blew my mind.

It's only 6 months later I started coding in Erlang. Then 3 years ago I started writing Elixir. I did not have to learn Elixir in fact, it was just another syntax for what I already knew.

I always recommend learning Erlang first with https://learnyousomeerlang.com/ and then learning Elixir. Simply because this book does a far better job at explaining OTP than the Elixir docs.

Maybe there is some value in writing learnyousomeelixir.com?

Sounds like Poker Chess (or Choker)

https://www.youtube.com/watch?v=UVx8l0y8rGI

Another approach would be using the "inverse" of the formula and then trying to prove that you can build all natural numbers starting from 1.

This approach, like every other approaches, did not yield any significant result.

The funny thing is that it fits right in the P=NP problem: easy to verify, hard to solve :)

I used TatSu back when it was named Grako, I really loved it.

But now, I discovered LALRPOP[0] and Logos[1] in Rust which is just so much more powerful, I'm using PyO3 to bring it to Python because I find it easier to walk the AST and do code generation from here.

[0] - http://lalrpop.github.io/lalrpop/

[1] - https://docs.rs/logos/latest/logos/

Chess, Factorio and Sudoku.

I have a huge library of games, none of which I play anymore except the 3 above

It is an ignorant one because without those, the industry would be far from where we are now, the cost of project development would be higher, security fixes would have a very hard time to propagate, leaving holes pretty much everywhere.

> borne of years of experience with these systems.

Which does not dismiss everybody else's experience.

> Hence the growing popularity of Go as a C replacement.

Fun fact: I've seen more Python projects being rewritten in Go than C projects being rewritten in Go.

Is Go a Python replacement?

I've learned to like Rust.

  1. You don't need to engage with the community to use a programming language
  2. The guys "ruining" conversations are a (loud) minority, most of the people I've talked with are light years away from proselytism

> We don't want the npm/pypi/crates/etc disease to infect Hare

That's a pretty harsh and ignorant statement.

Those repositories made developer experience much more enjoyable than the mess that is the C/C++ ecosystem.

A .rlib file then, that you can then add with:

  RUSTFLAGS="--extern closedlib=path/to/libclosedlib.rlib"

> In C/C++ there's no expectation of the code being anywhere.

That's not what I said. I said that most project do it this way anyway, regardless of any expectations. So who cares?

> I don't see how a VCS being popular is a reason to require it.

It is not required.

> Cargo is very opinionated, forcing upon you certain directory structures

No, it expects source code in `src` like most C/C++ projects anyway. Then it's `lib.rs` or `main.rs`. The opinionated directory structure (`pkg.rs` or `pkg/mod.rs`) is rustc not cargo.

> even a default VCS

Because it's the one used by most projects. Anyway, nothing prevents you from using mercurial, svn, ...

> Building multiple binaries and libraries from one project is a pain

Have you heard of Cargo workspaces? Because I've had no troubles with it.

> I think `gcc app.c` is way easier than using cargo

Agree to disagree. Because really soon, you'll want to manage dependencies.

But wood is so unsafe, it can burn, it can rot, you need to put the nails at the correct spot and most woodworkers are dumb enough to not do that correctly.

It should be criminal to build anything out of wood. Heard of forest fires huh? Guess what, they are made of wood!

---

Sorry, I couldn't resist.

I assume the closed source dependency is distributed as a .a/.so/.dll file, then you can use bindgen[0].

Still, yes it's a bit more complicated. But can we not pretend that the non-existent toolchain in C/C++ is easier in 99% of use cases?

[0] - https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...

Or SQLite - https://www.sqlite.org/whyc.html

Now add some dependencies, some required, some optional, for all platforms, or some specific to some platforms.

Then add configuration options for conditional compilation, and a build system to define them properly.

Then use the configuration options of your dependencies in your build system.

Finally, repeat this process for every project and make sure you use the same syntax/api for your build system so you don't have to relearn everything everytime.

cc main.c is as easy as it gets when you rewrite everything from scratch.

cargo is as easy as it gets when you want an ecosystem.