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.
I largely agree with this statement. I think the original question is very widely scoped. It’s like asking, “what’s the best tool for hammering nails, chopping wood, cutting wood, cutting glass, polishing floors, and building skyscrapers, and the tool is used by all builders anywhere and any time in the human history?” Different people, different skills, different problems.
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: !scala@programming.dev
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: !scala@programming.dev
IMO this should be a feature of the comments editor, if this matters at all.
Good bot
Yeah … but Scala is insane, you can fundamentally redefine the behavior of reserved words.
Since when?
Scala lets you define new operators, but only in the sense that any method can be used in operator notation and method names don’t have to be alphanumeric (e.g.
++is a valid method name).Scala lets you quote reserved words in order to use them as identifiers. They’re quoted, though; an unquoted reserved word cannot be used as an identifier.
Several Java operators, including
instanceof, are just methods in Scala. They are special in that they arefinaland don’t cause NPE when called onnull, but they are not reserved words and can, for example, be used as local variable names.Scala isn’t insane, just misunderstood. Its build tool, on the other hand… 😬
Scala isn’t insane, just misunderstood. Its build tool, on the other hand… 😬
Good thing is, mill brings a lot of sanity into this space. It’s been years since I’ve had to use sbt on a regular basis, and every time I looked at it since was with incomprehension and disgust. I don’t think sbt is improving in ways that makes it friendlier. Nowadays scala-cli is all the rage, and deserved (IMO).
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.
Scala is really nice and fun, but I get the feeling that it’s been kinda dead for a pretty long time
I’d be curious to know what makes you think that. Scala 3 released relatively recently and is basically a full rewrite of the compiler with a new type system/theory and features that you will see creeping into other languages for decades to come. And Scala 3.3.0 came out weeks ago as the first LTS version of Scala 3. Things are going at a fast pace there, on the library side, ecosystems like typelevel, zio and lihaoyi got a lot of polish and focus on practical use-cases, and tooling-wise, Scala now has cohesive and easy to use IDEs, linter, reformatter, build tools, …
Sure, nothing’s perfect, but it’s a much more vibrant place than most programming communities out there :)
Can you point to a particular project written in Scala that exemplifies the best parts of the language? I remember having a lukewarm experience with Scala when I tried it several years ago.
That was my point above about being multi-paradigm/having a powerful type system, what’s interesting about the language may depend whether you approach it from a “OOP done right”, “python with types” or “Haskell on steroids” perspective. Akka/pekko and Play projects may be in the first category, projects built with the Scala toolkit may be representative of the second, and typelevel/zio communities like heavy abstractions and pure functional programming a lot.
This approach may induce drastically different looking code, but on the upside, the Scala community seems to be converging towards those 2/3 styles nowadays, vs. the wild west of before where each project was full of its own idiosyncrasies.
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.
The learning curve is an interesting one. We’ve had new devs contribute within a sprint from zero knowledge. When they are contributing to an established platform.
Once they start looking beyond the walled garden things get complex. Scala supports a lot of variety in approaches. Which do they choose? Which is ”better"? Those questions can be hard to answer.
For me the variety of choice is great. For a new dev… Not so much.
C++ has the same issue, and that doesn’t stop everyone from using it.
Seconding what the below poster says. Spark and akka. Akka streams, specifically, was the only real distributed streaming system for a very long time. Which is very, very nice for low latency. Even now it’s tough to beat.
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.
Opinions will be all over the place, and it will depend on your areas of interest, your priorities as a developer, whether you’re willing to climb a steep learning curve before you can do anything useful, etc. If you are just getting started, the usual answer until recently has been start with Python and branch out from there. Your own preferences will make themselves known to you after a while.
Agreed, this question will never have a straight answer. I’d add that if your interest is web development, a good first language would be JavaScript. Python is great too.
Web development is such a horrible quagmire these days that imho it’s best to start in another area.
Let me adjust a little bit: front end web dev is a quagmire. If you want to get involved with web dev, start on the back end. If you move to the front end later, it will be with more systems understanding which will be useful.
I’ll say something even more extreme: before getting involved with web front ends, work on some video games with game devs. The know how to make interfaces responsive, unlike most of the slow crap you see on the web. If you can make front ends that are capable and fast, you will be a god among devs.
When’s the last time you saw a video game that launches in under 100 milliseconds? I bet it was a game written for the web.
At it’s best, the web is very fast.
What web games are you playing? Do you count the time it takes to load the web page? I can’t think of a single game that loads so fast, web or otherwise. agar.io is super slow and bloated, hanab.cards takes about half a second to make a room, candybox2.github.io comes close but the network tab reports 128 ms to download the javascript.
The best language is obviously C++ because it can do everything, and because it’s been paying my bills for the past 20 years.
Best for what? There is no godlike programming language yet.
deleted by creator
Ruby and Python both meet your description quite well. Ruby a bit more so than Python. Ruby refers to the style as Ruby Prose, because it’s meant to be incredibly readable, expressive, and easy to write. I wouldn’t say you should write big code bases in it, mostly because both Ruby and Python are dynamic languages. They both start failing the larger and larger the projects get, not because of speed, but because of typing.
Ruby also has a massive standard library. Things like
.permutations()are even included, making Ruby incredibly readable for complex stuff.Rust: A systems programming language that emphasizes safety, performance, and concurrency.
Out of curiosity why are you replying to yerself so many times?
Could have included it all within yer original post.
To see what people vote.
Adding a link to a poll would have been far easier/expandable/honest
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.
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.
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.
Rust has ruined C++ for me, so pretty damn good!
Do you have some resources on cybersecurity with Rust? I’m not at all experienced in cybersecurity but I’m curious
I used to not like JavaScript when I started, having done C# and Java for about a decade before moving.
But I feel differently now, having spent about a decade with it and having better tools (VSCode, Typescript, eslint). I code in JS, and use JSDocs whenever Typescript’s automatic type detection needs help (
no-implicit-any).The 2015 changes brought a paradigm shift to write more expressive/declarative code and it’s continued from there.
async/awaitis much easier than theFuture<T>in Java. Tree-shaking of imports is great at reducing code bundling size. Classes are also optional, not mandatory which helps simplify code (functionsvsmethods).But for the nerdy stuff, I like I can still pass around functions as objects, something that harder to do in C# (
delegates). It makes building functions more versatile dealing with arguments, so I can pass astring|number|function|Promiseto one function and write more expressivelyhttpPost(variableContent).Not perfect though. The prototype system is powerful if you learn it, but definitely confusing. Multithreading is basically non-existent in usage since you have to essentially convert a function to string (serialize) or script threads into their own file.
I heard
pythonis better for beginners, but I grew up on C style and needs my braces over indents.I’ve always said JavaScript was an elegant language with a horrible implementation. Now that we have typescript and modern ecmascript standards I feel vindicated.
The prototype system is a bit confusing despite being simple, but it’s very powerful despite being simple, which I think balances it out. Also using modern classes abstracts the more confusing bits and you very very rarely need to actually understand the underlying mechanics if ever anymore. Plus you rarely even need classes either with the first class functions.
Parallelism could really improve. Don’t think I’d want to mess with shared memory, but I’d like to be able to pass actual in memory objects instead of having to serialize everything first. Maybe a child process sandbox that can be filled and relinquished once or something like that?
You can use SharedArrayBuffer but honestly it feels like something engineered for one specific purpose (OpenGL).
It would be nice to have shared objects and strings with whatever syntax helps sync locks. You can technically use UTF8 with helpers like
TextDecoder, and I could probably sit and write all that logic using Promises, but I’d imagine the amount of data conversion to make it happen would negate the performance gains from multithreading in the first place.
Python is probably the top non-systems language for productivity and expressiveness right now if you use type hints.
Is there any way of enforcing the use of type hints? I just feel like even when I use them I forget about them most of the time and in that case they are not very useful.
You have to use 3rd party tools like MyPy.
The only thing that will force you to be a good programmer is you.
You can always have a CI step that runs
mypyon your code.
I was using python for quite a bit, but don’t like how cumbersome their types are, I really fell in love with nim when I was looking for alternatives, it’s an underdog, but personally I really like the langauge.
nim looks good at a glance. I tend to stick with marketable programming languages so there are so many I don’t know about. I personally think that using the optional strong typing features are enough to make Python a joy to use. But yes, other people’s code can be cumbersome.
For me it depends on the size, for small stuff like 1000-2000 lines of code that mainly I just work on alone, something like python is okay, if it is something longer, I miss types a lot.
The thing is nim is more than just a typed python, it just works really well, I’ve had a lot of fun with it the two or so years that I’ve used it.
But then again, I have a lot of fun testing out different languages, and don’t care about marketability, since I’m just programming as a hobby, and not as my profession, right now I’m playing around with picolisp, and it’s pretty fun :)
Fun stuff :)
Part of what make Python amazing is pip and everything that’s already been built. For a strongly typed and statically typed language with a large and growing ecosystem I’m drawn to Rust even though I don’t think it’s pretty.
Aww, the hype got to ya… yeah, seeing it again and again, at least don’t do like everyone else who are starting to shill for the language without even having tried it. I’m just tired of rust activism, so tired.
What you call hype I call a strong and growing ecosystem. ;)
Honestly it’s been fun chatting with you. I think we are sort of opposites. You seem to like hobby languages. I like well used languages. You are tired of hearing about what’s popular. I’m excited about other programmers being excited.
I am curious what turned you off when you were actually using Rust. Or did you mostly lose interest because other people endorse it?
I was excited by rust, back when it used sigils instead of box and other keywords, it was an exciting language, I had some fun with it, but it wasn’t ready yet, so I went having fun with some of the languages in its family (ocaml, F#) And when I went back to rust some years ago to write a little tool for myself (https://codeberg.org/sotolf/tapet-rust) to try it out, and it was really cumbersome, and ended up rather slow. I really don’t like the rust syntax, and yes, that is kind of shallow, but there are so many bad choices, like a ; not being there rather than a return, it just doesn’t work for me. Error handling is decent, just that it’s syntactically cumbersome unless you use a package like anyerror, there are packages, so many packages, and what you wanted to make that is just a small tool now has 2 Gb + of build artifacts. I later found out about nim, and rewrote the tool in it, and got a more stable faster tool in a 3rd less code (https://codeberg.org/sotolf/tapet-nim) And the way to work in nim just fits me so much better.
The thing about the rust pushing people (They are funnily enough mostly people that haven’t really used it for much yet, but went into the hype) is not that they are exited about a language, sure I can get that, it’s the way they are pushing it, they talk down about other languages, demand people rewriting things in a language they are exited about, I don’t like the slow compilation and the huge stuff. It’s just not me. Don’t get me wrong I know it’s a good language, just too low level for what I (and most people really) need and it getting pushed for places where it’s not really suited, I don’t really think it’s a good thing. There is also this push for cleverness in their libraries and code, and cleverness in code is always a red flag to me. So it’s not you rust, it’s me.
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.
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.
