51–60 of 70 posts
Every scala code base I have worked on, that wasnt written by small team of experts, turned into a huge pile of crap. A small squad of people that treat the language like a religion create an impenetrable masterpiece
I'm still trying to reason what the value proposition of Scala is in a business sense. Developer are more expensive and harder to find, the tooling is weaker, the ecosystem less deep, performance suspect, and the overall XP feels clunky. Plus our hardware is procedural, and contains/manages state within the instruction pipeline. I strongly believe it doesn't belong as a core business technology.
Moreover, despite what people claim I've had no issues mentoring juniors or people coming from other paradigms but willing to learn.
Tooling isn't as good as plain Java but good enough, and certainly better than that of more niche FP languages.
The ecosystem is pretty rich in spaces where Scala really shines, in some cases it's even better than libraries and frameworks you can find in Java or Kotlin. Plus you can always consume any Java library.
Performance is good enough for Twitter or big data workloads at major tech companies (many of them use Spark). And nowadays with GraalVM native images you can even reduce the memory footprint to very reasonable levels, not very far from Go.
I'm still trying to reason what the value proposition of Scala is in a business sense. Developer are more expensive and harder to find, the tooling is weaker, the ecosystem less deep, performance suspect, and the overall XP feels clunky. Plus our hardware is procedural, and contains/manages state within the instruction pipeline. I strongly believe it doesn't belong as a core business technology.
Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms of business domain. The jvm ecosystem is also massive. If developers are more expensive, presumably there's a reason they're able to ask t…
What metrics are you using to make the claim that it's "easier" than more widely known, better tooled, and easier to search languages?
>The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms of business domain.
I've not seen this play out on a codebase of nontrivial size. I find it forces new ways of doing the same old stuff because "functional"
> If developers are more expensive, presumably there's a reason they're able to ask those rates besides "they know scala".
Why would you presume that it's not a simple supply and demand?
The fact is there a fewer FP devs. Why is that if FP is "better"?
There's fewer Scala devs, because Scala isn't better.
I'm still trying to reason what the value proposition of Scala is in a business sense. Developer are more expensive and harder to find, the tooling is weaker, the ecosystem less deep, performance suspect, and the overall XP feels clunky. Plus our hardware is procedural, and contains/manages state within the instruction pipeline. I strongly believe it doesn't belong as a core business technology.
The small pool of experienced developers is actually awesome. I waste a lot less time screening candidates and they're usually above average. Moreover, despite what people claim I've had no issues mentoring juniors or people coming from other paradigms but willing to learn. Tooling isn't as good as plain Java but good enough, and certainly better than that of more niche FP languages. The ecosystem is pretty rich in s…
Business don't need everyone to be a rockstar who's also a FP whiz. But FP languages need that.
I haven't encountered this pattern before. Is there some more information on what problems this is designed to solve?
Earlier quoted context omitted.
The small pool of experienced developers is actually awesome. I waste a lot less time screening candidates and they're usually above average. Moreover, despite what people claim I've had no issues mentoring juniors or people coming from other paradigms but willing to learn. Tooling isn't as good as plain Java but good enough, and certainly better than that of more niche FP languages. The ecosystem is pretty rich in s…
You have a lot fewer candidates to pull from too, which is often a more limiting factor for a business. Business don't need everyone to be a rockstar who's also a FP whiz. But FP languages need that.
I'm still trying to reason what the value proposition of Scala is in a business sense. Developer are more expensive and harder to find, the tooling is weaker, the ecosystem less deep, performance suspect, and the overall XP feels clunky. Plus our hardware is procedural, and contains/manages state within the instruction pipeline. I strongly believe it doesn't belong as a core business technology.
Circuits are deeply functional: everything is computed all the time and only selected from.
Earlier quoted context omitted.
Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms of business domain. The jvm ecosystem is also massive. If developers are more expensive, presumably there's a reason they're able to ask t…
> Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. What metrics are you using to make the claim that it's "easier" than more widely known, better tooled, and easier to search languages? >The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms…
The term FP has lost precise meaning over time, and split into several related meanings.
• Focus on the absence of side-effects. (E.g. Agda, but not Scala, Ocaml, F#)
• Focus on the higher-order functions. (This is no longer controversial, but used to be)
• Focus on rich types. (The ML (the programming language) tradition, note that Lisp and even Lambda-calculus were born untyped)
• Focus on the use of traditional functional idioms, e.g. map-reduce, even when the implementation is totally not functional.
Which one are you referring to?
I'm still trying to reason what the value proposition of Scala is in a business sense. Developer are more expensive and harder to find, the tooling is weaker, the ecosystem less deep, performance suspect, and the overall XP feels clunky. Plus our hardware is procedural, and contains/manages state within the instruction pipeline. I strongly believe it doesn't belong as a core business technology.
The only rare exceptions I heard of were strict FP shops who share nothing with common JVM-based development. You could have a few years of full-time Scala experience with Akka and Spark and they won't even screen you.
In the year of our Lord 2024 the question is if you want to bet on Java21+ catching up with Kotlin or go with Kotlin from day one. The choice is less obvious nowadays. I'd go with a modern language, actual job market sides with Java still. At least on the backend in the Bay Area.
As a side note, I cannot imagine a competent JVM-based developer not familiar with either Kotlin or Scala by now. In a typical Java shop half of the team is dying to switch to one of them in my experience.
Earlier quoted context omitted.
Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms of business domain. The jvm ecosystem is also massive. If developers are more expensive, presumably there's a reason they're able to ask t…
> Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. What metrics are you using to make the claim that it's "easier" than more widely known, better tooled, and easier to search languages? >The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms…
> I've not seen this play out on a codebase of nontrivial size.
I have :shrug:. There's currently this discussion[0] about some functional design principles on the front page. Things like making illegal states unrepresentable mean that you just don't have to think at all about various would-be error paths (again, making it easier to write, easier to read, and easier to review), and while Scala doesn't automatically give you such a design, it at least makes it possible (unlike e.g. Go). You just need a good lead to guide people's design.
In fact "make illegal states unrepresentable" is perhaps just one facet of a more general observation that if you accurately model your domain, the code basically writes itself. IME Scala's type system hits a sweet spot of giving you the ability to model what you need without forcing you to model concerns you don't want to care about (e.g. Rust's lifetimes).
Demand for what? Why would there be intrinsic demand for Scala programmers? Why isn't there a similar premium for Perl or COBOL programmers? It's not like Javascript or C/C++/Rust where you have limited options of what languages can be used in some domain (browsers, embedded, etc.). It's a high level application language, which is a space with tons of other languages.
One possible contribution is that it has features that more experienced engineers can appreciate (like a compiler that helps prevent basic errors and a good concurrency story and workable macros so that you can focus on teaching your team domain context instead of looking for errors with nil references or locks or whatever or poring over tons of boilerplate. Performance is also good enough that you probably don't need to worry about e.g. horizontal scaling), so you may tend to see them wanting to use it more.
e.g. I did a few years of PHP (Laravel) work. You won't ever find me taking a PHP job again; I've had enough of it for one lifetime and don't need that kind of stress. My understanding is Ruby/Rails are similar, so again I just wouldn't consider a Rails job. I'd probably prefer working with Scala, C++, or maybe Rust, so you're more likely to find me in a "Scala programmer" statistic and won't find me in a "PHP programmer" statistic, but that's not really why I cost more. I expect more money than your average developer because I have more experience than your average developer and I've been in tech lead roles for a while now.