161–170 of 232 posts
I don’t think there’s anyone in the Elixir community who wouldn’t love it if companies would figure out that everyone is writing software that contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang, and start hiring Elixir or Gleam devs. The future is here, but it is not evenly distributed.
It sounds like they're looking for the Rust project Hydro [0]. EDIT: Lol nvm the author is one of the authors of Hydro [1]. [0] https://github.com/hydro-project/hydro [1] https://hydro.run/people
Just learn that there is another discontinued attempt https://serviceweaver.dev/
Earlier quoted context omitted.
> Whenever I would bring up this gap I would be told that we can't spent time and wait for people to create "magic tools". That sounds like an awful organizational ethos. 30hrs to make a "magic tool" to save 300hrs across the organization sounds like a no-brainer to anyone paying attention. It sounds like they didn't even want to invest in out-sourced "magic tools" to help either.
The real kicker is that it wasn't even management saying this, it was "senior" developers on the team. I wonder if these roles tend to attract people who get the most job enjoyment and satisfaction out of the (manual) investigation aspect; it might explain some of the reluctance to adopting or creating more sophisticated observability tooling.
Earlier quoted context omitted.
Had me confused for a second too, but I think it is the former that they meant. K8s has unneeded complexity which is really not required at even decent enough scales, if you've put in enough effort to architect a solution that makes the right calls for your business.
yeah sorry, double negatives. People got burnt by kubernetes, and that pissed in the well of enthusiasm for experimenting with distributed systems
If you’re architecture is poor k8s won’t help you
Earlier quoted context omitted.
Honestly, I am more cynical and just think people are always looking for ways to make their jobs more interesting than they actually are.
FWIW, at least one other comment seems to correlate job complexity with job security: https://news.ycombinator.com/item?id=43197623
Last month I switched from a role working on a distributed system (FAANG) to a role working on embedded software which runs on cards in data center racks. I was in my last role for a year, and 90%+ of my time was spent investigating things that went "missing" at one of many failure points between one of the many distributed components. I wrote less than 200 lines of code that year and I experienced the highest level…
Weak tech leadership? Let's "fix" that with some microservices.
Now it's FUBAR? Conceal it with some cloud native horrors, sacrifice a revolving door of 'smart' disempowered engineers to keep the theater going til you can jump to the next target.
Funny because dis sys is pretty solved since Lamport, 40+ years ago.
Earlier quoted context omitted.
I've found the rush to distributed computing when it's not strictly necessary kinda baffling. The costs in complexity are extreme. I can't imagine the median company doing this stuff is actually getting either better uptime or performance out of it—sure, it maybe recovers better if something breaks, maybe if you did everything right and regularly test that stuff (approximately nobody does though), but there's also so…
This is part of what I do for living. C++ backend software running on real hardware which is currently insanely powerful. There is of course spare standby in case things go South. Works like a charm and I have yet to have a client that scratched it anywhere close to overloading server. I understand that it can not deal with FAANG scale problems, but those are relevant only to a small subset of businesses.