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.
For me the big win with Go, is its so easy to get from new project -> first working test.
I think there installation of the required tooling is very easy and just works, unlike other languages where you can spend a lot of time just getting all of that initial stuff setup. Also upgrading the tool chain is very easy as well.
That's funny, because this is what I really like about Scala; how quick and easy it is to get a project started.
> sbt new scala/scala3.g8
will just create an empty project. If you don't even want to bother with a project, use use scala-cli or ammonite (http://ammonite.io/) to just start banging out code.
Even the upgrading of a project from Scala2 to Scala3 is a breeze, thanks to very good backwards compatibility of new library releases.
[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.
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?
>> I can give them more freedom (because I know their programs won't compile if they don't line their types up
In what meaningful way can you give them more freedom? When i think about how i spend my time with junior folks, it tends to be on things like:
1. Do they understand enough of our problem domain that i can begin to describe a problem that needs to be solved?
2. Have they understood the problem i described? How confident am i that they're not going to implement a solution to the wrong problem?
We don't spend time on "hey, you passed the parameters in the wrong order here".
To put it another way based on my experience, what's more useful to a junior developer?
Option A: Hey, here's a test case, here's how to run it. I need you to change the behaviour of this component to do X instead.
Or
Option B: Hey, here's a component with well designed types. I need you to change the behaviour of this component to do X instead.
My experience has been that Option A - play with the component hands on, try things, run it, tweak the data supplied to it and observe the results - these encourage engagement. The developer will be excited even.
And for Option B, they'll be quite dejected, not that invested in the project. I can't even compile the stupid thing because of some cryptic compile error.
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.
>> they can get something "real" into prod much more quickly with almost no risk to the org
What are the most common risks to an org (originating from its code) and how do types get you down to almost no risk?
When i think of common risks, most of them don't even originate inside the process's address space so the type checker is completely disconnected from the risks (e.g. hey - you misunderstood what we wanted here...). For the risks that do originate directly from the code, it's stuff like hey - your solution is quadratic time, sure your code compiles and your tests all pass but i'm telling you this won't work under prod data volumes.
I'm trying to steelman your argument and the best case i can come up with is an IO monad.
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.
