
Towards Scala 3 - kushti
http://www.scala-lang.org/blog/2018/04/19/scala-3.html
======
DandyDev
It's amazing how many people in this thread justify their own language choices
by making negative, sweeping statements about another language (Scala in this
case) that is successfully used by people other than themselves.

Yes, some people who previously used Scala, now use Kotlin. And some people
who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes
for Rust.

But there is a big enough market for people that like the intricate and
expressive type system that Scala gives you, in combination with the JVM
ecosystem. People that think Kotlin is nice, but not expressive enough, for
example. People who don't want to deal with Rust's memory management and/or
don't have a use for that. People who think Go's simplicity is sometimes more
of a burden.

Why are people so intent to bash sombody else's language choices?! Go, Rust,
Kotlin, Scala are all great languages in different ways. They all cater to
different needs, sometimes radically different (Go vs Scala), sometimes subtly
different (Kotlin vs Scala). I think there is a market for all of them, and
more. And the introduction of a new language (Kotlin for example) does not
necessarily spell doom for another (Scala).

Let's all enjoy our own tastes and needs, and respect those of others.

~~~
lmm
The reality is that a language lives or dies by its ecosystem - particularly
when it comes to a language like Scala that's in a tightly symbiotic
relationship with its IDEs (the next time someone tries to sell you a "visual
programming language", look at Scala for a language that makes really
effective use of the GUI for programming without compromising the things that
make textual programming languages good - see e.g.
[https://blog.jetbrains.com/scala/2018/03/27/intellij-
scala-p...](https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-
plugin-2018-1-inline-hints-better-structure-view-improved-refactoring-and-
greater-usability/) ). Only a few big players can afford the kind of
investment it takes to make something like that. So much as I wish it were
otherwise, I can't just sit on my island and use Scala because I think it's
the best - if the language is to live, I have to convince other people it's
the best. I don't begrudge other people feeling the same way about the
languages they do like (provided that doesn't fall into dishonesty, as some of
the claims from Kotlin advocates about e.g. null and Scala have).

~~~
MichaelMoser123
> if the language is to live, I have to convince other people it's the best

Aren't JVM languages interoperable - because they use the same classfile/byte
code format?

What does it matter if the jar is written in java or scala, as long as it is
possible to use the external interface from any of these languages?

~~~
dtech
Yes and no.

JVM languages can usually use other JVM libraries, but they often aren't
idiomatic to that language. Scala can use JVM libraries, but it often feels
wrong or cumbersome, e.g. Java is full of mutable builder classes, which I've
never once encountered in "native" Scala.

The other way around, in Scala you have to be careful if you want your library
to be usable from other JVM languages. There's certain Scala features you just
cannot use.

This is a problem that Kotlin actively markets itself with, they promise 100%
Java compatibility all the time, going as far as encouriging to mix Kotlin and
Java code in a single project.

~~~
swirepe
What Scala features can't you use?

~~~
ivan_gammel
Real example from my experience: you use a Scala Map and pass it to something
like FreeMarker, expecting that it will work like Java Map there. It will not
and depending on your test coverage and SQA capabilities, you may notice it
very quickly or very late (you'll get no compile error, since template engines
usually accept generic objects and then analyze their type via reflection).

~~~
AzzieElbab
Why would you expect this to work? In fact given that API a map from another
java library(say guava) would have crashed you just as well

~~~
ivan_gammel
Well, I wouldn't even try to have a source code written in two different
languages in the same component. But I've seen this problem in someone else's
real code, which was probably caused by a not really well-thought migration of
Java code to Scala. Basically, a developer replaced one Map with another,
fixed all the places where API was different on source code level and a number
of tests. However, interoperability issues like this one may be hard to catch
in general (even with good test coverage and regular code reviews) and they
show the complexity of the problem, that requires certain level of development
skills and discipline to do it right.

~~~
AzzieElbab
You are right, this particular example is more of case against reflection
rather than anything else. Having said that, Scala maps actually are tricky to
use from java. In general scala does a better job in compatibility when it
comes to reuse of java code from scala, but not the other way around

------
coryfklein
So many cool things already done and even more to come. Some parts that excite
me as a Scala nerd:

* One can now use implicit function types to basically build your own table language syntax that is type-safe. [1]

* Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with anything. [2]

* Null safety checks! Quoting from [3], "Adding a null value to every type has been called a "Billion Dollar Mistake" by its inventor, Tony Hoare. With the introduction of union types, we can now do better. A type like String will not carry the null value. To express that a value can be null, one will use the union type String | Null instead."

* First-class enums, finally. [4]

* Erased parameters: you can declare variables specifically for type-safety that _don't exist_ during run-time, improving efficiency. [5]

[1] [http://dotty.epfl.ch/docs/reference/implicit-function-
types....](http://dotty.epfl.ch/docs/reference/implicit-function-types.html)

[2] [http://dotty.epfl.ch/docs/reference/multiversal-
equality.htm...](http://dotty.epfl.ch/docs/reference/multiversal-
equality.html)

[3]
[http://dotty.epfl.ch/docs/reference/overview.html](http://dotty.epfl.ch/docs/reference/overview.html)

[4]
[http://dotty.epfl.ch/docs/reference/enums/enums.html](http://dotty.epfl.ch/docs/reference/enums/enums.html)

[5] [http://dotty.epfl.ch/docs/reference/erased-
terms.html](http://dotty.epfl.ch/docs/reference/erased-terms.html)

~~~
lmm
> * Multiversal Equality: you get to decide whether it makes any sense to
> compare an Apple and an Orange using "==" or "!=", as opposed to Java's
> forced requirement of allowing you to compare anything with anything. [2]

Unfortunately it's being introduced in a fail-unsafe way that as far as I can
see makes it virtually useless. If I see "x == y" in code, I have no way to be
confident that this isn't an old-fashioned universal comparison without going
into the details of x and y, so I'm no better off than I was without this
feature.

~~~
eeperson
It looks like you can force strict equality everywhere with the flag
'-language:strictEquality'. See the dotty documentation for more details:
[http://dotty.epfl.ch/docs/reference/multiversal-
equality.htm...](http://dotty.epfl.ch/docs/reference/multiversal-
equality.html)

EDIT just realized you are m50d on reddit and probably saw the exact same
comment I got that from.

------
stephen
...ships in 2020?

I'm impressed with what they're doing (and love the language), and it's hard
work, and their speed is faster than, say, Java's dead-pace evolution in the
2000s.

But, poking around at TypeScript, I've been blown away with the MS/TS speed of
development. ~2-3 month release cycles, with non-trivial changes to the
language (mapped types, conditional types, etc.), that are themselves
unique/novel type system features, not like Java finally getting around to
copying the obvious/best-practice approach to case/data classes.

Granted, I'm sure the MS/TypeScript budget is huge comparatively...

Seems like that's the "best" (realistic) way for dev tooling to evolve lately:
come from, or attach yourself to, a ~top-5 tech company that makes their money
somewhere else and can bankroll developer tools/languages (e.g. MS with TS, FB
with React/Flow, Google with a myriad of things e.g. Dart & AdWords, Go).

Bringing it back to Scala, seems like they were close to this (flirted with
adoption/sponsorship from a few startups like FourSquare, etc.) but, thinking
about it now, "software development in the large" is a huge concern for those
companies (e.g. anyone with enough extra money to actually pay for
language/tooling improvements), and that's never really been Scala's strong
suit (compile times, painless compiler upgrades).

~~~
cinnamonheart
For what it's worth, this isn't just an evolution of the language, but a
complete rewrite of the compiler. I appreciate that they're taking the time to
do it right. They probably could've pushed new, non-trivial features out
faster if they weren't doing a total rewrite.

~~~
BurningFrog
This does nothing to change my opinion that total rewrites are almost always a
horrible idea.

~~~
pas
The Scala compiler has to be cleaned up. Maybe rewritten, maybe not. Dotty
started as a fork of Scala, and now Odersky decided/announced that it'll be
merged back eventually. (And it should conform to whatever the Scala language
is/will be after the SIP processes for 3.0.)

------
dserban
There are a lot of comments pointing out pros and cons of Scala, comparing it
to other languages using superficial proxies.

I'd like to share a different perspective based on my own work with OOP-
centric and FP-centric languages.

If you take OOP to its logical conclusion, OOP is a slippery slope that
eventually leads to Gang-Of-Four centric designs.

If you take FP to its logical conclusion, FP is a slippery slope that
eventually leads to Monad-Transformer centric designs.

Both are equally valid ways to design complex applications, so it all comes
down to individual taste.

Personally I have a taste for mathematical abstractions, so Scala is better
suited for my way of thinking.

It's obvious that Scala was specifically designed to be a solid foundation on
which one can implement the concepts of a little known branch of mathematics
called the category theory, and almost every design choice in the language
flows from there.

If we use this as the basis for comparison to other languages, it's very easy
to understand that Scala has carved out a very powerful niche for itself and
is here to stay.

~~~
endgame
> If you take FP to its logical conclusion, FP is a slippery slope that
> eventually leads to Monad-Transformer centric designs.

I don't understand what you mean by this, and I write production haskell for a
living. We don't have teetering towers of transformers, and the best advice
I've seen is often "put away the shiny tools and just use functions",
[https://lukepalmer.wordpress.com/2010/01/24/haskell-
antipatt...](https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-
existential-typeclass/) . Similarly in
[http://www.parsonsmatt.org/2018/03/22/three_layer_haskell_ca...](http://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html)
, which is like one real transformer layer and a way of claiming only the
capabilities you need in your impure code. His "invert your mocks" article
talks about this, too.

Ed Kmett's comments on Scala make me worry that the "solid foundation" isn't
as solid as it could be:
[https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the...](https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu/)
. How much of this is true in more recent Scala versions?

~~~
preordained
It's been a while since I lurked Haskell forums/haunts (was into it way back
when), but at that time Lens was a big deal...if that's not a highfalutin
library made for the most entrenched monad geeks (and for the purpose of
making setters and getters, no less), I don't know what is. I guess I'm really
shocked to hear that Haskell is all pragmatic and simple now with slim
abstractions...but I'd love to be corrected.

~~~
tel
I'd suggest that you're giving Lens a pretty short shrift. It's not "just"
getters and setters as it works on immutable data. It also has a composition
story that's better than normal getters and setters and _much_ better than
other immutable data update stories.

------
jrq
Disclaimer : I'm nobody important, but I do have an opinion

If scala team were to disavow sbt, that'd be the single best thing they could
possibly do for the ecosystem.

I used to write a lot of scala, and working with sbt was enough to eventually
get under my skin.

I really like some of the OOP aspects of scala, the left-to-right style of
thinking matches how my brain works. Scala having a lot to offer can distract
new learners, especially with just how overwhelming all the different features
can seem for someone not coming from both sides. I had ocaml and ruby under my
belt when I found scala, so it was an easier curve, but lots of guys struggle
with it. I don't mind showing them, and of course I learn a lot from guys with
different experiences and different backgrounds, but that's sometimes a
complain I hear, also.

It's a language that doesn't compare very well. What is scala like? We don't
know, there's only one language like it, it's a departure from many different
paradigms.

I'm back to writing ocaml, all said and done. I enjoyed my time with scala,
and interacting with my guys on the other side of the office still doing scala
is always enjoyable. Smart guys! I'm not academic enough to grasp some of the
new DOT stuff, but they are excited about it.

Anyways, I gave up hope a while back on scala getting rid of sbt. There are
other build tools that exist, cbt, mill, maybe more, but without the blessing
from lightbend or whatever they call themselves this week, it's not feasible,
or responsible to deliver a solution to a client with an unofficial build
setup. Of course, after five years of doing sbt I decided it's not ok to
deliver sbt either.

Someday! Maybe?!

~~~
pacala
> If scala team were to disavow sbt, that'd be the single best thing they
> could possibly do for the ecosystem.

Seconded. Between [http://www.lihaoyi.com/mill/](http://www.lihaoyi.com/mill/)
and [https://bazel.build/](https://bazel.build/), there are plenty of
alternatives.

~~~
ionforce
Scala enthusiast Jon Pretty just announced `fury` as well!

~~~
joshlemer
Do you have a link to that? I can't seem to find it.

~~~
ionforce
[https://twitter.com/jaguarul/status/986146251379965953](https://twitter.com/jaguarul/status/986146251379965953)

------
clhodapp
> Scala 3 code can use Scala 2 artifacts because the Scala 3 compiler
> understands the classfile format for sources compiled with Scala 2.12 and
> upwards.

I feel like this isn't getting much attention but it is a huge deal. A big
part of the reason that Python 3 went the way it did was users didn't want to
upgrade until their libraries did and libraries didn't want to upgrade until
their users did. With Scala 3, users can upgrade pretty rapidly, freeing
libraries to upgrade without fear of leaving their users behind.

------
nnq
Just curious, what companies (or kinds of companies) are betting on Scala
nowadays? It seems that the people wanting "better Java" all decided they like
Kotlin, and the functional programming people now gravitate more towards
either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And
the academic/research/learning crowd seems to like Haskell more.

Who's still in Scala boat? Are Google or Fb or other big cos known to give
back to open-source growing any Scala codebases now?

~~~
pjmlp
F# only has access to a subset of .NET deployment scenarios, where Scala can
be used pretty much everywhere there is a JVM.

So most companies actually are more keen to bet on Scala than F#.

OCaml/Reason world lacks the wealth of Java libraries, which are an import
away on Scala.

Regarding Kotlin, so far its killer use case is targeting Android, where one
is stuck with an ageing Java subset. Outside of Android, it remains to be seen
how it will keep up with the Java improvements coming up every 6 months now.

~~~
Bizarro
I don't think many companies are betting on Scala anymore. F# is just as
irrelevant in the grand scheme of things.

Let's face it, Kotlin hurts Scala adoption.

~~~
stusmall
Kotlin and Java 8. I started using Scala in Java 7 era and loved it. When Java
was stagnating it seemed like an alternate language that targeted the JVM was
the best option. Progress with the language has really picked up a lot. There
is a lot that Scala has that Java doesn't, but now its not enough to make it
worth it. Java is so much easier to work with on a large team.

~~~
eweise
The two languages though also have preferred libraries / frameworks. I code in
Java again and the main thing that bugs me is being always in the Spring
ecosystem. There is a mindset in javaland that every technology needs to be
wrapped by Spring. Scala gave me the freedom to choose alternative libraries.

~~~
stusmall
Oft. I agree with you there. I never enjoyed spring. I don't get the appeal.
With scala I loved play framework. I know it has java support but I never
tried it. It used so many scala idioms and features I'm not sure how well it
would translate.

------
virmundi
How have people faired with Scala integration with Java libraries? When Scala
first came out, I liked the idea. If I wanted to use X library, great, I can.
As I pondered it more, this seemed terrible. Say I hug the functional side of
Scala. I know what I'm doing. Then I hire a Jr Dev. She comes from the world
of Java/Python where functional is no as big of thing (keeping in mind that
while Python does support, to a degree, functional, many use it as a
procedural/OO language in school). Suddenly I have to worry about the Jr Dev
doing silly things like introducing mutable Java objects into functional code.
Side effects could start to show at odd times, which makes debugging terrible
in a production environment.

All that said, how have others dealt with this issue? Did you just not work
directly with Java libraries? Did you use the OO side as a Better Java?

~~~
denisw
Code reviews. Let developers peer-review each other's code changes and share
knowledge about the functional programming practices used in the codebase.
This is not a technical problem and has nothing to do with Scala.

~~~
cloakandswagger
Language design can discourage those bad practices and lessen the workload of
code reviews.

Catching bad practices and anti-patterns in code review sounds fine on paper,
but I'm sure we've all been in the situation where there simply isn't enough
time in the day to do intensive code reviews while still maintaining the pace
needed for delivery.

------
dzdt
My big question (not answered in the FAQ) is will it be faster or slower than
Scala 2.12? Having worked on a big Scala codebase, the slow compiler speed is
one of the biggest downsides to the language.

~~~
modersky
It's currently about as fast as Scala 2.12, which means it compiles at roughly
3000 lines/sec. However, it supports more aggressive incremental compilation
than Scala 2 so at least in my projects, which are typically 50K to 100K
lines, most compiles are under a second, and I rarely see compile times over 5
seconds.

There's ongoing performance work to make both Scala 2 and Scala 3 faster than
they are now. A lot of what people perceive as slow compile times are actually
other factors (such as inefficient macros or slow build tools).

~~~
jvican
> However, it supports more aggressive incremental compilation than Scala 2

I'm not sure what you mean here... but Scala 2 and Dotty have the same
incremental compiler, and their independent bridges feature overall the same
quality (which is high and heavily battle tested, for those interested).

~~~
modersky
It has to do with what kind of dependencies the incremental compiler wrapper
(e.g. zinc) can extract from the baseline compiler (e.g nsc or dotc). The
Scala 3 compiler dotc handles that itself, which has the potential to achieve
better accuracy. But I am not sure how much it matters in practice. We'll find
out.

~~~
jvican
> which has the potential to achieve better accuracy

The quality of the used names extraction affects accuracy, but not compile
speed. I must say, Dotty and Scala are extracting about the same amount of
dependencies, with some corner cases being covered better in Dotty (for
example, changes in constant values).

I don't see a way Dotty can become a faster incremental compiler that doesn't
involve adding the incrementality in the compiler.

------
framebit
I saw a presentation recently on Mill[1] which looks extremely promising and
looks poised to remove the giant Scala development headache of working with
SBT.

[1] [https://github.com/lihaoyi/mill](https://github.com/lihaoyi/mill)

~~~
stephen
sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but
I'm slightly baffled that YABT (yet another build tool) was really necessary
vs. just making the existing (say) gradle experience super-polished.

Granted, it's probably more fun to start from scratch :-), just seems more
realistic for long-term adoption/maintainability to leverage existing tools.

~~~
lomnakkus
The models of SBT/Gradle/Maven are broken, or at least, that's the premise for
writing these build tools.

The model of Mill, Bazel, Buck, Pants are fundamentally different in very
important ways which allow e.g. using a shared build cache across _all the
developers in a team_ (or even all the developers in a whole company if one
takes the monorepo approach for absolutely everything). This is not something
that can be retrofitted into, say, SBT or Gradle.

~~~
stephen
Gradle does have a build cache, which can be local or remote:

[https://docs.gradle.org/current/userguide/build_cache.html](https://docs.gradle.org/current/userguide/build_cache.html)

It is a newer feature, so that might be why you're unaware of it.

Also, I get that the models of Bazel/Buck/Pants are fundamentally different,
because they are inherently cross-language / "sit on top of other compilers"
systems. And are best for mono repos.

But Mill doesn't fit in that camp AFAICT.

~~~
lomnakkus
Ah, right I wasn't aware of that. Still, AFAICT Gradle isn't nearly as
'ambitious' in tackling the hard problem of hermetic/reproducible builds as
e.g. Bazel, so who knows how reliable that build cache actually is.

You may well be right about Mill, but it's probably too early to tell exactly
where it'll land in the design space.

(Btw, I think it's entirely right to be wary of yet-another-build-system,
especially when it doesn't seem to do anything that other systems don't
already do.)

------
quantumwoke
This major breaking change to the language reminds me a lot of the Py2-Py3
fiasco. I wonder how Scala's community will handle the transition given the
previous issues with cross compilation in the 2.x series. Given the multitude
of language alternatives in a similar space to Scala, I'm worried. Fingers
crossed they can work through this.

~~~
azernik
Static typing makes this kind of large-scale refactoring a LOT less scary.

------
AzzieElbab
Great news! Kind of confused about scala2 and 3 sharing the same standard
library. I thought that was being redesigned.

~~~
modersky
The shared library we are talking about is the upcoming 2.13 library, which
has the new collections design. We currently link against the 2.12 library but
will switch to 2.13 once that comes out.

~~~
dhuramas
Just wanted to say- thanks for your great work in making Scala possible. And
wanted to add that going through your Scala Functional Programming MOOC was
one of the most rewarding experiences.

------
amckinlay
Last time I tried Scala I had to give up because I couldn't understand what a
"trampoline" was, or how to use it to get multi-function tail recursion to
work. Probably not Scala's fault.

~~~
ionforce
What level of Scala were you trying? The things you're referring to don't
sound pedestrian at all. You shouldn't let them turn you off from ALL of
Scala.

------
rilut
Is there any plans to include async/await on the language level?

~~~
azernik
async/await is a special case of monads (expressible with a for-
comprehension); it comes out to:

    
    
      def asyncFunction(): Future[Blah] = for {
        foo <- someAsynchronousOperation
        bar <- anotherAsynchronousOperation
      } yield bar.baz

~~~
saosebastiao
I find async/await to be much better for conditional execution, especially
with lots of branches. For example, I had a scenario where I tried one async
call and if it didn't have the information I needed, I had to make two
subsequent async calls to get the information I needed before proceeding with
the final call. Monadic composition was a nightmare where async/await was
perfectly suited to the task.

------
rb808
Its fascinating process where if you're a hot new language you attract a lot
of people that like shiny new things. When the next hot new language comes
along and those people move on - have you attracted enough of the secondary
wave to keep alive? Its going to be interesting to watch Scala adoption in the
next few years.

~~~
devit
Don't think it has a bright future since Rust and Kotlin share much of what
brings people to Scala and are better in many ways, including and perhaps most
importantly the fact they are improving faster than Scala.

~~~
lmm
Neither of those has or intends to have HKT, and they'll never be an
acceptable replacement for Scala without it. They're "improving faster" but
only in that they're starting from further behind.

~~~
seanmcdirmid
The reason why Kotlin is gaining marketshare is specifically because they
aren’t chasing after things like HKTs. Kotlin is squarely going after the
better Java market and not the advanced FP one.

~~~
lmm
I think Kotlin's design - adding lots of ad-hoc support for specific use cases
but without the underlying general constructs that make them coherent - will
come to bite them as and when the language needs to evolve over time. (Indeed
to a certain extent it already has, as Java 8+ adopts Options which don't play
nice with Kotlin's ?. etc.) I guess we'll see how things look in a few years.

~~~
seanmcdirmid
? actually should play nicely with explicit Option types, they do in C#
anyways.

------
sriku
"Scala has pioneered the fusion of object-oriented and functional programming
in a typed setting."

What about Ocaml (1996, well before scala) and F# (2005, not too long after
scala)?

~~~
lmm
OCaml users tend to avoid its object system, so while it attempted to fuse
object-oriented and functional I don't think we can say it succeeded. F# is,
as you say, later.

~~~
yawaramin
OCamlers tend to avoid OOP mostly because we can get away with modules,
functors, polymorphic variants to model subtyping, and now also GADTs and open
variant types to precisely model and add cases.

When we do need to use it, it is actually pretty elegant and well-designed.
It's just that since we've tasted the power of the more functional abstraction
techniques, OOP loses its allure.

~~~
lomnakkus
Indeed. I think that what OCaml proved is that the "O" isn't actually
necessary. :)

------
merb
Well it won't solve the biggest problems with interop
[https://github.com/scala/collection-
strawman/issues/283](https://github.com/scala/collection-strawman/issues/283)
(sadly).

I mean I can understand all the reasons not to, however It's just a pita that
there is no sane way to do it, besides reimplementing either two api's or come
up with your own collections.

~~~
dtech
Is this really such a big problem? You can either work directly with the Java
collections if the code is performance sensitive, or have a `.toScala` call at
your Java -> Scala boundary and a `.toJava` call at your Scala -> Java
boundary.

------
room271
As a heavy Scala user I'm excited by this. But really I don't think it will
improve Scala adoption because the blockers there are all around developer
experience (tooling is terrible - sbt, and feedback cycles are very slow).

Personally, for a lot of my current use cases (APIs) I'm veering towards Go
more and more as I find it a lot more productive.

~~~
jvican
At the Scala Center we’re working on addressing these problems. We now have
working groups devoted to ease coding in Scala and make it easier for any dev
to use any build tool.

~~~
room271
That's great news! Thanks for the reply.

------
mavdi
> Simplify where possible

> eliminate inconsistencies and surprising behavior

Oh dear god please.

~~~
realusername
I know on HN people like Scala but it's by far one of the language I hated the
most when I worked with it. It's the complete opposite of Go, every time the
Go team said no to a random feature, the Scala team said yes to that random
feature. Scala feels to me like a kind of functional Perl.

~~~
_Codemonkeyism
Scala is not for development, it's a research project.

~~~
sulam
I don’t know is this is a good troll because I’m replying or a bad troll
because it’s so obvious.

There are Many people who work at many companies doing real development with
Scala that goes all the way to production, handling real user traffic.

~~~
_Codemonkeyism
Yes we use Scala in production for >6 years.

But I wonder how many companies would make the same decision again after their
experience with Scala.

------
viach
I was really hoping they implement python-ish syntax
[https://github.com/lampepfl/dotty/issues/2491](https://github.com/lampepfl/dotty/issues/2491)

But no, "Implicit Function Types" instead. Ok.

~~~
Cyph0n
So your biggest complaint is "Scala doesn't look like Python"? I mean, I love
Python, but indentation-based syntax isn't _that_ great. I think Scala is fine
as it is.

~~~
willtim
Being brutally honest, compared to Haskell, ML and to a lesser extent Python,
Scala's syntax is rather ugly and unnecessarily verbose. I'm almost certain
its creators chose the syntax in order to tempt curly-bracket programmers, not
because they liked it personally. I really hope that future high-level
languages will use better syntax and move on from the C/C++ influence.

~~~
Cyph0n
> compared to Haskell, ML and to a lesser extent Python, Scala's syntax is
> rather ugly and unnecessarily verbose

I have never worked extensively with Haskell or ML, but what I can say is that
Scala's syntax is better than that of most other mainstream languages.

Three of Scala's syntax niceties are:

1) No semicolons

2) No braces required for one-line functions

3) No constructor required: instance arguments passed in class declaration

~~~
s4vi0r
To add onto this, its not one line functions but rather functions whose body
is a single expression.

You can do a big for comprehension, or a if/else, or a big chain of function
calls, etc. without having to add brackets.

In practice you often end up not really using braces that often when writing
FP style Scala.

------
tytytytytytytyt
> become more opinionated by promoting programming idioms we found to work
> well

Which idioms exactly?

