Static typing alone won't save you from creating monolithic code that's hard to maintain. My current employer has been slowly decoupling their 20 year old core product written in .NET into microservices (mostly Java, some Node) for years. The legacy .NET codebase has tons of tightly coupled dependencies, logic heavy error prone stored procedures spanning thousands of lines, and laughably slow startup/deployment times.
This. People who believe this pipe dream that static typing will somehow protect you from technical debt either haven't dealt with Java or it's slightly better cousin C# or have only dealt with that one technology and believe whatever kool-aid advertising they were sold on.
The only way to adress (but not eliminate, since it's impossible) technical debt is to refractor mercilessly and constantly. And then there is some merit to static type advertisement - as the tools and techniques to safely refractor are both more feasible and more available for these environments.
> People who believe this pipe dream that static typing will somehow protect you from technical debt either haven't dealt with Java or it's slightly better cousin C# or have only dealt with that one technology and believe whatever kool-aid advertising they were sold on.
Hark! A counterexample has arrived! I spent a bunch of years creating and maintaining big Rails applications. I've spent the last couple years on a bigger application in Java. I didn't drink any kool-aid, I just think Java is a better tool for this. C# and other things may be even better; the key is the ability to write static analysis tooling, which includes, but is not limited to, a compiler's type-checking analysis. It's not that a language with strong static analysis support saves you from creating a mess, it's that it makes it easier and much less risky to clean up that mess over time.
I agree with everything in your second paragraph, and would emphasize the risk aspect of refactoring a big application without good static analysis tools. After the first few spooky-action-at-a-distance prod breakages due to refactoring, it becomes hard to argue for a merciless and constant refactoring culture, and much easier to become the grizzled veteran who is a risk averse gatekeeper discouraging major refactoring in code reviews (this was me).
You don't refactor "a big application". You refactor bits of it (sure it might mean moving things around) and then comes your barrage of tests before you merge that into master.
That and: You don't (or at least shouldn't) write a big application anymore. The only other thing (other than horizontal scaling, that is) that microservice design makes easier is exactly code maintainance / refactoring. The practices around it have matured enough.
On the other topic: I've spent last year or so writing mostly JavaScript, and have moved to VS Code as my primary IDE. I'm pretty happy (was doing Java/Python before that, and PHP/Python before that, and some embedded stuff before that).
The truth is that a good tool (and VS Code is one hell of a tool) makes working in a dynamic language very usable. VSCode static analysis tools make my JS experience better than my previous NetBeans Java experience, all things considered.
And I'm now dabbling with TypeScript to see how that goes. I quite like the idea of "just enough typing" and I think type-hinting rather than static typing is the way forward in this networked future. It's simply that these JSON-ed distributed environment people work in now will make static typing languages frustratingly un-agile for large majority of use-cases.
I get the sense reading this article that the main concern raised is whether or not enough value is being generated by companies and researchers that "use machine learning to solve problems related to X" to justify the investment. The author doesn't touch upon whether using ML could be exacerbating the very problems these implementations are trying to solve. Inappropriate implementations of classification algorithms and predictive analysis that create false positives has the potential to inflate this sort of a bubble even further.
Apple being the acquirer wouldn't change the potential conflicts of interest or the trend towards monopolization, which is what a lot of people are upset about. Animosity toward large corporations isn't unique to Microsoft.
Developers in Toronto are getting a raw deal. The cost of living is orders of magnitude higher than the rest of the country and devs aren't making the difference up with higher wages.
So glad I made the decision to move from Toronto to Atlantic Canada this past year. I'm actually making more money in New Brunswick than I did in Toronto and can afford to own a 4 bedroom house instead of renting a 600 square foot condo.
I have been weighing making a move from Saskatchewan to New Brunswick. When I compare Regina to Fredericton (as an example) though, it seems like I must be missing something. On the surface, pay is generally better, the stacks/companies are more interesting, the location seems amazing, and comparable real estate is less than half.
I know that Regina->NB is dramatically different from Toronto->NB, but is there anything you wish you would have known??
Might be obvious, but the biggest thing you'll give up in this market compared to cities like Toronto or Montréal is selection. There's some larger companies with satellite offices here (IBM, Salesforce, etc), but not too many startups.
One word of caution about real estate in the Fredericton area; don't buy any property too close to the river. There's usually flooding in the spring from the snow melt up stream and this year was especially bad. I was lucky enough not to be affected, but there's lots of homes taking flood damage right now.
First, I apologize. I know that the river is flooding right now and I asked you 'should I move' questions when you could have been facing a tragedy. That was very selfish of me and I'm sorry.
I'm very glad you weren't affected by the flooding, and thanks for being kind, despite my gaffe!
It finally feels to me like things are on the cusp of getting interesting in Regina. Saskatoon's recent acquisitions (Solido bought by Mentor/Siemens, SkipTheDishes) seems to have raised a lot of eyebrows in Regina and there's at least some momentum building to get investors/business folks/tech folks together to start building things. Co-Labs in Saskatoon seems to have been a huge inspiration/wake-up call for parts of the Regina business community.
That being said... I've always had a bit of a longing for Atlantic Canada, and if the jobs are out there... that's pretty interesting!
My team used Sails for a project about 3 years ago and can confirm that your description fits the framework to a t. We were sold on the premise of a Rails-like experience running on Node, but experienced all the shortcomings you described.
I'd also add that we probably underestimated how much using a less popular framework negatively affected our pace of development. Having a large community helps a lot when you're trying to get junior devs up to speed.
This sounds like the most likely explanation to me. The only programmers I've personally worked with that wrote code in a functional language for their day jobs were data engineers using Scala for an Apache Spark data pipeline. They weren't paid well because they wrote functionally, they just filled more of a niche role with a higher barrier of entry than a typical web developer.
I've been doing Scala professionally for a decade (so definitely not limited to Spark). There was a clear correlation between Scala jobs being higher paying and more interesting than what I was doing previously.
I'd love to see a SAAS product for watching sports. Similar to Netflix in terms of UI and pricing, but also with the support for live content. I know this probably won't happen any time soon since major US telecom providers have exclusive broadcasting rights to major sports games.
This looks promising. Although, it seems they only offer NFL, soccer, and tennis coverage currently. Hopefully some day they'll add NHL and NBA games as well.
As a Canadian who's spent a few years in the southern states, I can say that the difference in infrastructure here does help reduce the risks of road accidents when there's snow. In the south the entire city shuts down because the people there don't have the snow plows, road salt, and winter tires to deal with it. However, in a really bad storm the reduced visibility and slippery roads can still make your drive very dangerous.
