Hello Matthieu, La 09.06.2020 15:46, Matthieu Baechler a scris: > 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). There are immutable collections since Java 9 https://docs.oracle.com/javase/9/core/creating-immutable-lists-sets-and-maps.htm#JSCOR-GUID-202D195E-6E18-41F6-90C0-7423B2C9B381 .
Some of the other you mentioned are coming to Java as well. Slower for sure. JDK 15 (release in september) comes with text blocks, records (second preview), sealed classes preview, pattern matching preview etc. IMO in 1 year they will be mainline and just hopefully that will be the next Java LTS ( september 2021). I do believe (and hope) value types are going to come in the next 2 years. Let's see if my predictions are accurate :). https://openjdk.java.net/projects/jdk/15/ The benefits of having that in Java is the bigger ecosystem. It does look like a lot of languages will lose some of their appeal. > 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'm mostly referring to libraries. Having a library bring a dependency like scala is a no-no on my part. Ideally the lower parts of James should not bring any dependencies. Guava is also big and I would like to see that gone as well. It's not reasonable to bring 1+MB of data for 2-3 classes like Preconditions and immutables. Especially since most of that is available in the newer JDK. There are a lot of projects that use James libraries. Asking them to bring an extra 5.6 MB for scala is also not reasonable. (I checked the size of this: https://search.maven.org/artifact/org.scala-lang/scala-library/2.13.2/jar . I might be wrong.) I mean the James libraries have less then a few K of data and bring in 10 MB of extra dependencies that we can avoid by being mindful about our choices. Those classes take disk space, take time to load and process, take memory and also maintenance on the security side - something else to worry about. I would also like to see some native images for James with GraalVM. Again things add up. I'm going to stop ranting about that for now because I do want to see other languages use James. I do think it's very valuable to consume James libraries from other languages and to build applications on top of James. Using multiple programing paradigmes will improve our API and developer reach. I would like to write mailets in Clojure for example and make James more appealing in the Clojure community. And of course I won't stop anyone for adding a new library in their own preferred language to James. > 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? Yes the central part of James that we should keep dependency free are the libraries. The pieces of James that tend to be reused by other people in their projects. If we want a broad reach, we need to make as few assumptions and use the least amount of dependencies as we can. For extending James - bring as much examples as possible in as many languages as possible. I am all for extending and having implementations in other languages. We should be mindful that software is easy to write and hard to maintain. Maintenance is going to fall on the whole team. > 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. I'm sold :). Please share with me how. I ran "mvn clean package -DskipTests" and it took 10 min. [INFO] BUILD SUCCESS [INFO] Total time: 10:40 min > 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. Have you tried finding an alternative implementation in Java for grammars? I agree, all tools are not born equal. Like I said above I am open to adding alternative implementations in new languages. The users can choose based on the features which one they use. Please keep in mind that each piece will add overhead: - more time to build for everyone in the project - extra things to take care of during release, bug triaging, maintenance when API's are changed. I'm asking for the sake of discussion: How do you think we should handle a case when we need to change an API. An implementation, written in another language needs to be updated but the original maintainer is not here/not responsive and we don't know the specific language / tool well enough ? > 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. I'm also glad you opened the discussion. I'm also glad you did not change your mind. It's not my intention. We need to find solutions on how to do this in a way that has a small impact on the others. The only way we can do that is by having a discussion. On my part I can say this (as a conclusion): - I will be very resistant to adding dependencies to James libraries. It's my default. Also to James Apps, but less so. - I will do my best to remove dependencies from those libraries (and I hope you will support me) - I support consuming James libraries from other languages - with examples - I support extending James API's in other languages and/or tools - with the caveat that we will have to maintain or drop that if no one steps in to maintain it - I support adding NEW implementations for protocols, API's / libraries in other languages - with the caveat of maintenance. This should be justified since it will dilute our development efforts. Regards, -- Eugen Stan +40720 898 747 / netdava.com
<<attachment: eugen_stan.vcf>>
signature.asc
Description: OpenPGP digital signature
