sixminuteabs

Recession and layoffs are slightly different. I view the more proximate cause of layoffs etc is the increase in the cost of capital and more of a feeling that there might be a slowdown. Company execs, boards and investors had a different denominator in their projections about present value of cash flows in Q4 of last year (this is always an approx calc in practice, but the mechanics / views follow the equations) and now investments that might have made sense may not. People are calculating the risks of recession differently. All of this is idiosyncratic to each company. Some companies may be operating in a domain where it makes sense to invest or for larger companies based on their estimations, and in large companies you may have some bets that make sense to expand and others that should shrink.

I agree with a lot of the criticism in the article, but also agree with this idea that Scala is in the best position it has ever been. Core Scala is migrating to Scala3 (will take a few years) and the scala team had the courage to take on the rough edges. The Typelevel community (FP side) has a whole ecosystem which is maturing into something really nice. Akka pulled the ripcord on licensing so everyone knows where they stand.

Across the board the language and environment is stabilizing. Most of the (correct) criticisms expressed in this article are either 1. An expression that dependency management remains really hard as dependencies and ecosystems grow 2. An artifact of the fact that early scala projects relied heavily on borrowing from java to bootstrap and it caused a snarl of dependencies. On the latter, I see a decline in snarl overtime.

It is fair to say that Rust and Go have a really awesome toolchain experience and are setting the standard (though I wonder if the problems of being "old" and having boatloads of libraries haven't yet set in). SBT nominally has a similar experience but it's definitely slower and somehow less intuitive. Hoping to see more work in this area and I think Mill + SBT "competing" + BSP and bloop opening the door for more innovation will allow for quick progress.

We're US only for now.

[Disclaimer] I'm the founder of farther finance (https://www.farther.com) - the first digital family office.

We offer this to our clients at farther - set a minimum amount to keep in your bank account, everything over set minimum gets swept to your investment accounts and invested based on how you set them up and any relevant regulatory stuff (like max IRA contribution amounts) or goal amounts.

Quick note - We focus on holistic management for pretty significant wealth (compared to the target client for most offerings) and all of the stuff that comes with that - more intricate planning around events, alts, families, collabs with CPAs, attorneys etc. That's best achieved with a hybrid approach - an advisory team boosted by tech - so advisors are part of the deal! If you're interested, feel free to PM me and I'll connect you with one of our advisors.

When I say more freedom, I primarily mean freedom to focus on the problem domain and freedom to contribute in a major way more quickly. Upon reflection, I realize that my expression about optimal solution was about optimality in modeling and understanding the problem domain vs. wrestling organizational programming pattern you're trying to learn / hold in your mind while also trying to solve the domain (which you don't have to do as much with scala's compiler)

And in terms of morale, I view almost the opposite of what you're saying. Because types and the compiler enforce correctness in the program and compatibility within our systems I can have a relatively junior person thinking more about the domain and knowing that they can get something "real" into prod much more quickly with almost no risk to the org. They can move on to bigger blocks of work more quickly. Solving real, big problems and making impact gets engineers jazzed up. Regarding compilation, I find the "this won't compile" phase is almost non-existent in practice. People quickly adapt from "this thing doesn't compile [insert sad longing for python]" to "this thing won't compile - somewhere there's a misalignment with what I said I'm going to do (via types) and what I'm actually doing, [insert silent acknowledgement that they would have shipped an error in python and not known it]."

I'm not seeing where the gap is between A and B except that in option A it appears that there is no compiler involved, which per the above, means that I have to ask them to focus more on exercising mental discipline about coding conventions (boring, low value add work) and also I can't allow them to contribute as quickly because the risk they threw an exception somewhere they shouldn't have (e.g.) is higher.

We develop the majority of our code in scala at my company (in fintech).

There seems to be an experience in this thread that training in Scala is difficult. For anyone who is considering and wants another perspective - I have found that junior engineers tend to get up to speed more quickly in Scala than in other languages and that I can give them more freedom (because I know their programs won't compile if they don't line their types up and our use of the type system very immediately forces them to deal with the possibility that an operation can fail, e.g.). I can simply look at types and give them a nudge in the right direction (heyoo -fp either joke-). Yes they suffer a little in the beginning, but are usually shipping code within a few weeks then their trajectory really begins to rocket. It's very cool to watch them grow to building complex systems in a complex domain so quickly. As they grow the ease of refactoring means that it is easy to change their prior work as they gain more understanding, so for our management the penalty of allowing them to learn in the wild about something that's suboptimal is pretty low - they will come back and fix it. Of course what I'm saying above is really about FP and type systems and an implicit (heyoo -scala joke-) presence of thought about how our systems work top to bottom and how we train people. I think that is also required no matter what tools you use or what you're doing in any organization?

As someone who has hired and worked with consultants, these make me chuckle a bit and I think speaks more to a problem of lack of self-awareness of the consulting side (and in the world in general) around consulting's primary role (false view driven mostly by recruiting material), and a bit of arrogance. Clients aren't just hapless rubes. They are domain experts in their industries and organizations and are quite aware of what consultants provide and what they don't. Consultants are a tool. If you're running an org, you don't have time to make excel models and presentations really at all. It's so freeing to be able to dump a bunch of raw data and some direction on a consultant and to have them drive a structured process of analysis product development. A less morally loaded way to think about what is being said in this story in the "I modeled a billion dollar loss story" is that on one side of the table you have a 22 year old with a lot of mental horse power but 0 years of relevant experience or context and 0 ownership of consequences of action. On the other side you have an exec with probably 10-25 years of industry and company experience and a vision, and skin in the game who is going to use the model probably mostly as a sensitivity analysis mechanism with colleagues and not a "this is an accurate state of the world in 2028" kind of way, which is the way that any model or simulation is used in real world decision making.