fndrplayer13

I think this is likely the reality. I don't think this is necessarily a community problem so much as it is the reality of software development today. Most developers given the time and resources would probably enjoy making their libraries and applications as portable and flexible as possible -- who doesn't love to see their work reused? That being said, on a typical software delivery cycle you optimize for what you think _most_ people are using, and likely what you yourself are using -- standard flavors of Linux operating systems running in one of the big cloud providers. This is not to say Go doesnt have applications outside of this space -- it clearly does.

Health care isn't scarce in most of the first world. Many first world societies offer health care to all of their citizens, and those visiting their country. Much as we view education as a fundamental human right in the United States and no longer treat it as scarce, most other societies view healthcare as a fundamental human right. As a society and political system the United States has actively made the choice to pursue a profit-based, insurance-centered care model that is purposefully scarce.

Which is to say, I completely disagree that there is no other option.

I think this is a great summary. C++11 is a huge leap forward if you can start fresh and/or only target C++11 compatible systems. Personally, I've also been down the road of trying to get older systems (also RHEL6) to run C++11 code via a hand-built compiler and it was an exercise in absolute frustration. And yes, Boost was the answer to some of this. Another thing you can try if you're in a well-abstracted code-base is to write wrappers around some of this functionality. Eg, if C++11 or greater is available, use the STL functionality, else use Boost and/or whatever legacy thing we hand-built. The obviously crappy part of this is that your functionality can/will diverge on multiple platforms.

Have we seen similar levels of damage in other cars that carry large battery packs and have been in head-on-collisions?

I dont really have any commentary one way or another about autopilot or the safety of batteries, I'm just thinking there are probably other accidents that have happened in the industry in similar conditions to this.

For example, the Prius and Volt have been on the road for quite some time, and both cars carry relatively large batteries (though certainly not as large as that on a Model X). When involved in head-on collisions do they see such drastic damage/fires?

Just curious. I don't know that its even fair to compare those types of vehicles given the difference in the size of battery.

Having built programs that used the ffmpeg libraries (as well as x264) I have to say that a tutorial that is up to date and recent like this would have been very helpful at the time. Glad to see somebody is undertaking this effort.

I think its very exciting they were able to get the number of discrete modules up to 26. That's extremely impressive to me given the age and complexity of Java! I went to a talk a few years back from one of the contributors to this project (forget the name, sorry!) and I think if my memory serves me they had significantly fewer discrete modules at that time -- perhaps 6?

Anyhow, I think this is a great step forward for Java.

I agree with this assessment. We decided to do "kubernetes the 'sorta' hard way" by leveraging the Saltbase installer with some level of customization and full control via terraform of how our infrastructure was being allocated. I think its valuable to learn what the tool is doing if you have to maintain it. When something breaks, an upgrade has issues, or you need to better understand the system to make a decision, I feel that you gain a lot in setting up a system yourself. I think you'll be more likely to know precisely where to look to debug things. You also get closer to the tool which makes it easier to contribute back into the community. You also get the benefit of making your own infrastructure decisions. Yes k8s can provision ELBs and EBS volumes (and their equivalents in Google Cloud, Azure, etc) as well as autoscale nodes via a cluster addon, but the big moving pieces, such as instances, VPCs, Networking, etc, remain well-defined in Terraform or some other infra-as-code. That means that you can decide how to deploy that etcd cluster, how it gets backed up, whether or not its encrypted at rest, etc. Generally speaking, we just value the level of control and insight that we get out of controlling the stack definition ourselves. To some extent that may be antithetical to the purpose of k8s, since the goal of the project overall seems to be simplification and centralization of best practices of deployment.

With all that being said, kops is an incredible tool (as are others) and we used it to learn about the system and test some of the functionality for ourselves. Can't recommend it enough.

I appreciate the responses everyone. Glad to be set straight on some of this stuff.

Great set of resources -- I just went through the process of defining a terraform cluster in AWS over the past few weeks, though I'm leveraging the k8s Saltbase installer for the master and nodes.

I'm curious, why no mention of AWS as a provider for roll-your-own? Is this a cost thing?

Also, I get the feeling that Ubuntu is _not_ a first class citizen of the k8s ecosystem, but perhaps my newness to the ecosystem is to blame here. The Saltbase installer, for example, only supports Debian and RHEL distros, `kops` prefers Debian, and the documentation for cluster deployments on kubernetes.io and elsewhere also seems to be somewhat suggestive of Debian and Core OS. Perhaps thats just a mistaken interpretation on my part. I'm curious what other peoples thoughts on this topic are!

thank you, I totally missed that.

That's awesome!

This may be a silly question to ask, but forgive me, I dont know much about EE or battery technology:

Its my understanding that current batteries found in mobile phones, laptops, etc make use of rare earth minerals which are limited and expensive and only available from big players like China. Does anybody know if this technology also makes use of rare earth minerals?

Enjoyable read, and I think for any experienced developer there's at least a _bit_ to relate to in there.

But seriously, this is why you have an integ/staging environment :)

And obviously, better developers.

I loved being an embedded developer. Loved it. I had been out of college for 4 years and thought that the work at startups would be even more exciting. I took a job as a backend developer at my current company because I was really excited about the technology they were working on from a conceptual level, and I still am. I transitioned from working on computer vision/image processing embedded work to natural language generation stuff in AWS. The AI aspect just generally excited me, but so did expanding my skill set in a much wider sense. Today I can talk about embedded concepts all the way up to AWS concepts like lambdas, cloud formation, etc. That's a pretty cool breadth of skill (notice I didn't necessarily say depth :P). I still feel like an embedded developer at heart, though. I'll go back to it someday.

Agree that swift (and other languages like Rust for that matter) offer some very nice advantages over C++. However, C++ is so well established and has a rich collection of libraries and integrations. You can write a library in C++ and ship it on nearly everything. You can also optimize the parts of your system that are well-suited to a systems-language like C++ and then easily expose them in other languages like Python, Ruby, Go, Swift, etc. via their C-bindings.

We can't say that (yet) about Swift and Rust. In 3-5 years I think this is going to be a very different conversation, though.

In my mind, C++'s flexibility is both its greatest benefit and its greatest danger. You can do almost anything, and there are so many ways to do it. I agree this is a "problem" that's likely not going to be fixed. You can ask your fellow developers to read Scott Meyer's Effective (Modern) C++, you can go to meetups, listen to the wisdom of the steering committee, etc. but at the end of the day it really boils down to the fact that your team needs to be committed to being resilient and responsible. That's true in any language, but much more so in C++.