I am glad to hear it.
https://contributors.scala-lang.org/t/discussion-about-structural-types-index-based/
I hope I have been able to explain why I think that structural types should be index based at least to big data.
- Records were never meant to be index based, thus thereās no abstraction leak.
- Pinpointing problems is much easier than pinpoining solutions. I have told you about megamorphic methods. Devirtualizing them efficiently would improve overall performance of Java, Scala, Kotlin, etc to a much higher extent than exotic features like records.
- Nobody has any idea how index-based polymorphic records are supposed to work in the compiler (Iām actually curious about that), but you somehow tell that itās obvious and refuse to elaborate on the idea or even provide complete working code that needs improving.
I guess complaining is everything you can do (yeah). You need to shift the energy to properly describing your idea instead.
thatās why we just donāt use them 
I just do not want to be trolled. there are no direct question which have not been tried to answer by me.
So I try to avoid such discussion. It is obvious
I better follow the Martinās advice:
- If we take us as individuals, the answer is that we can and will stop interacting with people whose behavior we object to.
So if some questions seem suspectible for me, I will not insist on continuing discussion. If someone regularly provocates me instead of making a good question or proposal I do not understand why I owe him something.
Iāve stated them in a post above yours:
Somehow asking for complete working code to improve upon is asking too much. It seems you have http://xyproblem.info/ - we donāt see the original problem (i.e. code that can be improved), but instead youāre asking us to finish your obscure solution.
2 Likes
It is not too much, but I can reject your asking without any blaiming if I think it has no sense. Can I have my own opinionā¦
You can open and read CoC. It has been violated too much, letās stop.
1 Like
This style of debate is not encouraged here and this thread has gone completely out of topic. Please, keep your comments concise and on point.
8 Likes
Iām coming late to this discussion and I admit to have skipped many of the comments (encouraged by @jvican 's last comment), so I might repeat some of the proposals that have been discussed already.
Let me start with some more practical ideas. These may be obvious and already being worked on, but I feel like itās worth mentioning them anyhow:
- Reduce compilation time. I believe this is the number one reason developers refrain from using the language.
- Target popular IDEs other than IntelliJ. Eclipse, VSCode, etc.
- Add support for popular online REPL, such as https://repl.it
- Add guides / tutorials / courses in popular educational websites, such as https://www.codecademy.com/
There is also one more strategical concept that I believe needs to be adopted, and that is better catering Scala for Java developers.
Java is one of the most popular languages out there, and it is closely related to Scala, especially when it comes to technicalities and migration efforts. I strongly believe that targeting Java developers as potential Scala newcomers is the way to go.
How does one cater for Java? Primarily, by fully adopting many of Javaās already existing libraries and tools as part of the Scala ecosystem, treating them as first-class tools and not second-class. Scala does not need another testing tool, another mocking tool or another build tool. There is no problem having these around, but they should not be the go-to solutions, and should not be the focal interest of the community. The Java counterparts are more mature and have a bigger community, and they work well with Scala.
One of the biggest examples for this is the outdated support for Scala in Gradle ā one of the more popular Java build tools. This is only being addressed now, and not by any of the community āleadersā, but rather by Gradle Inc itself. Instead, the community seems focused on adopting Mill, which is in such an early stage that it doesnāt even run JUnit tests, making it largely obsolete for Java-Scala projects.
1 Like
While I understand and sympathize with this viewpoint, I donāt really agree, for a couple of reasons.
First, the separate Scala tools didnāt come out of nowhere ā they evolved because the existing Java tools didnāt work as well as one might wish in the Scala context. For example, you say:
I donāt think thatās true. ScalaTest is easier to use for idiomatic Scala code than JUnit is ā thereās less boilerplate, and it leverages Scalaās power to do a lot of cool things easily. And ScalaCheck is hella powerful, and remarkably easy to use.
Mockito, IMO, is terrible for Scala code (we do use it a moderate amount, and I spend too much time helping fix problems caused by it), because it is fairly weakly-typed and null-centric, both of which are a poor match for Scala, so the resulting tests tend to be brittle. (Granted, ScalaMock isnāt perfect either, but itās at least better-typed.)
sbt, for all folks complain about it, became popular because folks found the common Java alternatives painful to maintain big Scala projects. I know several people who have tried the Java alternatives because they were so annoyed at sbt, and wound up coming back to sbt afterwords because they found it the least-bad option.
Not to mention that Scala now runs on platforms that Java doesnāt. You must use Scalaās own test tools if youāre going to test cross-platform, which many projects do nowadays. Scalaās environment is now a superset of Javaās, so the Java ecosystem doesnāt cover all of its needs.
I think youāre coming at this from a somewhat Java-centric viewpoint, and that was once absolutely central for Scala ā but the world has moved on. When Iām training up new folks, theyāre as likely to come from a background of JavaScript, or Python, or Ruby as they are from Java. (Personally, I came from C#.) When you are coming at Scala from Java, it seems weird to see āredundantā tooling like this; but when you arenāt, the Scala tooling (IMO) looks more appropriate and focused on the task at hand than its Java counterparts.
The different toolsets does make it more of a challenge for Java-centric companies to adopt Scala ā the same way it would be a challenge for them to adopt Ruby or C# or whatever. But Iām skeptical that it is much of a challenge for individual engineers to pick up Scala. Iāve been training up a bunch of Java folks recently, and all of them have picked up the Scala tooling quickly, easily and enthusiastically. So one shouldnāt over-estimate this issue.
Iāll totally grant that Scalaās homebrewed tooling hasnāt been historically as mature and robust as weād like. But the community has woken to that in the past couple of years, and tooling development has gone from being an afterthought to being pretty front-and-center. Iāve been really happy to see the rapid and dramatic improvements of everything from sbt to editor support over the past couple of years. Thereās still a long ways to go, but it now feels like weāre getting to the point of having an ecosystem we can be proud of, which suits Scala well.
I think thatās an overstatement, although an understandable one. Folks talk about Mill a lot, because itās New and Cool, and in some ways is easier to understand and more easily-powerful than sbt. But Iāve seen relatively little Mill usage in the wild yet. Weāre only using it for one of our hundreds of Scala projects ā and that only because itās a fork of uPickle, which was already using Mill.
I think Mill might eventually become one of the dominant tools, but I believe adoption is still pretty modest at this point, and growing slowly. It is early-stage and somewhat immature, everyone knows that, and itās going to take a while (if ever) before any sort of critical mass of projects moves to itā¦
6 Likes
I came from Java, and ScalaTest was a selling point, not an obstacle. JUnit only felt easy to use because I wasnāt exposed to better alternatives, and I feel that adopting it as the testing library would be a huge step backwards.
4 Likes
Since I I wrote 2 or 3 comments arguing for the exact opposite you might want to read those and reply to them (you mention you skipped some so I guess that includes mine). It would be interesting to see your counterarguments.
1 Like
ā¦i.e. Kotlin being backed by Google (and Jetbrains) making it the dominant alternative JVM language and it being a better Java than Scala is, as I argued above.
(I understand this is somewhat radical but Iāll put it out here just as a thought.)
Thinking about this, if we accept this as true I think it might be time to re-evaluate the benefits of being tied to the JVM. It might not be the adoption driving force it used to be.
The Java ecosystem is still valuable, probably the the biggest benefit. Scala however has a pretty nice if somewhat fragmented ecosystem by now, probably enough to keep the language in the industry alive.
Itās not a given anymore that potential adopters have JVMs running already everywhere.
Itās not a given anymore that potential adopters come from a Java background (see @jducoeur 's anecdotal evidence)
If I understand correctly in the near future this will be a question of compiling TASTY to your preferred target.
It is now possible to compile Scala to Clang and JS (I donāt know a lot about this)
Iām not sure how good the JVMās future looks like with GraalVM coming to life. Orcale might just kill it as a redundant product. Wouldnāt be surprised.
There is a handful of limitations imposed by the fact that Scala is primarily a JVM language, right?
Any chance that moving away from the JVM to native and JS as equal targets would by now outweigh the drawbacks adoption-wise and with regards to a potential hit the ecosystem would have tot take?
2 Likes
I have my reservations with the mileage we can get out of making scala more attractive for people who really dislike scala, or changing scala to become more like the language you want to appeal to.
If you want to appeal to Java programmers to win them over, becoming more like Java may not be so much of an incentive for them to switch, but rather reduce or eliminate the reason to switch.
It is pretty difficult to gauge what a java programmer that prefers not to be a java programmer prefers, and Iām apprehensive of making too many assumptions about it.
8 Likes
IntelliJ has a decent ātranslate this Java to Scalaā feature, so it might be worth considering bringing along a subset of Java libraries. Even if the JVM remains the primary compilation target, Iād image the ScalaJS folks could make good use of something like this.
1 Like
Perhaps ā erasure is generally cited as the poster child for that. OTOH, erasure is so deeply baked into the language that Iām not at all sure you could straightforwardly undo that without breaking stuff all over the place. (And IIRC, the alternatives to erasure are themselves controversial, so I donāt take it for granted that we would necessarily want to undo that even if we could; I canāt say I know the topic well, though.)
More importantly, while I think the JVM is no longer as much the center of the Scala universe as it once was, compatibility with a programās runtime environment is a general priority for Scala, wherever it runs. Interoperability with JS libraries is crucial in the browser; I assume that interoperability with native libraries is a priority for Scala Native. Thatās a key part of Scalaās āDNAā ā interoperability should work well. So while the JVM might not dictate all decisions, it does necessarily influence them, so that we can have good interoperability with JVM librariesā¦
3 Likes
Iām no longer sure that type erasure is as big a limitation as I used to think. Iām not sure that the general case of a FunctionN can be specialised in any language. But it could be interesting to try.
Iāll try to reply to all of you at once, @jducoeur @Tom_Poczos @martijnhoekstra, since I feel like you are coming from the same place and with a similar mindset. Iām also going to put aside the arguments over specific Java tools vs Scala, as I believe our opinions are currently divided on a more fundamental level.
In order to gain popularity, Scala needs to either find a new application domain, or to compete / cater for programmers of other languages. I think we all agree on that. My opinion is that itās also absolutely necessary to focus on one segment and one segment only. Trying to cater for both Python and JS simultaneously (just an example) is doomed to fail IMHO. Side-projects, such as Scala.js, are always welcome, but they should be seen as so. They should not dictate major decisions in the language, unless theyāve already become the majority.
What segment should Scala focus on? I canāt say for certain. As for a new application domain, Iām completely oblivious. As for catering for devs of another popular language, I believe that Java is the right choice here.
Iāll start my argument for this by first noting that in my opinion, students and universities are minor factor of popularity compared to developers working for / with commercial companies and startups in the industry. The working industry is where the money is, and money attracts the masses. Students have no experience and make no decisions, while educational institutions largely adapt to what the industry is looking for, and not vice versa; i.e, the industry does not change its technologies according to what students are being taught in universities and boot-camps.
I feel that Java, C/C++, JS and Python largely dominate the industry, and for quite some time. Iām loosely basing this on online published estimations (PYPL popularity, TIOBE, StackOverflow survey), and on my own experience from the companies I know and the job positions Iām seeing where I live (Israel). Therefore, I believe if Scala to cater for any developers, itās for one of these languages. Among these languages, Java seems to me as largely the best candidate, and for multiple reasons.
-
Scala is statically typed and compiled. This vertical is one that I feel really divides developers, so it seems to me that Scala inherently cater better to these types of languages ā Java and C in this collection.
-
Scalaās applicative uses are very back-end oriented, which is another major vertical in my opinion. From what Iām seeing in the industry, Java and Python are more back-end oriented (Iām putting Android Java aside), JS is front-end oriented, and C is nowadays more low-level oriented (high performance applications, security, embedded, etc).
-
Scala is a JVM language. It is not a multi-platform language. Having a side-project implement Scala for JS does not change that; side-project means being not popular and maintained by a very small team. Stating that Scala is multi-platform based on this reasoning is tantamount to stating that Python is also a JVM language since thereās Jython.
As for competitions, I must say that I donāt a lot about Kotlin, and how it compares with Scala. However, I donāt believe this state of affairs is any different for the other languages. JS for instance, already has a large growing community of a statically typed alternative ā Typescript. Iām less familiar with the Python state of affairs, but based on what Iām hearing from many of my colleagues who are mainly Python developers, they love Python and donāt want a statically typed alternative.
So yes, focusing on catering for Java developers is the best approach I believe. This clearly does not mean making the language more Java-like (itās already quite similar to Java, to be honest). This also does not mean to assume that Java developers donāt like being Java developers. These are straw-man arguments. Java developers love being Java developers, but Scala can offer an even better alternative for them. This is not due to Scalaās specific tools or ecosystem ā quite the contrary, it only distances them ā but because of the language itself and its unique approach - a mix of imperative, OOP and functional programming.
Scala also needs not to focus on individuals, but rather focus on companies. Companies, as Iāve argued before, dictate which languages will strive. Curious individuals are perhaps necessary to get a language going and gaining some popularity, but they cannot turn the tide. Scala is already popular enough that it can stop trying to appease to all kinds of different small fish, and start targeting a specific type of whales.
If (and only if) we can agree on that, then I would further argue that Scala should mostly adopt Javaās tools and ecosystem. Those tools are perfectly suitable for Scala (for instance, I donāt see why Mockito isnāt a good fit), and they are more mature, more stable, have bigger a community, more maintainers, and sometimes better features (Iāve made such a comparison not too long ago between SBT and Gradle). Most importantly, itās what the Java-based companies already use, and they do so because this ecosystem has proven itself to be able to scale.
Could you eleborate on what ācompete / cater for programmers of other languages.ā means? Without that, I donāt think itās possible to agree.
Make developers who mostly use a certain language convert to mostly using Scala; and again, this is more relevant not to individuals but rather to entire companies (small startups are companies too). Iām not necessarily expecting Scala to surpass the popularity of any of the big languages, but itās just that they have the most developers, and therefore a bigger pool to fish from.
Waw, I think you widely underestimate the popularity of Scala.js and the maintenance that goes into it.
Several estimates (StackOverflow, IntelliJ survey, Gitter rooms, download numbers, etc.) more or less converge to say that Scala.js represents about 10% of the Scala marketshare. It is far from being a majority, but you canāt dismiss it as easily as saying āitās a side-projectā and āitās not popularā.
Also, you say it is maintained by a very small team. Thatās true for the core, but also it only needs to be maintained by a very small team, because the scope of Scala.js core is very limited. Scala.js reuses the hard work done by the Scala core team on everything from language design to compiler implementation up to the back-end. Scala.js only reimplements the compiler back-end, with a strategy to emit JS code instead of JVM bytecode. If you want to compare apples with apples, you should compare the size of the team working on Scala.js with the set of people maintaining the Scala/JVM back-end (i.e., GenBCode). That team is as small or even smaller than the team maintaining Scala.js.
8 Likes
No, we donāt all agree that in order for scala to grow, companies must to convert to mostly using scala from a different language. Companies using scala on the side is a perfectly reasonable way to grow too, as is new companies using scala.
In general, I think your post is very black and white. We must convince companies to switch to scala in majority in order to grow, scala is a JVM language because scala.js is maintained by a smaller group of people, so we must focus on the JVM part of things only, so we must convince companies that predominantly use Java to start predominantly using Scala in order for scala to grow, which means we must start using the tools they use, because those companies will not switch when we donāt.
I donāt think any of those things are very true, and I donāt think that with such an unnuanced perspective, there is room for further discussion about that.
2 Likes