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.
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).
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.
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?
https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5
I have been reading it regularly. 
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. 
This is meta discuss. The authors of that topic ask not to do it there.
Then take this into a new subject or DMs, because it doesn’t really belong here either.
I think it is in subject. It is not difficult to create a different subject. Could you suggest its name?
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.
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.
How about this?
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.
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.
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.
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.
Let me share my humble opinion about your last questions.
What is the reason to solve something in Scala?
Because is powerful yet easy to use language which lets me write reliable and scalable software.
what is the Scala way?
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 an explicitly mathematical background.
I disagree. First, it doesn’t apply to a narrow scope of problems, FP is just a different way to address a problem. As such it is applicable to any kind of problem where traditional imperative programming could be applied.
Also, I am largely against the idea that you have to have a PhD in mathematics to use FP, I barely made my undergraduate and it was not at all theoretical (my university even has a focus on administrative, so I even had more classes about finances than calculus or even programming), and yet I have understood FP pretty well (or at least I believe that) so far.
But, I won’t argue about that because I am even more against the idea that we have to have a “Scala way” of doing things.
One of the main reasons I have chosen to use Scala instead of other functional languages is that I am not forced to always go full FP. This is especially useful in the context of simple prototypes. And the flexibility of the language allows you to hide performant and complex imperative solution behind a simple and pure interface.
However, I do think there are a few common best practices that apply no matter if you prefer FP or OOP.
What is at the heart of Scala? Where does it really shine?
Having one of the most powerful compilers out there is a great advantage. Scala shines in proving you with the ability to prove most of the correctness of your code at compile time.
I believe #1 and #3 are quite the consensus in the Scala sphere, but I’m really not sure about #2 and #4. IIUC, #2 stands for using recursion over imperative loop constructs, which is an approach heavily biased towards FP. #4 is also not so much of a consensus, as discussed in this SO question (full disclosure - I am the author of that question).
I would say that this is actually the place where Scala shines the least. The compiler / build process is extremely slow, and that is a huge pain in development.
#2 stands for using recursion over imperative loop constructs, which is an approach heavily biased towards FP. #2 stands for using recursion over imperative loop constructs, which is an approach heavily biased towards FP.
First, I would like to make clear that I used the word prefer with the intention to show that it is more a guideline than a strong rule. I apologies if that is not the exact meaning in English (which isn’t my first language) but that is the meaning of the word “preferir” which is the Spanish translation of that word (my first language).
Second, IMHO, it has been shown that even without going full FP and using effects systems and things like that, Scala power resides in the combination of OOP with FP, using Scala just as an OOP and imperative better Java is not recommended, you are not only no gaining anything. But rather making your life more complicated. If you want a better Java it would be better to use Kotlin.
So, for me, it is safe to say that basic FP constructs are a core for any Scala developer.
Third, #2 refers more to the use of functions like map & filter rather than plain recursion. And, I believe this is a good practice even outside of Scala, other OOP languages like JS, Python, Java and even C++ are including these.
Because, it is hard to argue against the idea that those are cleaner and easier to reason about (not necessary that they are always better, but that is another discussion).
Finally, I agree that #4 is the one with the least consensus, I have made that clear in my first post saying it was the most controversial one of the list. So I won’t go further.
I would say that this is actually the place where Scala shines the least. The compiler / build process is extremely slow, and that is a huge pain in development.
I have to say that I am biased about this one, as all the Scala codebases that I work on, are small enough for that being a problem. Also, IMHO, this is an orthogonal issue, the compiler being slow does not demerit that it is really powerful.
Anyways, I would like to return the question, if the type-safety of the language is not Scala’s strongest point for you, then which one is?
Aha, then I did not understand your initial statement correctly. I most certainly agree that this approach is preferable and that it’s quite the consensus.
I don’t know if I like Scala because it’s a “better Java”; I’m not even sure that I see it that way. I do, however, believe that it’s one of the major advantages that the language has - the ability to (almost) seamlessly use Java’s SDK, libraries and tools.
I’m not sure it’s an orthogonal issue. First, the richness of the language might not come without a cost, but that cost can be mitigated, as is being done with Dotty. Second, there is always the option to give up on expensive features that are not so popular.
Type-safety is hardly a unique feature for Scala. That’s one of the most common characteristics among programming languages. However, I do believe it has a unique combination of these characteristics:
I like your questions. Of course I have no answer for these in general.
But for me personally:
I can see one general area for scala. It is fast reliable data processing.
Because this area requires custom types for each sub domain areas and big performance.
IMHO:The ability to comfortably use custom types with standard libraries without performance overhead is the most powerful feature of scala which is absent in other languages which I have known.
I know only one disadvantage of scala in that area in general. It is a lack of structural types(index-based)
May be there are different ways. But I do not know area where I will choose scala when I do not need custom types. It seems I will prefer java or kotlin where standard jvm types are enough.
Scala has beautiful string interpolation but I do not prefer plain jvm types in the areas where it is really a very important feature for me.
val guid = g"1322030"
for(v <-SQL"""select id from table t where t.guid= ${guid}
""".as(nStr("id").*).sortBy(_.desc) if v.isNotNull){
...
}
all together with type safety:
My thoughts on how to get Scala more popular:
Students almost universally despise Sceme, and Lisp with a passion (arguably also Haskell). It’s for a reason, these languages are very, very impractical. Students should be taught how FP gives value on top of OOP, not instead of it. Scala can do that beautifully!
Emphasize simple features with lots of value: For-comprehensions, Pattern-matching and Case Class ADTs.
One single idiomatic style wouldn’t work so make two. Make an FP-Idiomatic style and an OOP-Idiomatic style. (Or call it FP-Pure-Idiom and OOP-Friendly-Idiom). That should be possible.
Emphasize that Scala combines FP (Friendly People) and OOP (Odd Old Professors).
Uhh, why wouldn’t it work? That’s one of the best things about Scala - its idiomatic style isn’t all that strict and allows for variations of new cross-paradigm designs. Not everything has to be considered “idiomatic”, some can still be just “good practice”.
Although I love the joke, I think that’s an example of one of the things that make Scala less popular - a somewhat snob and elitist approach towards anyone who’s not fully embracing FP.