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
