Since setting up a business in 2016, I needed to better understand how to build a business:
Principles by Ray Dalio - I found this really motivating to ensure our business sticks to and has a set of principles that evolve based on mistakes made (sounds obvious).
Hard Thing About Hard Things by Ben Horowitz - I loved listening to this (audible) because being a CEO can be lonely and hearing other peoples thoughts and advice based on their experience (that you can relate to) is really uplifting.
2018 has been a great year for us and I do think these books have helped me get through the roller coaster that is building a technology startup.
Vanadium batteries are very promising, however the energy density is the main issue here. Lead Acid batteries have a better ratio however obviously lead is toxic and it requires more than just lead.
The fact that Vanadium batteries capacity is limited to just the size of the tank (slight oversimplification) is a positive for sure, their life span is also a positive factor. It also, while classed as toxic, is not classed a seriously hazardous.
Like most redox/flow batteries they have a very big shortcoming and that is a very limited operating temp range for vanadium it’s 10-40c that means they’ll need environmental controls installed in almost every case.
Given that these batteries would be used mostly in stationary applications, where space is less of a problem, the only question is how much extra power would the heaters and/or coolers need, and how much waste heat the charge/discharge releases (some of the waste heat could be used instead of the heaters, but would put more demand on the cooling system). Unless the amount of waste heat is too high, it doesn't sound like too much of problem to me; given proper insulation, most of the heat would come from the battery itself.
Cooling/heating Li-Ion batteries which have a wider range and are mechanically easier to cool than liquid Redox batteries is a big challenge, this one is a much bigger one.
Modern Li-Ion can operate at 0-45c in "fast charge" and there are even higher ranges being developed, there is a huge difference between 10-40 and 0-45 as far as suitable environmental locations go.
Li-Ion can be charged at 0c or even below in some cases, with Vanadium Redox you get crystallization at 10c and the battery stops working it's not like Li-Ion where you lose some charge and you need to charge at a lower current and the charging it self will bring back the inner temp of your battery pack to fast/full charge levels.
That article is very low on actual electrochemical details. Here's one of the research papers on high performance salt water electrolyte batteries: http://sci-hub.tw/10.1126/science.aab1595
I don’t think it’s fair to say they ignored advances in modern programming languages. There are opinionated reasons for the omission of generics and they do make sense in the overall architecture of the language. At the end of the day it’s about trade offs and ultimately my opinion is that, having written a lot of both C# and Go, I can see the pros and cons of feature sets. Its about choice of tool for the solution in mind. I’m happy with that.
Absolutely! The "advances" were design decisions that go chose not to use. The people who designed golang are not newbies. They didn't ignore anything, nor were they ignorant of other languages. They had good reasons for choosing to go another way that makes sense for their language.
The end result is, in my humble opinion, a very stable language that is very high performance, and is highly maintainable. It's not perfect. It's not great for every use. Java does some things better. C does some things better, etc... It just fills a niche that was unfilled in an opinionated manor.
> The people who designed golang are not newbies. They didn't ignore anything, nor were they ignorant of other languages.
Chalking everything missing from go up to "the designers know what they are doing--every omission was on purpose", ignores the way humans design things. We are really good at post hoc rationalization.
Bob: "Why did you draw the woman in tall grass?"
Alice: "To allow the viewer to engage with the piece by forcing them to use their imagination to visualize the hidden area."
Bob: "Are you sure it's not because you don't like drawing hands and feet?"
At the same time critiquing without understanding the problem the engineer was trying to solve is equally easy.
Go is far from perfect, I just don't agree that lumping things in a good/bad pile is very insightful.
Engineering is all about making compromises. It's unsurprising that you'll meet everyones use cases that it's not designed for. The article would have provided additional value if it explored alternatives to the bad, and the disadvantages that come with them.
They are talking about things like generics. Considering the years it took for a team of people to build Go, I think it’s fair to assume they didn’t just forget about generics and that it was an intentional decision.
I think one thing that people get caught up in with Go as well is... well it's stupid easy to learn and work with.
I work for a giant enterprise company and the range of programming talent that we have is incredible. I know some people that couldn't code there way out of fizbuzz. Unfortunately, getting these folks onboard to learn the functional abstractions doesn't always sell (especially to the biz folks).
One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.
My 2 cents in the bottomless well of programming language opinions.
> One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.
And then what? They find themselves duplicating the same code again and again because Go doesn’t provide good abstractions to reuse code. Or that they write a ton of code to do what could be achieved in a few lines in a reasonable language.
You learn the language in a week because there is not a lot to learn. Shell scripting is simple to learn as well, but nobody is building anything beyond short scripts using it.
An ideal language should allow the user to be a productive after a short time, but should have have enough power for advanced users as well.
One of the things I hate the most about Go is that source code generation is considered an acceptable solution to many problems. Perhaps I should go back to C — the preprocessor can be used to generate code as well as anything. In fact, the predecessor to C++ was a preprocessor used to generate C code that simulated C++ like behaviour.
>They find themselves duplicating the same code again and again because Go doesn’t provide good abstractions to reuse code. Or that they write a ton of code to do what could be achieved in a few lines in a reasonable language.
This.
>You learn the language in a week because there is not a lot to learn.
Exactly. For example, Brainfuck is even simpler and easier than go. It also produces even worse, unmaintainable, horrible code.
> One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.
This ranks just about at the bottom for any language I care to work with.
"Learning a language" is more than just about being able to write syntactically-correct code. It's about understanding effective design patterns, idioms, the standard library, common pitfalls, writing maintainable code, and so on.
Learning the syntax comprises less than 5% of that effort, and optimizing for that step—particularly at the expense of the other steps—is ill-advised. And in my opinion, go has done precisely this by having tons of sharp edges: nil interface values, race conditions with channels, supposed-"meaningful" zero values, implicit interface implementation, etc. are all sharp edges I've personally run into that have caused bugs in production.
> One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.
IME, that's basically the case with any language with suitable libraries in the application domain and that doesn't have radically unfamiliar syntax or programming paradigm, so this rings as praise for it being neither especially novel nor deficient in library support for it's target uses.
> The people who designed golang are not newbies. They didn't ignore anything, nor were they ignorant of other languages. They had good reasons for choosing to go another way that makes sense for their language.
Yes, for using monkey coders more effectively.
>and is highly maintainable
No. Lack of exception handling and generics really hurt maintainability a lot. Not to mention that package management is still full of wrongs.
1. It complicates the compiler.
2. It slows down the compilation.
3. We didn’t think about it in the beginning, and can’t add it now without making non backwards compatible changes.
4. It makes the language harder to learn.
5. We don’t use this feature a lot.
I didn’t invent these reasons — search for why doesn’t golang have <insert-feature> — and you will eventually come across one or the other as a reason mentioned by one of the core members.
I get that you're just the messenger, but almost every one of these arguments makes my blood boil.
1. So what? The whole point of writing a high-level language is to pay the cost of low-level burdens once so that application developers don't have to pay them repeatedly.
3. This makes me treasure even more greatly the Rust core team's forethought when releasing Rust 1.0, in ensuring they hadn't walled themselves into any easily-avoidable corners before stabilizing the language. Such an approach has repeatedly paid dividends.
4. Optimizing for a person's first week of using a language at the expense of their next ten years is borderline indefensible.
5. This last one pretty much boils down the entire problem for me. Go is designed to solve problems Google has that most of us don't. It's also designed to solve them in a way that makes the most sense to Google (e.g., dependency management is irrelevant if you have a monorepo).
I totally agree, in case it wasn’t clear. Go, like many others, was designed by people who thought the users of the language are not as smart as themselves. They seem to have forgotten that after writing a few thousand lines, even a novice can become a power user and start demanding more of the language.
Unfortunately this meme will never die. The good news is I’ll be getting shit done while people who go on about this crap will just blog about Rust or monads or something.
Improving your tools != making the same stupid argument people have been making for a decade as if it hadn’t happened before. I actually agree that there are improvements to be made to Go; generics and dependency management being 2 that look like they’ll probably be resolved soon. That’s not that the same as this crap about “it ignores advances in programming!” or “it’s a failure because it’s not a systems language like they said it would be when they announced it.” or “Google made it because they think their programmers are too stupid to write Haskell.”
Improving tools is complicated and involves a lot of trade offs. It’s not just “omg it doesn’t even have generics what a shit language.”
We should attack the problem from the other direction, and for entities without special exemptions, require proof of consent from any identifiable people and organizations whose activity can be discerned in the recordings they retain or make commercial use of.
Success consists of going from failure to failure without loss of enthusiasm. - Winston Churchill
I don’t normally take these kind of quotes to heart but having a constant fear of failure and wondering what success is I think the above for me really helps put this in context.
