Imagine going to a project like Rails and trying to convince them they should use C# instead because its better than their language and everyone is wrong. Then if they refuse to change you start going on social media shit posting how all of them are wrong and and they should use the language you decided is king.

I think Linus was happy for people to use Rust peripherally, but then they needed changes to the kernel and slowly wants to infiltrate every other project to become rust dependent. This didn't sit well with other maintainers as they use C and arguably don't want or need to deal with Rust. The same they don't want to use Zig, V or C++. You're welcome to develop your driver in Zig, but don't expect others to change their code for you so you can be happy.

clj gives a different way of thinking (imho better), but alas even introducing algebra to geometry had push back, and so will anything that upsets the norm.

Another equally important benefit of clojure is its stability, i.e you can write a script today and it will run weeks/months/years/decades afterwards, the same cannot be said for js.

This is all known to people already using clj and cljs, and now we can keep enjoying our clojure on nodejs also :)

note: there is a misconception aparently that clojure does not support mutability, it does, just does so in a sane way so you dont shoot yourself in the foot. So yes you can mutate in clojure, and yes you can have side affecting stuff, clojure programmers do so every day .

self promotion * You did ask how people do it :), this is my way, Ive written my own service which has been in production for more than 3 years, http://pkhub.io (if you would like to try it send me an email to admin@pkhub.io). This was before aws secrets manager, the tooling is usefull cause I wrote: running your app with its needed secrests dev/stage/prod, accessing dbs, downloading and installing ssh keys to ssh agent, utilities.. end

of course you could write all these yourself with aws secrets manager.

there is hashicorp's vault but tbh it always seemed like way to complicated to setup.

my advice in general would be: to get something secure but simple enough that your engineers can do their work and access the resources they need, without the oh only bob has the keys on his laptop situation.

I strongly have to insist that when sharing credentials/passwords you should be using a service like a secrets manager or password manager, ideally you'll use my service https://pkhub.io :)

This quick share mechanism is made for that time when you are about to send a password over slack and delete it afterwards. You know its wrong but its just so convenient :/

With https://pkhub.io/securesend you can send it, have a optional passcode and the message expires either on read or after the expire time set.

The advantage is the message is not somewhere in a text transcript that can be harvested, and is deleted permanently after expire. Its also stored encrypted where only the link holder can decrypt the message.

The link will be available for harvest if you send it over email or slack but the temporality of the message solves this i.e the link becomes useless after the message expires.

Comments URL: https://news.ycombinator.com/item?id=20614968

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=20292342

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=20208365

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=20106886

Points: 5

# Comments: 0