Puerto Rico's population has been falling for the last 10 years or so, which is a strong factor in why they had so much trouble with debt. This is going to make it much worse. See https://www.cfr.org/blog/puerto-rico-maria for a lot more detail.
If it was 100% isolated, the heat from the sun would continually increase the internal temperature, which would probably be bad. They're looking for a steady state dyson sphere.
I don't think that Go is a good language to compare with Scala. (I do like Go, though.) The two languages could not be more different in philosophy. Scala is maximalist - you can do things many ways, you can call java, you can have tremendously intricate types, etc. Go is minimalist - there are just enough tools to get by, and sometimes it feels like you are missing one. My experience with Scala is that you spend more time telling it what to do but not how to do it (and it is often not obvious exactly how things will be done), while in Go you have to tell it both what and how to do things, which results in longer code, and repetition, but less ambiguity. You can't add to Scala to make it more like Go - the only way to make it more Go-like is to remove from it, which is impossible.
I think a more appropriate comparison for the language would be F#, which is probably not a surprise to you. I have never used Scala professionally, so I can't give any suggestions that would improve the use of Scala for day to day programming. Years ago I was learning 1 language per year, and picked up Scala and F# that way. After completing the Coursera courses on Scala, I put together a few projects on github using it, enough to get some job feelers that ignored my "don't send me job offers." And I realized that while I enjoyed fiddling around with the language on my own, I didn't want to spend my professional time deciphering other people's Scala code, and so I dropped it. Take from that what you will - maybe I am just not cut out for it.
I do use Go professionally, although it is a minority language where I work.
Thanks for your balanced reply. Sadly, some people see it as a badge of honor to write super clever code that's essentially write-only, and Scala somehow triggers this in them :-)
We, as the Scala community, play an important role in shaping the culture of programming in Scala as one that embraces simplicity as the true elegance, maintainability and testability, friendliness and openness to criticism. The language will remain flexible (though we're always looking to remove warts), it's really up to your company culture to decide how to use it (which is different for different teams over time).
Many big players, such as Twitter, have done a great job with that (and continue to do so).
Yes maybe some of the success stories regarding changing from X language to Go are actually because Go enforces behavior at the language & tooling level that could potentially be enforced culturally at the company, but for whatever reason, the company has not been able to develop. Kind of, "if you don't play well with your toys, we take them away," instead of teaching them to play well from the start. When you're just a senior developer, you probably can't change the culture but you might be able to change the language for some applications.
There is the old jeremiad to not use technology to fix cultural problems, but when you're just a part of a much larger institution that may or may not have the ability to intentionally change its programmer culture, it can make a lot of sense to move to a language that reduces your reliance on those cultural behaviors if they are lacking.
Some of that could be addressed automatically in Scala with code standards enforcement like with scalacheck. And you can help with good practices like code review or pairs programming. But in a lot of places there is no appetite for "wasting time" on stuff like that (I vehemently disagree with that kind of attitude, but changing other people's view is not easy).
The advantage of Go is that left to their own devices, people will tend to gravitate towards more readable code, in a standard format, using standard tools that are pretty good in most situations. The entropy of having a bunch of people work on a project will then work in favor of coherent approach and style, instead of tending to diverge into using the tools they like best in the format they prefer.
Always show up in court if you are being sued. If no one shows up at all for one side, they lose. He sent his assistant, but I doubt that made the judge happy. That's probably the mistake that cost him 100k of his and his employees' time.
My job, which includes attempting to determine the facts and deliver a just decision, instead of making a reality-show-style popularity contest out of it.
Proper procedure (including appearance, notice, and other jurisdictional matters) is part of the decision.
It's ridiculous how otherwise (mostly) rational professionals are so blinded by their version of facts & the adversarial nature of litigation / hearings that they act so cluelessly.
This comment included: imagine if someone had a pitch scheduled with a VC, but sent an assistant instead. The investor would correctly pass on that and HN would flip a shit. But involve lawyers, judges and the judicial process...and expecting someone to show up to court is a "reality show popularity contest"
The claim was that he didn't fully hold up his end of the contract. This isn't a criminal case with forensics; this is small claims with a lot of he-said, she-sad.
I do agree with this and should have attended the first trial myself.
I do find myself somewhat conflicted though as to what advice to offer others in the same situation. In California small claims court, it seems that you basically can appeal a decision for any reason as the defendant. You could almost make it a practice to send an entry level person to fight the first one and if you lost, go back and appeal. The other shocking thing is that if state you will not stipulate to a pro tem hearing your case, your case will most likely be delayed again and again. You could almost just do that till the other party gives up. I have doubts that a person angry enough to sue would give up though - I did not.
Even then it can be hit and miss, depending upon the judge's ability to understand the case. I have been court a couple of times where the judge used my exact argument to side with my opponent. I got both decisions reversed in appeals, but that didn't make the process any less frustrating.
Unfortunately, courtrooms are not always the bastions of justice we'd like to think they are.
I think the idea behind "always show up in court if you are being sued" isn't that it will always work out for you, but that it almost definitely won't work out for you if you don't show up.
I cringed when I got to that part. Not showing up in small claims court and sending your assistant is just the dumbest thing short of not showing up at all, and not hiring a lawyer.
He acknowledges this as his biggest mistake:
> At this point, I made my biggest mistake and figured it was such an obvious win that I did not even need to attend the small claims hearing
Hopefully everyone reading can learn this lesson the easy way and save the $100k.
In this case, it was the company that was being sued, and the assistant was there to represent the company. Which sounds perfectly reasonable. It would be nice, but there's certainly no expectation for the CEO/owner to attend every single court case.
All the emails and negotiations are between him and the other guy. It's not like his company is a multinational with billions in revenue and the CEO on another continent. It was absolutely a huge mistake not to show up personally.
By fostering a larger talent pool competition insures a dynamic long term future, lack of it it often leads to creative stagnation. This is the case in natural systems as well.
It is kind of both; go doesn't allow some approaches in native go code that can make it slower than other languages. (I love go, but that is my experience.)
In this case the choice to use utf-8 everywhere, including in the csv delimiters, is making it slower.
His book "Numerical Methods for Scientists and Engineers" is brilliant, his work included information theory, sampling, and running bell labs during its most productive time. He wasn't a professor, he was a giant.
I also very much recommend "The Art of Doing Science and Engineering", which is mostly philosophical but has quite a few partial differential equations in it.
Side question: are there any open source synthetic chemistry projects that I can look at to get an idea of the techniques and problems encountered? I try to learn about a new non work related subject every few years and it piqued my interest but I haven't been able to find anything but textbooks - code is easier for me to understand.
