Greg Hall

I'm just going to add that I don't really care about the size of each service, I'm more interested in memory consumption and benefits of having multiple services for maintaining code over time.

I would call it many services, not micro services. The point being that if, for example, you choose to use Spring and JPA you only have one copy of those frameworks for the whole app, not copies for each service. Since they take up over 200MB together, a single copy is fine, but 50 copies for 50 services is not.

If that's true, then the usage of micro is incorrect, and some other word should have been used.

But I don't think most people would agree with what you said - I think most people see microservices as basically a way to have more separate pieces of code instead of one large monolith, which intrinsically means the pieces are smaller. The whole point is to try to avoid the spaghetti code mess of one large codebase. Some would argue if a single service becomes a mess, it can be replaced more easily since it is smaller.

It's also a bit silly to stop reading just because you disagree with one point.

Well, there isn't really one answer. What I started using consisted of:

- JSP for generating HTML server side

- Java code for backend

- A framework called Struts I don't think anyone uses anymore to deal with requests from browser in Java code

- Ant as a build tool, long since replaced by Maven

Maven is genuinely a better build tool than Ant. Ant was XML as code, with strange steps. Maven works best with Java code, but can be used for C/C++ code if you want, and probably other languages.

Server side rendering is far less complex than a single page app. That means less work to maintain it, like anything else less complex.

I would be happy to do the following

- Use server side rendering. Could be Java JSP, Go html/template, every popular language has something like these examples.

- Pick a simple front end library that produces a nice looking UI, such as Shoelace or Tabler. I'm sure they could both be used with Angular or React if you really needed to at some point.

- Use PostgreSQL for the database. Out of the box, it can do graph and hierarchical queries, full text searches. It has many extensions, allowing it be a good one ring to rule them all for most custom apps built by software companies for customers.

- Have one repo with top level dirs for each service

- Deploy one container with all services in it. You're not Netflix, you can redeploy your one container off hours.

- Use a simple method of handling REST, like Go net/http or Java HttpHandler. It's not hard to write your own code that deals with verbs, cookies, URL paths, and query parameters. You can just make some utility functions for most cases.

- Crucially - only add more infrastructure (EG, Redis or ElasticSearch, etc) if you genuinely need it - eg, you tried materialized views, indexes, tablespaces, query optimizations, partitions, read replicas, and it still isn't good enough. Your database is still too slow, then ok, go ahead and use Redis as you have what it is designed to solve - a slow database. Start with just your SQL database, and use other tools only when they are really needed. Once added, these other tools will never go away, and you pay a permanent operational tax on their existence - fixing bugs with your usage, updates for security vulnerabilities, migrating to new versions, training for incoming team members, money costs like cloud expenses, etc.

Now someone else might have a different stack that is similarly simple, and that would be fine. This is a moving target, as frameworks and libraries keep falling out of favour, then they don't really get updated anymore in some cases, and new libraries pop up that might be genuinely better in some way that actually affects team performance.

There probably isn't. People have been happily not doing this for over 25 years of Java. I guess the stock answer would be, the same use case as C++.

Interestingly, the C++ community said long ago to only derive from one class that actually has behaviour, and the others should just be the equivalent of a Java interface - they only define methods that have to be implemented.

I just like sometimes to do something like this for fun.

I like the approach being taken of compiling generic code to ordinary code so people can try it with real problems. I'm going to give this a try with my streams library and see if it helps, what works/doesn't. Should be interesting.
Thanks for the update, I wasn't following this proposal.

There are ways to deal with that kind of stuff in Go.

An iterator doesn't have to be a class in Go, it just can just be a function like "func iter() (X, bool)", where X is the type to iterate. Either it returns (X, true) because there is another X to iterate, or (zero value, false) because there are no more Xs to iterate. Yes, you'd have to keep writing them, but it's only a single function of usually < 10 lines of code.

Usually a generic abstraction doesn't refer to the generic type in every single method return value. If an abstraction has 20 methods, maybe only 4 of them return the generic type. Then only those 4 need to be tied to a specific type using embedded structs.

Not sure what you mean by "using template methods of a concretion that may have more methods than the abstraction. on a language that doesn't even have typing system".

As for dynamic typing errors at runtime, that's where the localisation comes in that I mentioned:

1. Write struct GenericFoo that uses type "interface{}" for its methods so it can handle any type in Go.
2. For each specific type X, write GenericFooX that embeds a GenericFoo.
3. For each method of GenericFoo that returns "interface{}", replace it in GenericFooX to return type X instead. Internally, the method type asserts "interface{}" to X.
4. If you want, also replace methods that accept "interface{}" in GenericFoo so they accept X in GenericFooX. This isn't really required, since Go allows any value to be passed to a function that accepts "interface{}".

Another option is code generation - use some kind of generator to produce GenericFooX structs with correct signatures for the specific types you want.

It basically depends on how much work you're talking about - if it's not a lot of work, use copy/paste to create GenericFooX structs. If there are lots of methods and it's a lot of work, use a code generator.

I think sometimes we're spoiled by runtime code generation in managed languages that allow it. Go only has, to my knowledge, reflect.MakeFunc, which won't help much with generics. What Go does have is "go generate", which you might find useful for generating code for GenericFooX structs.

Try https://blog.golang.org/generate as a starting point.

Why do you think just because I don't think generics are an important feature that I have limited experience in Java? Limited compared to what? I've worked on Java projects at companies for about 12 years, and personally for many more.

I wouldn't presume to know someone's experience in anything based on a single posting they authored online, just because I disagree with what they say.

I never said there was no use for generics. Instead of putting whatever words you feel like in my mouth just to sound superior, why don't you try making a real argument? Once that isn't cynical, snide, dismissive, or arrogant. Assuming that is, that you actually know how. Is this how you talk to your coworkers? You must be real popular.

That's all well and good for my own personal projects, but oddly enough the projects I have worked on at the companies I worked for were not MY projects. The fact not a single one of them had any significant use of generics aside from collections also wasn't MY choice.

For my current company I needed to write a parser in Go for a somewhat strange document format that was never intended to read by computers. I didn't find parsing it in Go any worse than any other general purpose language. I personally prefer recursive descent parsing.

The reason Go has no MaxInt is that int is 32 bits or 64 bits depending on the platform. You should be able to determine at runtime which size it is by using an expression like "i := math.MaxInt32 + 1". On a 32-bit platform the result should be 0, on 64-bits it should be 2147483648.

This is getting somewhat off topic, but I don't think interfaces are a very good paradigm for functional programming. I definitely prefer having functions as first class data types as in Go.
Java only has "functional interfaces" due to tacking functional on top of OOP. And it only has the silliness of all these primitive/object parameters due to generics only using objects.
That is the one thing I wish Java had done differently, having generics also working with primitives.

Some of those problems could probably have been solved in some other way.

As an example, I find one trap people fall into is the progression of a data structure:
- I need to keep track of some strings, I'll use a List.
- Oh, now I need to associate each string with an int, I'll use a Map.
- Actually, I need a pair of ints per string, ...

Each change requires modifying various for loops in various methods, some method signatures, etc. A better idea would be to abstract all access to the data structure into a separate class, with semantically meaningful method names like "addPreferredCustomerToInvoice".
If the abstraction needs to modify the underlying list/maps, etc, no code outside the abstraction is affected. This is one form of the localisation I was talking about.

I hadn't thought of that. I wish some of these surveys were more in depth. In fact, almost any survey I read about online seems lacking in depth.
I'm sure all of those opinions you mentioned exist in the 21 percent, and other opinions we haven't thought of.

I never said generics are bad, only that we don't really need them.
They require significant additional complexity in the compiler, anything that complex tends towards a few really strange compiler error messages until you know what they mean, sometimes you might still have to do some strange casting, etc.
Personally, I don't think Java's generics is a bad implementation,I just never felt like wow, this is amazing and solves a real problem I have.

Yes, there are some good usage of generics, I never suggested there isn't.
That doesn't mean every language needs it as a feature, or that it is critically important.

Using Java generics as an example is no worse than using C++ templates or any other example of generic programming. It's no different than comparing engines of different car manufacturers, it's hardly a wild apples to gun barrels comparison.
Regardless of which implementation you compare against, the points are valid - the compiler gets significantly more complex, there are some hard to understand rules, and you don't really have to have it.

If you passed a type that contains interface{} to a bunch of methods on multiple structs, then you'd probably be right,

But you don't have to do that, you can keep it localised as I mentioned. That's why for years of Java it didn't bother me. Try it!

Did you ever try using Thymeleaf to preprocess it's own files? EG, you have input templates that use the include tag to include common stuff like css, company logo, privacy policy link, etc. The build tells Thymeleaf to process the file without using separate logic, and with no beans. The output is a template that has the common elements copied into it. The output template can then be used at runtime with separate logic and beans. This allows both a living prototype and the ability to separate out common elements so that one change can affect many templates. It should work, never tried it.

I can honestly say I have always hated JSF, and dread using it. I freely admit it's not entirely JSF's fault, I found that people loved to abuse JSF in ever increasingly inventive fashions, the result was always a spaghetti ball of garbage. I've usually seen the same thing with JSP projects.

I would prefer to use Thymeleaf, as it makes it easy to produce HTML because you simply write it as HTML with a separate file to say how to replace hard-coded data in the template with real data. You can have a "living prototype" that can be viewed at anytime without any server.

Tools are not my decision, they're the decison of every company I have worked for, made usually by someone who is no longer there by the time I arrive :)

And if it was up to me, I would choose the tools people are actually using, not my personal preference, because it is in the company's best interest to have projects using tools any random hire should be familiar with.

And that's my point - tools limit you, so much so that using FP primarily in Java means writing your own tools. I'm sure there are other languages where the opposite is true.

And yes, you're right that you can achieve a balance of FP and OOP in Java.

I find what's usually lacking in these debates is practical reality, such as:

- Libraries like JPA and Spring MVC that require mutable objects with an empty constructor and setter methods.

- The need side for effects somewhere along the line (eg I/O operations)

All such considerations can simply be summed up with one statement: you're not going to write everything yourself. Depending on others code inherently means you can't control how they chose to write their library/framework that you depend on, which limits how you program.

Not sure I get part of my post what your comment on strong typing relates to. I'm a great fan of using reflection for all its worth, hence my suggestion of mapping a URL to a method of a class. It also eliminates the refactoring that invariably leads to a URL of /customer that displays an address.

And I'm way more unusual than you can possibly imagine :)

Well said :) But is any other language really any better? If so, does it have all the stuff Java has for PDFs, spreadsheets, database, networking, etc ad nauseum? If not, can it work reasonably well in the JVM directly or through ScriptManager? I've been asking myself if this is the way forward, something else in the JVM that can access all those libraries.

It largely feels to me like a "damned if you do, damned if you don't" proposition to use a language like Java, same for OOP.

In the end, I'm happy if the project is well structured with maintainable code. Unfortunately, that seems rare.

And how about a 25-page spec!

You should know you an still address those issues without a 570 page spec :) SQL injection? Come on, that's free - just use PreparedStatements, which people tend to use anyway. Character encoding? Just use UTF-8. I've never needed to translate encodings for any application yet in over 10 years, though I'm sure some people have. Filtering can be done with J2EE filters.

I'm aware of those points you mention, they are are not complicated. They can all be taken care of without tens of megabytes of code and hundreds of pages of specs.

I doubt the need for the giant tools we use all the time in Java far more than OOP. Why do I need a 570 page spec just to translate between rows of an SQL database and Java objects? Why do I need a 486 page spec just to deliver a String of HTML to a user's browser?

I'd far rather see a less-is-more approach where simple things are done simply. It only takes some simple string manipulation to translate a URL into a Java classname and method name to execute for that URL. A small bit of code can translate between forms and Java objects. I don't really care if it uses OOP or FP.