IMO Scala is one of the best programming languages out there. I know it might sound like zealotry because Scala is already way past its hype curve, and the “Through of disillusionment” already caught a fair bunch in ways that more recent and hyped languages haven’t yet, but it’s not only still very relevant today, but more and more so (IMO).
So, what’s to like about Scala? Like most of things, those are two-edged swords:
1- multi paradigm
To my knowledge Scala is the only language that unifies object oriented programming and functional programming so seamlessly. You can pick the right tool for the job, opting for imperative-style where it’s fit and choosing elegant composable/curried when appropriate, without having to bend your mind as much as you would with Haskell/clojure/OCaml/F#/… where things are more one-sided. The downside is that different programmers will have different takes and preferences as to what’s the most adequate style might be, and a same codebase might look very different from one place to the other.
2- type system
Scala has one of the most advanced type system. Nothing Rust or Kotlin might match any time soon, or ever. Scala’s implementation of GADTs, combined with its powerful pattern matching enables concise and idiomatic abstractions. Many of which are zero-cost thanks to things like opaque types, inlining, tail recursion, … There is a whole area of the Scala community striving to make invalid states irrepresentable (your code won’t compile if your instance of a pizza is missing a topping), which makes such libraries self-documenting and easy to use. The downside is that nothing prevents you from climbing the abstraction ladder and encoding everything in the type system when all you need is a simple trait/generic, and that’s a human/complexity management problem tooling and the language can hardly mitigate.
3- scalable
The author of Scala (who was a long-time Java compiler architect) wanted Scala to scale from shells one liners to complex multi-cluster distributed systems, and delivered on that. You can start small with a scala-cli proof of concept, transition to a mid-scale “python with types” kind of project, and grow up to very large and complex projects. Beyond the JVM, you can target the browser with scala-js and share models and validation logic between the front and back ends. You can target native binaries for instant startup/low footprint executables that are cheap to spin-up as microservices.
4- has a foothold in academics
A whole team at the EPFL is pushing boundaries of programming languages and using Scala and its compiler as a ground for experimentations. Scala 3 has a proven sound type system thanks to its foundations on the DOT calculus. Effects and Capabilities are being researched as part of the project Caprese to offer a solution to “what color is your function” (mixing sync and async), of memory management/lifecycles (more generic than rustc’s), of pure/side-effectful code, etc. The downside is that this gives an impression that Scala’s development lacks focus, but arguably those happen in distinct development branches and by different people.
Anyway, feel free to continue the discussion on: [email protected]
Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn’t work well for people on different instances. Try fixing it like this: [email protected]
Yeah … but Scala is insane, you can fundamentally redefine the behavior of reserved words.
Scala desperately needs a new build system along the lines of Cargo. Sbt is a mess.
Mill has way too much boilerplate. It makes the same critical mistake as sbt.
Go take a look at Cargo. That is the correct way to design a build system. Configuration is purely declarative, in a language (TOML) that doesn’t even allow imperative code. Custom build behavior, if any, goes in a separate script alongside the configuration file.
Also look at Maven, which tried and failed to do what Cargo has done successfully.
I rather disagree with the statement about mill’s perceived boilerplate, you build is composed/extended from classes and traits and the behavior is provided by overrides, OOP style. It’s nothing like sbt’s layered opaque architecture, yet you can do as many complex things as you need, programmatically, with the same scala language your project is written in.
As I said, you might not need that if your build is simple enough, and the more direct equivalent to cargo would be scala-cli. Going on a tangent here, Cargo is pretty basic and restrictive: scala build tools need to concern themselves with binary/ABI compatibility and cross targets compilation (to the JVM, JS, Native, WASM, …) all at once, whereas cargo only “cares” about source compatibility (no dynamic linking, no publishing in a compiled ABI stable form).
Here’s an interesting thread describing very well the problem space, and elaborating on the situation in rust/js (reply from mdedetrich): https://www.reddit.com/r/scala/comments/12jhud7/comment/jg2aecf/
you build is composed/extended from classes and traits and the behavior is provided by overrides, OOP style.
Yes, that’s the boilerplate I’m complaining about.
you can do as many complex things as you need, programmatically, with the same scala language your project is written in.
That belongs in a separate file, and the typical project shouldn’t need one.
the more direct equivalent to cargo would be scala-cli.
That’s a false equivalence. Cargo is a full-fledged build system and handles multi-module projects.
Cargo is pretty basic and restrictive: scala build tools need to concern themselves with binary/ABI compatibility and cross targets compilation (to the JVM, JS, Native, WASM, …) all at once, whereas cargo only “cares” about source compatibility (no dynamic linking, no publishing in a compiled ABI stable form).
That can be a problem, but it doesn’t justify Mill’s boilerplate.
I think the only way to make this constructive is if you could describe what you mean by “boilerplate”. My experience of writing and reading mill build files is that they are extremely succinct and convey their intent clearly.
And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked. Cargo is factually a very basic tool, comparatively.
I think the only way to make this constructive is if you could describe what you mean by “boilerplate”.
object,extends,def,Seq, etc. These things do not belong in the top-level description of the project.And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked.
I just did. I am not at all convinced by lihaoyi’s reasoning. Maven already solved the “templating system” problem with POM inheritance. POMs are not functional programs. There is no need to pass values between different parts of the structure; simple variable substitution is usually adequate, and when it’s not, scripts and plugins fill the remaining gaps.
Cargo is factually a very basic tool, comparatively.
Maven isn’t, and although it has serious problems, none of them arise from the fact that its project description is not executable code. There is no need for that.
And there is a need for not-that: it takes a long time for IDEs to open sbt projects, and they frequently fail to do so at all. Maven and Cargo projects, meanwhile, open instantaneously and reliably.
I’ve only written a “hello, world” in Scala a long time ago, but it seems to be used a lot in the banking or fintech industry mostly. Is there a reason for this?
It got this foothold pre-spark, largely due to the akka and typesafe/lightbend ecosystem. Then spark resulted in a lot of data engineers picking up scala (this was my entrance, from the Hadoop map/reduce world). And now cats/zio and effect systems have rounded it out.
Personally I love scala, my teams use it heavily (mix of styles but mostly zio-http, and a lot of spark). But scala3/dotty has been problematic enough for us that we decreed people stop updating their apps. The learning curve is HIGH (esp for functional/effect system scala). The candidate pool is small. I don’t know that if I were to start a greenfield project (without all the rest of the platform already using it) I would suggest we use scala. But the rest of our platform does, and we have tooling, and L&D tracks, etc. So onwards we go.
Rust: A systems programming language that emphasizes safety, performance, and concurrency.
If you are creating a distributed system, then Erlang/Elixir is probably what will be the most productive and expressive language, bar none. Outside of that, ReScript has a lot of potential and Ocaml can be nice if you like that syntax instead.
deleted by creator
The question could be changed to: “what’s your favorite programming language?”
I would said that this is a subjective question, as everyone has different opinions in expressiveness and design, and the productivity also depends in your experience.
On my case, this language would be Ruby, as that’s where I feel at home.
The best tool is the one you have and are familiar with. That being said, it also depends on the task at hand. There’s no silver bullet, and anyone telling you this or that language is THE best without context is a fool.
Plain Old Human language. Remember comments? Remember moments when things get very complicated and docs and comments become your only help?
That mostly because none of the languages is the best. Some of them better in some places and worst in others.
For example: Java. Amazing library range, enterprise support and feature and community reach. Java also fail in shambles when you need a low level or guaranteed performance. Erlang. Robust distributed and fault tolerant. Now try to create something that is not network, agent oriented and should work locally only.
Every language has a niche. Look at javascript. JS is only exist because of it’s niche. It wasn’t good as a language, but it was the only one viable solution in it’s niche.
Same with assembly. Nobody sane would use assembly if it wasn’t that close to the metal.
There are time tested solution in every niche and it is wise to know why they still there and what drives them.
I think you took more effort into answering the “other side” of his question.
You are absolutely right. At first I just wanted to add my favorite language to the bunch, but then I realised that this isn’t really answering anything, because the use case matters most.
You can use any language to programm solution to any problem in any environment. And given that here we have many developers fixing many different problems we will end with just a collection of all possible languages and problem/solution permutation.
Language doesn’t matter. Solution and solution logic matter. And most times we are using a Plain Human Language to crate a solution and then encode it.
Nim: A statically-typed language that compiles to C and emphasizes speed, expressiveness, and ease of use.
The qualities you describe are a function of the programmer’s talent and their familiarity with the language, not the language itself. So there are no ‘correct’ answers, just opinions.
A few years ago, I would’ve said Ruby. Nowadays, it has to be Python - it’s simple, readable, clean and more performant than ever. The fact that is widely adopted and used in a wide range of industries probably helps a lot.
Smalltalk: A dynamic language that emphasizes simplicity, flexibility, and interactivity.
For my sins I spend a significant part of my time maintaining smalltalk, and it most definitely is not productive.
The syntax is ugly and cumbersome when you start chaining messages. Any advantages the evangelists tout are available in modern languages without the baggage of this dead one.
Today if you want something ‘simple, flexible, interactive’ (interpreted, GC and likely faster) python would almost certainly be a better choice.
D: A systems programming language that emphasizes safety, performance, and productivity.
c++ with garbage collector lol
How’s Rust? I was thinking about learning it since I do work in offensive cybersecurity and it seems to be the getting popular with exploit being written mostly in it, but I have no idea what to expect.
Rust has ruined C++ for me, so pretty damn good!
A lot of focus is placed on rusts memory management, thread safety and lack of surprise undefined behaviors, which is all good. The thing that I miss the most about rust at my C++ $DAYJOB though, is that it has better tools for abstractions (ADTs with traits instead of classes), the error handling and that it has a more well put-together standard library. Rust is a very solid language in terms of expressiveness and having useful abstractions, but it does require you to juggle memory and error management more which is sometimes good (languages with try catch throw often tend to have code that’s just handles the happy path ime) but does require more dev time upfront.
Do you have some resources on cybersecurity with Rust? I’m not at all experienced in cybersecurity but I’m curious
Common Lisp!
It can be a little esoteric if you don’t have experience with the paradigms, but I’ve never used a language that felt more free.
On SBCL you have typing support, CLOS provides an OO interface, and it lends itself well to functional style programming (despite not having a type system as powerful as say Haskell). Additionally, the ecosystem is quite stable and mature, any library of functionality you might need is likely available.
functional dev environments have been the hardest part of learning cl for me. i don’t really want to use emacs, but it’s the wild west for other editors.
setting up emacs wasnt hard per se, but emacs is just so much. i spent more time troubleshooting how to use emacs and fix issues with it than learning the language, which just makes it all a little lame.
I’ll agree the emacs on ramp is widely regarded as a barrier to entry on CL. I’ve heard good things about the Alive plug-in for vs code though. Also stuff like emacs4cl and portacle in theory make it easier, but I don’t disagree.
With that said, using an editor built on a lisp to work on lisp as its advantages if you can get over that initial hurdle.
I’m enjoying dart because of flutter
Flutter is great but dart is terrible. It is like bastard baby of javascript and Java but takes the worst of both of them. It is not efficient at all and still lacks pretty basic features like nested classes. Its accessibility modifiers are very poor and “asynchronous” jobs are shit. I am still using it because of Flutter but dart itself is shit
