What can make scala more popular?

Community
193

I think you might have misunderstood what I was trying to say here, which was that Typescript’s success in the JS world does not say anything about Scala’s chance to beat Kotlin as a better Java, rendering it an irrrelevant fact.

I don’t think I misinterpreted you, based on what you say here it seems like I understood you exactly the way you intended. My argument is that people in key roles don’t care about the choice of language safe for personal success or failure stories and factors external to the language’s nature such as availability of talent or regulatory concerns. If anything, introducing a new language is a slight risk that has to be justified. Java not able to make lambdas working with checked exceptions is shambolic but unfortunately not a justification in business’ eyes. What is though is devs preferring a different language because of things like this. And this is what my argument stands on:

Convince the devs, and they will convince the otherwise understandably indifferent decision makers. Don’t convince the devs and decision makers will have one more reason to not move from the mainstream coming from these devs preferences.

The students argument falls nicely into this line of thinking. But since it’s brought up again, it is a nice opportunity to emphasise how much imperative code wrapped in OOP IS software development for a graduate. The equivalence can hardly be overstated wrt most graduates.

It’s @sjrd 's statement, I don’t feel the need to defend it, he might if he’s around.

I don’t think targeting Java devs work as well as it did in the mid-2000’s, the landscape is much more fragmented than it used to be (and also Kotlin is better at that, but we appear to agree on that so I’ll not elaborate). If anything, catering for Java devs might alienate Python ones and vice versa (just examples) while you also can’t cater for everyone. Doing so also imposes otherwise unwanted limitations on the language. That’s why I think Scala should be its own thing instead and be convincing as an absolute rather than in relation to any other language.

Sure familiarity arising from similarity might suffer somewhat and it’s an important drawback. It’s more evenly distributed between devs using different stacks though and that counterbalances it quite a bit I think. That’s also why I’m suggesting other sources of familiarity, I actually believe quite a bit in teaching it to undergrads (big corps are paying $$$ to get their tech taught for a reason, AFAIK). The other way to gain popularity is… to utilize the gains in language design coming from e.g. moving away from the mindset of being a better XXX and make Scala good enough so that it is an appealing alternative.

For context: Scala is never going to be mainstream, and that’s OK. It just needs to be popular enough. If 10% of companies would be using it I’d be happy. All I’m saying is in the context of that. If you want a language to take over another mainstream one, you need Typescript’s approach. But that’s very far from Scala’s way of evolving as is, that would be something completely different.

194

I was merely suggesting that it might be the reason why it got that amount of support from the ecosystem, but you’re right – I don’t know this topic very well. But I believe that this is not a good proxy for popularity; again, that should be based on actual usages – say, appearance on job boards. But let’s not go down that rabbit hole since this is getting irrelevant to the discussion, as I believe we can agree that the majority of Scala is still very JVM centered.

I believe this type of companies – the ones starting off with Scala early on – are quite the minority. Finding employees nowadays is becoming harder and harder it seems, and therefore small startups usually start with technologies that have many developers on the market; meaning, the more popular languages become even more popular, and less popular ones become less popular. Unless, of course, transitions are made in bigger companies that are willing to take a risk or do an experiment.

I’m not saying that the current Scala community mostly came to Scala from Java, I’m saying that if Scala wants to become vastly more popular, it needs to draw developers from other languages, and I believe that with the current state of affairs it’s easier to achieve that by catering for developers of one very similar language rather than trying to cater for developers of all languages.

195

Being the best language and ecosystem we can be according to our own vision leading to people adopting the language sounds like a more appealing strategy than changing what we value because that may appeal to some specific subgroup of companies because we believe that’s where we can unlock the most growth. I don’t believe growth lies in that direction, and I certainly don’t think we can all agree on that.

7 Likes
196

It must be called Scala.js because it’s a jouet de Séb.

(Edit: my French ami says you never spell the short form with the accent, sorry about that.)

1 Like
197

I’ll put the catering for a specific (and quite large) subgroup argument aside because I believe we have exhausted that discussion.

What is, though, this vision that we have? How is Scala going to be best language? How does it compare to other languages and being better?

And who’s “we”? Ever since I came into the Scala world 4 years ago, I had the notion that the community is somewhat divided on how to approach the language and its design. Many best practices vary drastically from camp to camp. There are of course a lot of concepts that differ from many other languages and that most of the Scala world agree on (immutability, for instance), but I’ve seen so many other cases where a specific group is very opinionated about a certain concept, advocating it as if it is the idiomatic way to go about, when in fact many others disagree on that.

1 Like
198

I think it is right direction.
Nevertheless there are some difficulties.
Martin has written :
I see this difference of approaches as a big opportunity. There are so many great ideas to debate and opportunities to learn from each other! Lots of these ideas feed into the design of Scala 3, with the overall goal to make Scala’s integration of paradigms even tighter than it is now, as well as making it simpler and safer.

Scala is integration of paradigms. It is great. But it can make almost everything kitchen syndrome.

I can see it in these topic. It creates the high wall between scala community and other world. It seems it is a communication problem :slight_smile: I think it can be overcome by good business task oriented documentation. IMHO scala has a lack of such documentation. The current documentation is too philosophical in high level(scala for business).

199

This is a really misleading use of statistics. Since Scala.js goes out of its way extensively to make sure that compiling to Javascript is as transparent as possible, most Scala.js questions are specific to integration and issues specific to Javascript within context of Scala.js, i.e. I may have a Scala.js application but if I am getting some generic compiler or type error I would not tag the question on Stackoverflow as Scala.js because it has nothing specfifically to do with Scala.js.

On the other hand if I have an issue in Scala.js interopting with some Javascript library than I would tag this with Scala.js and that is precisely what you tend to find for both search queries and stack overflow questions tagged with Scala.js.

7 Likes
200

I would argue that claiming Scala.js is popular needs better evidence. There is currently no statistic to support this claim.

Plain downloads count is not a very good indication for popularity. It may be a start, but you really need more than that to assess the usage of software.

Furthermore, full download statistics for Scala are not even available. Most packages on bintray, for example, don’t have the download numbers publicly available. This has been brought up in an issue on Scaladex’s repository.

In order to try and improve Scala’s popularity, one has to establish what that popularity means and how it can be reliably measured; otherwise, this entire discussion is a bundle of speculations and not much more than that.

201

Sure, but you can argue this either way. My point was simply that your way of using stastics was misleading (one way or another).

Using download statistics is arguably more accurate because you only download Scala.js if you are using it in your project otherwise it doesn’t even download, it’s not a normal transitive dependency in this regard.

1 Like
202

More accurate perhaps, but still largely inaccurate and can’t be relied on. Many downloads could be just for trying out the library and not actually using it long-term, or in any real world project (open source or commercial). Some of the real-world projects that use the library might only be importing it to make sure they are compatible with the library (in tests), but they don’t actually make use of it (in production).

I would argue that appearance in job listings is a better proxy (which is still somewhat easy to obtain).

203

Actually the variable is immutable. It is just initialized outside a constructor.

There are many others things that sure me that concept is unfriendly. It doesn’t not solve tasks. it tries to restrict use case.

I doesn’t have qualification to argue. Actually I do not understand it.
I can’t understand motivation for such dead simplicity.
I can’t understand simplicity.
But I am sure simple restrictions by virtual rules doesn’t make a language popular.

204

We’re well into tangent territory here, but essentially the external initialization means you’re introducing a race condition on that initialization. You probably know this already, because unless you have a really well built framework protecting you, I’d bet dollars to doughnuts this has caused trouble for you.

We’ve got some code that does this (dependency on a database), and you have to be very careful how you access them to avoid issues. It’s absolutely a race condition, regardless of it it’s changed once the initialization is complete.

Also: I think you may have posted to the wrong thread. Was this supposed to be here?

205

https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5

I have been reading it regularly. :smirk:

I have been developing such framework more than 5 years. It is not simple task, but It have been working in production already.

I have been working with databases more than 15 years. So I have known many ways to shoot in the foot🙂
And immutability is a also a good way. :slightly_smiling_face:

This is meta discuss. The authors of that topic ask not to do it there.

206

Then take this into a new subject or DMs, because it doesn’t really belong here either.

207

I think it is in subject. It is not difficult to create a different subject. Could you suggest its name?

208

You’d like to have support for var backed implicits, so if you’re going to ask for that support, open a thread doing so.

I don’t particularly care for that proposal, so I’m not going to put in the work to help it along. I’ve got too much to do for the time I have as it is.

1 Like
209

While it was about “lateinit” I did not take a part at the discussion. I just had said that it was inconvenient. But currently I think that it is wrong principle at whole I have already said it either.
It seems that there are no question to discuss any more.
Thank you.

210

How about this?

211

Lots of good points made already within this thread.

A fair part of this discussion takes a marketing approach to the topic. For marketing, you need to (1) have (know, understand) a target group, (2) address and reach that target group, (3) convince people and last but not least (4) keep them invested.

However, while marketing is certainly a valid approach, it tends to overlook other aspects, which likewise matter for a programming language ecosystem to be alive and thrive.

Programming is a craft, and as programmers, we spend a huge fraction of our live in exerting our craft. The programming language ecosystem defines the space, the place where this happens. And as such this needs to be a good place to stay.

  • there must be a reason in doing the craft this way
  • things need to be at hand
  • you need to be empowered to perform your work
  • and matters need to be at ease.

Just take a look at various programming language ecosystems which succeed in becoming and staying relevant. Also consider some examples which fail and fall into obsolescence, where most people start to put “getting away from here” on their agenda.

Consider Perl. Perl made doing simple things simple, and allowed you to do the complicated ones. And this was not just marketing speech, rather, this was a truth. Everyone who used Perl in depth can confirm that. IMHO this is a very important point: the inner reason why you choose a tool needs to be constantly reconfirmed. Every day you work.

But unfortunately Perl failed to resolve some of its long-standing quirkiness. It was unable to support the growth of a code base, structuring, modularisation, building abstractions other parts can rely upon, without the need to “open the box”. And, lastly, a very late attempt to address some of these points caused a state of fear, uncertainty and doubt.

Have a look at Java. Without doubt, the language itself is dull and deaf. Yet still, working e.g. as java backend developer on mission critical enterprise services is an enjoyable experience. The language is quite opinionated; there is a clear-cut “java way” of doing things, with some marginal flavours to choose from. “Holy style wars” are mostly non-existent. There is a standard way of naming things, which is clear and explicit, albeit somewhat verbose. Which is not much of a problem, because the java ecosystem offers the most complete, mature and powerful tooling you can imagine. And you are highly empowered to do your actual work. The readily available free standard tooling supports even the more advanced operations problems, like monitoring, profiling, versioning, CI and deployment. And up to now, Java successfully managed to move ahead and incorporated some pragmatically chosen moderately modern concepts.

In the late 90ies, the C++ language was a sinking ship. At that time, you found yourselves “forced to code something in C++”. Then something astounding happened. The people on the bridge set a course towards future and maintained that, without a wiggle, for more than 10 years to come. They really embraced the state-of-affairs instead of abandoning it. Most notably, they embraced template metaprogramming, and turned it from an exotic, curious after-the-fact discovery, from a quirky workaround into a core pillar of the envisioned smaller, cleaner more modern language struggling to get out. And even more fascinating, the vision of the modern language turns out to be the old one: building zero-overhead high level abstractions. Thus, modern C++ empowers the developer to build large-scale, demanding and mission-critical systems, while reliably controlling and encapsulating a lot of intricate low-level details and warts. After the last language standard iterations, working with C++ is an enjoyable experience. Not so much writing C++, which tends to be tedious. But, after all, 90% of the time you read and maybe adapt existing code. And with that, the ability of modern C++ pays off to express the solution for some given problem cleanly and concise, yet still without compromise.

Some Conclusions

  • what is the reason to solve something in Scala?
    • we need to be able to answer that in a single sentence!
    • this single sentence must be understandable and obvious
    • and it must correspond to the inner truth of matters
    • and this must be reconfirmed every day when writing Scala code solving everyday mundane problems.
  • what is the Scala way?
    • can we show what is a typical Scala approach?
    • “we have a problem here”. The Haskell-like extreme FP-style can not be it, because it covers only a narrow scope of problems and appeals only to a very limited group of developers with explicitly mathematical background.
    • yet such a sub-style is not a problem in itself. Also people promoting such a specific advanced style are just fine, and can be inspiring to the community as a whole.
    • what is problematic is that the Scala mainstream is fuzzy. We are not opinionated enough in that respect. It is still somewhat hard to grasp what idiomatic Scala looks like. “Everything goes” is not enough to keep a language relevant. We need to decide what is good, what is bad and what is ugly.
  • what is at the heart of Scala? Where does it really shine?
    • can we define a small coherent set of ideas/concepts/constructs which suffice to grasp “this is Scala”
    • and how do precisely those ideas help solving problems in an unique and empowering way?

I personally think, we should not foremost aim at “popularity”. Others are better with that. And, last but not least, popularity comes as a side-effect after you did your homework. Sure, it does not come for free, but first things first.

It is not enough when a programming language is interesting.
Rather, a programming language must be convincing in order to stay.

5 Likes
212

We might need a separate bikeshedding topic on renaming Dotty to Doti.

That would gibe with Java as a place name. Wikipedia says the highest peak is Api, so the t-shirt could pun on reaching Peak API.

There is also the expression about “dotting your i’s” to mean polishing to a high gloss.

Dotty is a nickname for Dorothy; in Middlemarch, Dorothea’s sister calls her Dodo, which might suggest a language heading for extinction. But Dorothea means “God’s gift”, as in, “Dotty is God’s gift to coders everywhere.”

A propos of Middlemarch, Mrs Garth tells her husband, “Some men take to drinking, and you have taken to working without pay. You must indulge yourself a little less in that.” I don’t actually know that Caleb Garth contributed to open source, but I recognize the hazard in that.

2 Likes