What can make scala more popular?

Community
81

IMHO, it is enough to have comparison of main use cases for a certain business area. For our company the most important features are:

  • hight level data manipulation scala win because of collection(high priority), implicit(questionable priority in kotlin), operator overloading and value calsses (questionable priority in kotlin)
for (ropDet <- Stk_WarrantOutDetApi().byParent(rop)) {
      val roaDet = ropDet.copyAro()
      val idvWarrantDet = roaDet.id
      var nvCostBaseSum = roaDet.nCostBase
      var nvQtyGetBaseSum = roaDet.nQtyGetBase
      var idavDetItem = new ListBuffer[NLong]()
      var navPrimeSum = new ListBuffer[NNumber]()
      if (bvDetItemTypeExists === 1.nn) {
        val rvaWarrantDetItem = (for (rp <- Stk_WarrantOutDetItemApi().byParent(ropDet))
          yield rp).toSeq.sortBy(_ :> { aro => aro.nQtyGetBase })
        for (ropDetItem <- rvaWarrantDetItem) {
          val roaDetItem = ropDetItem.copyAro()
          val nvCostBase = (nvCostBaseSum / nvQtyGetBaseSum * roaDetItem.nQtyGetBase).round(2.nn)
          nvCostBaseSum -= nvCostBase
          nvQtyGetBaseSum -= roaDetItem.nQtyGetBase
          //Š·Š°ŠæŠ¾Š»Š½ŠµŠ½ŠøŠµ ŠŗŠ¾Š»Š»ŠµŠŗцŠøŠ¹
          idavDetItem += roaDetItem.id
          navPrimeSum += nvCostBase
        }
        //Š”Š¾Š·Š“Š°Š½ŠøŠµ Š¾ŠæŠµŃ€Š°Ń†ŠøŠ¹ Š¾Ń‚ Š“ŠµŃ‚Š°Š»ŠøŠ·Š°Ń†ŠøŠ¹
        Stk_WarrantOutDetItemApi().insertOperationByWarrantDetItem(idavDetItem.toList, idvWarrantDet, navPrimeSum.toList)
      } else idavDet += idvWarrantDet
    }
  • string intorpolation(java loses)
  • jdbc intergration(scala loses)
  • named arguments(java loses)

All other features do not influence to performance of programmers significantly in comparison to other languages.

82

Thank you very much for this offer! I agree it would be great to display this prominently. Would you be OK with people making changes to the document as the language evolves?

3 Likes
83

Oh yes, definitely. I donā€™t know much about licenses, but my initial thought was to transfer the license for the bookā€™s material to the scala-lang.org website and/or EPFL, and stop selling the print and PDF versions of the book. I guess if itā€™s ever re-sold as a for-profit book I wouldnā€™t argue with receiving a small percentage of the royalties, but thatā€™s not a concern. (Or if the book profits could go to the Scala Center or EPFL, that would be awesome.)

Iā€™m open to anything, whatever helps people get started with Scala. I can also help update and maintain it a few hours a week.

9 Likes
84

Thatā€™s very generous of you. Thank you in advance! I think the next step should be that someone at the ScalaCenter will get back to you about this. It wonā€™t be immediate since people are away right now, but hopefully soon.

2 Likes
85

Okay, sounds great ā€” thanks!

1 Like
86

Having a stable, standard, supported and free development environment. The scala-ode was it. Unfortunately it has been dropped.
Eclipse had a massive amount of support. C, FORTRAN, other languages, XML, UML/MDL, print engines, database support, just to get started. Even if IntelliJ could offer those add those features, new incubators are forming all of the time. Itā€™s the Apache of development environment. IBM gave them BIRT because it was cheaper for them to maintain and develop than hold the large product in house. IBM is still the main contributor, itā€™s that strategic for them.

IntelliJ doesnā€™t cut it. It never will. Perhaps if everyone paid a lot for it they could afford the research and develop men. But scala will suffer for it.

Every enterprise shop already uses Eclipse and Apache. I was an Enterprise Architect for American Express. We might have a small team or two using scala with JetBrains, we would never allow that to roll out. The simplest reason would be managing yet another large development suite on developerā€™s desktops. Second would be training. Third would be advanced training. Sending people to eclipse world hits dozens of stones at one. A JetBrains conference? Two or three might go, out of a IT shop of tens of thousands world wide.

Thatā€™s another problem. Most departments have developers in the US, Europe, ASIA, some in South America. Another death-knell for IntelleJ. Managing things in Vietnam, India, Philippines, US, England would be difficult at best. Ensuring our contracting firms paid for their licensing would just raise the cost of the contract. Eclipse - free for contractors that are hired for their low costs. Add in a fixed cost (licensing) and they stop being as cost effective.

SBT is another problem. Though a lesser one. For accountability, itā€™s important to have a well documented build process. Quality and avoiding liability is a big thing. Maintenance contracts are changed from year to year. An entire project need to get up and move. Having yet-another-build-tool doesnā€™t help. It doesnā€™t hurt that much either. Every team has some unique build tool. Itā€™s free and open. Other than being yet another tool, itā€™s biggest problem is that it does too much. If it gets used for more than one or two things, the auditors would need to learn the language. That would make the enterprise QA people unhappy.

Licensing JetBrains and hiring consults in the US wouldnā€™t be a barrier. Tying your horse to IntelleJ cart will ensure there is only a small number of shops pick it up.

None of this is about scala. Bringing a new language into a project would be a hard sell. Depending on the project, maintenance might be farmed out to contractors. Contractors for Java is easy. Part of that reason is Eclipse, part of it is that it just has more followers. Companies that can construct a scala team easily will be expensive. So there is inbuilt impedance there. That will take work to sell to management. Having the problem of selling a new development environment will make it much worse.

2 Likes
87

Having scala be taught at colleges and universities is important. Thinking functional has to be taught to most people. It is a critical skill. MIT used scheme* for decades as its intro-to-cs class. Itā€™s hard. Hard enough that they gave up and now use Python.

Functional programming is probably taught in Haskel at most schools. its good enough that students need not look further. Scala has a lower skill-impedance for most people. It might make it a better language for teaching. Getting some academic considerations will help. It talks twenty years or so for a new idea to become part of software delivery. It wonā€™t be fast.

  • Scheme is too small to be a useful language itself. The free CLOS environments donā€™t include the xml and web bits, so they wonā€™t get used.
88

Commit body and soul to Apache. The scala community is too insular. Being ā€œApache Scalaā€ is important. It doesnā€™t require much change in how the community actually works. Once established, the teams are left alone.

Most every real scala based project will be using some Apache tooling anyway. Becoming a full fledged part of that community would help with image. Too many groups trying to move the tiller avoid the major support groups. Haskell, for instance, is trying to build a new more beautiful world. It doesnā€™t want to be sullied with the stench of the pragmatists at Apache. But it is moving in now. Integrating in tiny steps (like thrift) can help.

The biggest win is just being part of Apache.

89

Yes, and for good reason. The hard numbers were showing time and time again that the vast majority of Scala users were favouring IntelliJ. Yes, even ā€œenterprise shopsā€

Supporting ScalaIDE was a drain on resources. It took developer time away from other more productive tasks, and it was a real pain. The Eclipse project model was never a good fit, and being able to handle subprojects and different versions of Scala within the same plugin proved to be the very definition of pain.

They also use VS.code if they do any web development whatsoeverā€¦ and this is where youā€™ll find the heir-apparent to ScalaIDE. Not in IntelliJ, which is something that JetBrains did of their own volition with their own devs.

The future is compile servers, via Bloop and Metals. IntelliJ are certainly interested in using this to make their lives easier, and it supports several editors (VIM, emacs, sublime, atom, VS.code) of which VS.code is far and away the most popular.

If we get a reboot of the Eclipse support, this is the technology itā€™ll be based upon. At which point the same functionality will be available to any editor/IDE that chooses to adopt itā€¦ Making Eclipse one amongst equals.

5 Likes
90

Thatā€™s only semi-true. Eclipse itself might be supported, but the Scala-IDE plugin has been limping along for a long time. I was using it until about six months ago, but for years Iā€™ve often the only person in any given conversation doing so. The community largely gave up on it ages ago.

By contrast, IntelliJ is well-supported, used by a large majority of developers (especially in enterprise environments ā€“ I work in a substantial Scala enterprise shop and AFAIK Eclipse is one of the few editors that nobody uses), and for better or worse has become the de facto standard. And while the free version doesnā€™t have all the bells and whistles, it works well enough that a large fraction of the Scala community uses it as their standard IDE.

Seriously ā€“ I think youā€™re empirically incorrect on this score. Yes, shops that have decided that Eclipse is the one-and-only IDE will have a problem with it, but I donā€™t offhand know of any place that was seriously interested in Scala where this proved a serious impediment. Eclipse is very popular in some circles, but itā€™s by no means the be-all-and-end-all.

And as @kevinwright says, LSP is going to take over next, allowing folks a broad array of editor choices (including Eclipse) with official support built into the compiler. Thatā€™s well along, and is built into Dotty from the outset.

5 Likes
91

Unfortunately David Bernard was too ahead of his timeā€¦

92

Thatā€™s the point. Places disinterested or hostile to bringing in a new language wonā€™t allow scala in at all unless it attempts to match the standard development environment for the corporation. If it going to be used by mid re than 1% of the population, it canā€™t be in an island by itself. ā€” I donā€™t work any longer, I donā€™t know what has happened in the past few years. Every shop that had IBM equipment, or IBM or Oracle databases used Eclipse and BIRT. For smaller systems they used Apache servers & datastores. In other words, every large company. ā€” There are always small groups going off and doing their own thing. Those groups tend to have a short lifespan. Management typically will kill the project and buy something off the shelf, even if it doesnā€™t meet the needs of the business unit. It doesnā€™t make sense, but itā€™s how senior management thinks. ā€” The question was how to make scala more popular. People that are already committed to using scala and IJ arenā€™t the subject of the question. FP is hard for the average programmer to understand. Scala is a language they donā€™t know. If they also have to give up the wealth of free tools from eclipse and Apache, itā€™s a non-starter. IJ is a particularly horrible choice. It doesnā€™t follow any meaningful UI standard. Another, perhaps worse, problem. ā€” Scala canā€™t be so arrogant that they force the world to revolve around them. Like it or not, they must exist in the real world. They made a great decision to use the jvm. It opened up the entire java environment to them. Haskel hasnā€™t done that, and it suffers. Scala needs to work within the corporate world. The corporate world certainly wonā€™t make an effort to use a new programming language. Look how long COBOL lasted. It wasnā€™t until RDBs became common, used java for stored procedures, was the primary language for the new world of the www that they dropped COBOL. ā€” Sorry about using dashes for paragraph breaks. If I hit enter on my phone is posts the reply.

93

Please donā€™t drain your limited resource on ScalaIDE!

2 Likes
94

True, we at alibaba mostly use IDEA and VSCode.

1 Like
95

At ScalaDays I asked the people at the IntelliJ booth if they thought they might augment or replace parts of the IDEA Scala plugin with a language server like metals. To make IntelliJ always agree with the real compiler. And they said no.

Compile servers (bloop) are a different thing, of course.

96

IIUC they would be happy to in principle but unless you can translate 100% back and forth to their own AST, you lose much of the benefits it provides.

97

Now that Iā€™ve seen LSP, I agree with you. I also presume eclipse will have to fall into line. Some of their components arenā€™t suitable for the current LSP (UML,BIRT). But all of their program text files certainly are in line. It looks like Atom, VS, and likely others will support it. Eclipse will follow.

I was primarily concerned with being hitched to IJ. A small, commercial proprietary editor. Not something that corporations like. Especially when development is done in places like Vietnam. Fear of liability is a larger motivator than keeping customers. Atom, Eclipse, even VS are free. IBM and Microsoft will sell them support, but they are free to copy. IJ has a product version, thatā€™s just scary.

Realistically, scripting languages will always be huge. Just like Perl and Visual Basic, they can be used. Languages like MatLab and R will grow quite a bit, but in vertical markets. Clojure is the only real competitor in the same space as scala in the corporate world. LSP is/will be covering all of those options. IJ was making it feel cramped, like the commercial CLOS companies.

98

Itā€™s easy to think about Linux distributions having gcc, jvm and python. Not so with sbt/scala. I donā€™t that will ever change.

99

Why not?

100

We sort of changed our mind during Scala Days. Weā€™ll look into using the compiler output from BSP to highlight errors as alternative to the builtin highlighting. This should help in cases where it own highlighting doesnā€™t work as expected. This will have drawbacks of course, such as losing the improved type error display

2 Likes