You keep making the assumption that AWS == EC2, meanwhile it is just one of many services AWS provides.
You keep making the assumption that AWS == EC2, meanwhile it is just one of many services AWS provides.
Abstracting away is costly. You can target only the lowest common denominator. The abstractions are going to leak. It’s like the criticism of ORMs, only worse since SQL is at least standardized.
Python is for some reason darling of many, sometimes it has almost religious connotations. Meanwhile differences from e.g. PHP are mostly superficial and each has their strengths and weaknesses.
Bourne shell is orders of magnitude worse clusterf*ck than JavaScript, yet it’s rarely criticized.
Rust rarely gets criticized which isn’t necessarily a problem, since it’s IMHO a good language for its intended use case. But people tend to recommend it for things where the trade offs come out negative. (apps not needing max. performance)
In general I wouldn’t follow the trends on social media, it’s all a huge groupthink, mostly focusing on (easily avoidable) warts, and ignoring strengths.
Swallowing your pride, merging into another project and taking a less glamorous role in that project is not as easy as it was to fork when steering your project.
I don’t think it’s because of the ego. But if you’re working with other people, you need to do a lot of non-coding (non-fun) things. Align thinking, find compromises, establish and follow processes. Things are easier and more fun hacking alone. No processes to limit you, no one telling you “this doesn’t align with the vision of the project” (and the other way round - you don’t have to maintain code contributed by other people with use cases not interesting to you) etc. For volunteer FOSS contributors, doing fun stuff is often a big part of the motivation to give their free time to the community.
I agree. Rust has advantages, but none of them outweighs the negatives (complexity, difficult to find devs) for this particular use case.
I also agree that JVM would be a good platform. It’s both performant enough and simple/conventional enough.
has documentation which says it is meant only to be used for logging / debugging
No, it’s not a breaking change IMO. The method contract (the “debug” name, the comment) heavily implies the output may change and should not be relied upon.
I’m in a golden cage where my job earns about twice or more of what a large majority of remote jobs offer (available where I am, which is Europe).
I guess I could get very lucky and find a great paying remote job, but I feel like I could lose in the end.
People still want the money, tho. It’s the main reason I’m staying in my no-remote job.
RabbitMQ is more expensive on AWS than e.g. SNS/SQS. It’s not a coincidence, you’re trading lock-in for a cheaper price.
The increased complexity comes from the fact you will need some components which exist in either managed, but vendor lock-in form, or you need to spin them up / managed yourself.
Being cloud-agnostic also means additional cost/complexity.
Sometimes the only way to win the game is by not playing it.
QA of course contributes to the defects and features.
78 people contributed in the form of code commits, but more people likely contributed to the release in other ways (QA, triage, release management etc.)
But there were more contributors, you just don’t know how many. By this you’re kind of disregarding their work.
The obvious choice would’ve been to not use it and state the numbers plainly.
How would you write it?
The author of the blogpost is a developer, not a professional writer. Honestly I don’t understand why you’re so upset about it.
Maybe there were 78 committers. But other people contributed to the release in some other way (QA?), but that may be more difficult to count than just looking at the commit stats …
Who cares what OS the AWS machines are running? I can’t touch it, it’s completely inaccessible for me and other clients. I can only touch the services which AWS provides. I wouldn’t know the difference if it was running windows, since the OS is completely transparent, basically a hidden implementation detail.