That almost all software is unreliable and SaaS products only work because there are engineers behind the scenes fixing it all the time.
The Wizard of Oz nails it:
"Pay no attention to that man behind the curtain"
3,151 karma · joined June 7, 2011
The Wizard of Oz nails it:
"Pay no attention to that man behind the curtain"
These were my points:
1. Performance improvements of interactive programs below a certain threshold are imperceptible and therefore of negligible value.
2. A minimalistic program does not always lead to better performance.
3. Compilation involves trade-offs and binary size and the number of syscalls executed are not the only things that matter.
4. The syscalls emitted by these programming languages are there for a reason and provide significant value to developers and users.
I nowhere stated that memory was cheap, but I agree that CPUs are fast.
As for latency, quibble with the numbers, but I don't think a user will ever notice the few hundred microseconds difference between the Go version and the ASM version.
> But that's beside the point, which is that all these programs are doing a lot of things you didn't ask for and take megabytes to do that.
Yes. And it both doesn't matter and optimizing them away has drawbacks.
Theoretically the points in the original article could matter - writing a very simple tool with Electron for example. But the example given wasn't anything like that.
I kinda think any other car company could make the cars Tesla does more efficiently.
But then again who knows :).
1. The advent of an artificial womb will toss a wrench in the abortion debate
1. Civil war in China
2. A new, significant non iOS/Android OS in mobile
3. Uber/Lyft will gradually shift to a unionized, national taxi company
4. Nothing significant will be done about Climate Change, and it won't matter. Some new environmental issue will be talked about instead.
5. A third political party will become significant in the US
6. There will be a major Christian missionary movement from the global south to Europe
7. VR gaming won't be much of a thing (ie like 3d movies)
8. Tesla will go out of business
9. Commonplace purchases will increasingly be made with point-of-sale loans and/or monthly leases. This will increase economic disparity (rich people will buy stuff / get better rates, poor people will rent things / can never get ahead)
10. Software development will still be a relatively specialized, niche field, with most people not knowing much about it. It won't be more "diverse"
11. Health insurance, higher education, housing and tax preparation will all still be crazy complex and expensive in the US
12. You'll finally be able to pump your own gas in New Jersey
13. Most churches will lose their tax exempt status
14. Texas will have more people than California
The point about maintenance is a good one if you're running purely static sites. K8s has a steep learning curve, though FWIW I think its probably easier than systemd and standard unix administration + puppet/chef/ansible/etc.
Amazon's original fix reduced performance substantially, which lot's of people noticed, but no one knew why till the vulnerabilities were announced.
Meanwhile Google built a clever workaround which minimized the pain. It was really a mic-drop moment from Google and I wish someone would dig in deep and tell the whole story.
At this point I'm sure AWS has merged Google's patches, but it showed how much Google was investing in their GCP offerings.
If you feel like Uber is doing something wrong there's a trivial solution. Just pay your driver more.
Sure it doesn't solve Uber's problems, it doesn't change the behavior of anyone else, but it does solve your personal culpability. (If you feel you have such culpability)
I suspect a significant number of riders are pretty well off. Why not be exceedingly generous? Tip the driver 10 or 20$.
Featurewise:
- good support for updating status in github
- haven't tried Jira
- it supports artifacts which can be stored in s3
- you can use docker to build most programming languages and there are plugins for some functionality
- you can also install additional things on your worker nodes which could be available when you run your build
All in all its probably less-featureful and will require a bit more setup, but it gives you more control.
I have also used Google's cloudbuild for personal things and like it OK. It uses cloud-builders: https://cloud.google.com/cloud-build/docs/cloud-builders. If you set it up right its pretty fast.
That is not what motivates many people who care deeply about this issue. Its partisan spin used to malign a contrary view. Believe it or not many Republicans are not racists hell-bent on denying minorities the right to vote. I know it seems impossible, but some Republicans even are minorities.
> What does exist, however, are coordinated ballot-harvesting efforts designed to unduly influence the outcome of elections, as was witnessed in NC-9 in this past election. But again, the GOP doesn't seem to be very concerned about this specific issue.
A lot of Republicans in California complained about ballot harvesting.
FWIW I agree that voter fraud not a major problem. And neither is vote hacking.
Both sides play footsie with these issues and its dangerous as it undermines the credibility of the system as a whole. If you believe elections are stolen or democracy is dead, then the American government is illegitimate. How long till we're advocating ignoring its laws, or overthrowing the regime.
Another civil war is the last thing we need in this country.
A slightly corrupt system that we collectively pretend is pristine is far better than the alternative.
Apparently some Republicans support this bill. I bet there are some Democrats that don't support the bill.
Partisan reductionism presents an overly simplistic view of a complex phenomena.
And bills don't represent ideology anyway. They often have unintended consequences. Politicians might be interested in fixing a "vulnerable system" while rejecting a particular bill for some other reason. For example: Voter ID.
The Secure Elections Act was introduced by a Republican: https://www.congress.gov/bill/115th-congress/senate-bill/226....
The unstated assumption here is that you have a pile of offers from Amazon, Google, Microsoft, etc along with some from startups and you have to make a decision about which to go with.
I suppose my experience might be unusual, but I don't think that's typical. You've got an offer on the table, and your choice is to go with it, or reject it and hope you're given an offer by some other company.
I've seen it go both ways. Maybe the next week you do see the better offer. Or maybe 3 months later and a few dozen rejections later you've got nothing to show for it.
So you take what you're given.
Also there's a big difference between throughput and latency. Networking might introduce a longer delay than a CPU call, but if each one of those calls does significantly more work, the overall performance of the system can increase.
This brought to mind John Calvin's Institutes. In the first chapter he suggests that knowledge consists primarily of two parts: knowledge of self and knowledge of God, and oddly, the best way to know oneself is to know God:
> If, at mid-day, we either look down to the ground, or on the surrounding objects which lie open to our view, we think ourselves endued with a very strong and piercing eyesight; but when we look up to the sun, and gaze at it unveiled, the sight which did excellently well for the earth is instantly so dazzled and confounded by the refulgence, as to oblige us to confess that our acuteness in discerning terrestrial objects is mere dimness when applied to the sun. Thus too, it happens in estimating our spiritual qualities. So long as we do not look beyond the earth, we are quite pleased with our own righteousness, wisdom, and virtue; we address ourselves in the most flattering terms, and seem only less than demigods. But should we once begin to raise our thoughts to God, and reflect what kind of Being he is, and how absolute the perfection of that righteousness, and wisdom, and virtue, to which, as a standard, we are bound to be conformed, what formerly delighted us by its false show of righteousness will become polluted with the greatest iniquity; what strangely imposed upon us under the name of wisdom will disgust by its extreme folly; and what presented the appearance of virtuous energy will be condemned as the most miserable impotence.
In particular the concept of the Image of God has profound consequences for the way you think about dignity and human personhood.
I recently watched Won't You Be My Neighbor, the documentary about Fred Rogers, and was struck by the way he treats an interacts with people, not as means to some end, but as ends in themselves, with real dignity and respect.
It was counter-cultural at the time, but boy is it strange now. It feels like everything is outrage and disingenuousness. We treat people like tokens of their tribe, with pure contempt and toss them aside like their worthless and inhuman.
Maybe Calvin was on to something.
This is all a bit abstract. There are plenty of go libraries which are suitably mature for production use. For example Google's cloud libraries or Amazon's AWS libraries. There's a platform for communication of issues and releases: Github. I guess I haven't really had an issue with it... The only problem I've had is the messiness of versioning, but there's been solutions to that for a long time (godep, govendor, glock, etc...)
> To the second point about per-thread caching, Go does not expose threads to end-users. So, there's no concept of thread-local. What you're describing results in lock striping, which has contention issues as described in the post.
Sorry for the confusion. I did not mean thread-local variables. I meant breaking up your workload across mutiple goroutines so that you don't have to use shared state.
For example suppose you receive a message with an org ID. You start 8 workers, all data for (id % 8 == 0) goes to worker 0, (id % 8 == 1) goes to worker 1, and so on.
Each worker maintains a local map of data and no mutex is needed to coordinate access, because only one goroutine can use the data at a time. So there's no lock-striping and no contention issues.
This is the recommended approach for Go concurrency:
> Do not communicate by sharing memory; instead, share memory by communicating.
I understand that this sort of approach doesn't work for every problem, there's not always an easy way to split up the data like this (you might end up with hotspots for example). But I feel like that conclusion needs to come after a bit of reflection, instead of reflexively reaching for a global object + mutex. (Not saying that's what you guys are doing... just a common issue I've seen working on distributed systems with developers new to Go)
There is a cultural skepticism about the overuse of packages. There are occasions where the STD lib copied a function instead of adding an import for example. Like many things in Go this pushback is needed but sometimes goes too far.
But maybe single function packages in npm we're a bad idea.
Anyway caching is a mixed bag in my opinion. Local per-thread caching is often better than a global cache as it avoids contention. It's also trivial to implement with a map and requires no special coordination.
It does require rethinking how you design a solution to a problem. FWIW that design process tends to lead you down a better direction anyway for producing distributed systems.
For example one giant, randomly distributed Kafka topic with a global redis db for a cache is probably a lot worse off than a system with more predictable data locality on the consumers.
Average humidity during the summer: Austin: 90% Mobile: 100% Miami: 100% NYC: 54%
It's not even close.
Maybe its because people are outside more in NYC and don't have a car readily available with AC torqued to full blast? Or less buildings have AC / the subway is oppressive?
Miami is 90 degrees. And Austin is humid too.
And there's no comparison to NYC, which isn't even usually above 90 degrees.
It's the baptist and bootlegger problem: https://en.wikipedia.org/wiki/Bootleggers_and_Baptists
> "Such a coalition makes it easier for politicians to favor both groups. ... [T]he Baptists lower the costs of favor-seeking for the bootleggers, because politicians can pose as being motivated purely by the public interest even while they promote the interests of well-funded businesses. ... [Baptists] take the moral high ground, while the bootleggers persuade the politicians quietly, behind closed doors."
Also FWIW configuring Linux machines manually over SSH and building and deploying your code too it, isn't always easier. Make sure you write everything you did down, because in 6 months you will completely forget how you built this thing, where it was deployed, etc...
For academic research Twitter offers products which dramatically reduce the amount of data you need to consume via the full search API or historical powertrack.
So just rewrite all our code in Erlang, including off the shelf products we didn't write?
Then use some other technology to deploy the software, configure the machine, come up with a way to do service discovery, attach block devices to nodes, and automatically provision new machines based on resource usage?
It doesn't make sense yet it's seemingly repeated on every thread about Kubernetes.
The Erlang community should celebrate technologies like Kubernetes, Mesos, or any other number of resource scheduling systems because they're finally the industry taking seriously the problems addressed by Erlang.
We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time.
In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of the autoscaler nodes are dynamically provisioned when needed, and then removed when the test environment is destroyed. That's pretty nice functionality you get basically out of the box. On EKS anyway. There are some occasional rough edges, but I think the decision to use k8s for this makes sense...
At some point we'll migrate prod too.
Kubernetes has a lineage as well... Based on the Borg project at Google.
I guess I'm not seeing why these things are being compared. Aren't they solving different problems?
Go's concurrency features are formally specified, are not ad-hoc (they are a major feature of the language, and the product of multiple language design iterations) and are certainly not bug-ridden.
Or are you talking about using Kubernetes to manage workloads on machines?
How does Erlang solve running my python webapp or my SQL database on my ec2 nodes, or in the case of this project, on an IoT device.