Hi, I'm not really skilled in Scala. But I don't think that it's a mistake to go ahead for such a language, I will not enumerate the advantages of Scala Vs Java. One point is that James can attract another population of developers.
In order to don't lose none-Scala developers, I think it will be great to have a document summarizing the Scala patterns used in James. Antoine Le mar. 9 juin 2020 à 14:46, Matthieu Baechler <matth...@apache.org> a écrit : > Hi Eugen, > > On Tue, 2020-06-09 at 00:52 +0300, Eugen Stan wrote: > > I'm also against adding more complexity in James. > > I guess we all are. > > > My arguments against adding scala to James are: > > > > - It adds another language that is more complex that Java - operator > > overloading, much more dense language (easier to write, harder to > > read). > > My experience with Scala is the opposite: you can write code that > express the problem you are solving instead of a lot of boiler plate > that divert the reader from the intent. > > I'm not saying Scala is perfect but I would not say it's more complex > than Java (no checked exception, support for immutable datastructure, > easy separation of infrastructure and data, no primitive mess, easy > data type definition, etc). > > > - Extra build and runtime dependencies. Scala is another compiler > > step > > and if I remember quite slow (might have changed). > > It's definitely slower than Java. > > > It also requires adds > > the library to the applications. > > That's also true > > > More bytes to push, more surface area > > to atack. Ideally we should have NO outside dependencies in James > > core. > > Hard but doable - Lucene does it. > > Depending on what is the 'core', I may agree. However scala stdlib is > like the jdk: do you see the jdk as a too-big dependency? We have to > balance number of dependencies with not re-implementing everything > (with more bugs) from scratch. > > > > > > > I do believe we should make James easy to consume from other > > languages > > but I don't believe we should add more things to James. We should > > strip > > them off, starting with dependencies. > > Depending on what you define as being James, the goal is opposite as > what is done currently. James intent is to store things in RDBMS or > distributed datastores, we can't do that without dependencies. > > From what I understand you would at least want a central part of James > to keep dependencies to the minimum. The ADR we wrote is about writing > components and extensions in Scala. So I don't think it opposes this > vision as component are swap-able, having one in Scala should not be a > problem. What do you think? > > > > > Right now I'm trying to "mvn compile" master and I can't. mvn clean > > package also fails after running for 30-45 minutes on a Ryzen 7. I > > feel > > that does not work. > > Ok, there are two problems here: > 1. we have a lot of tests and they are run by default > 2. the build process is not as reliable as it should > > > The project has 408244 lines of Java and takes longer to compile > > than > > the linux kernel [1]. I believe we are doing something wrong here. > > I can build James in less than 3 minutes and my computer is slower than > yours. Most of the time is spent in Maven and not in actual code > compilation. > > Here you compare the time our testsuite takes to run to compile C code > to a binary: it's not a fair comparison. > > > As a developer I should be able to work on James and build it > > locally, > > otherwise things are not going to move forward. > > Agree. > > > Every new tool and external dependency adds complexity. > > Not exactly: when using a tool that prevent us from writing a lot of > code, it actually removes complexity. All technologies are not > equivalent: some are better in some cases and help keeping code simple, > etc. > > I would give a single example here: do you think splitting strings for > doing protocol parsing is less complex than using a typesafe PEG parser > library? In the later case: we can stick to ABNF grammar and everything > is obvious at the cost of learning the tool. In the former case: it > looks like raw Java so people feel at home but the grammar is lost and > it's probably very buggy. > > > I believe we should avoid adding more languages to James. > > > > I personally prefer Clojure but I will not add Clojure to James core > > for > > the same reason. I will build apps on top of James with Clojure for > > sure. > > > > As somebody who write code for this project, I'm probably more willing > to use modern tool. It's very usual: users want things to be stable > because they don't want to work for keeping their service online. > Developers want things that make their work easier or funnier. > > It's one reason I asked to the community and I'm glad you answered. > > I didn't changed my mind (yet) but at least I evaluated my opinion > against others and it's always valuable. Thank you for the time you > took to write that answer. > > Cheers, > > -- Matthieu Baechler > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
