In this case the original title is "ChatGPT for teams", so the headline was actually editorialized when it was submitted, which is discouraged by HN guidelines.
Normally it would be ok to capitallize words to match what many other US publications use, but this capitalization introduces confusion. I can only speak for myself, but I made the assumption that this was an integration with MS Teams. This would have been avoided if the original title was kept.
In my opinion this depends on the use case. If one service has a strong dependency to a different service, it may be a case of "distributed monolith" and they should consider if the functionality should be moved to the original service instead.
If two services need to communicate with each other, I don't see how a message queue makes the coupling less robust. What is the difference between sending a message or making a http call? You still have a coupling between the two services.
Message queues used right can actually increase operational robustness in my opinion. By placing a message on a queue you get a lot of functionality for free.
- You distribute the load automatically so that the risk of overloading a single instance is reduced
- You can limit the ingestion flow, so that services only process the data at a rate that they can handle
- If a service fails or shuts down, the message remains on the queue for the next instance to retry. You get a lot of retry logic for "free".
- You can easily monitor and scale resources based on the processing rate of the queue itself. Some queues can be allowed to grow large during peek hours, because they can be processed during off hours, while others may require scaling up the service capacity to cover a minimum latency requirement.
Misuse of message queues may of course lead to distributed monoliths and add a lot of complexity in understanding how data flows within the system. This is not something specific for queues and it's the same for direct HTTP calls. As all things, we need to use the right tool for the right purpose.
Actually, one of my pet peeves are internal web hooks. Web hooks are good at notifying an external partner compared to the alternatives, but the complexity is too great to justify its use for internal services as well. Just use a message queue instead for your own services.
I agree. Guard clauses and chunk statements make code much more maintainable. It has little cost of implementing, but a huge return on readability and reduced complexity. Nested if-statements are often hard to read and easy to break.
> I have never seen Kotlin used in environments other than Android
I have seen several companies that use Kotlin as a backend language (often with Spring). I personally don't find the differences enough to bother switching from Java, but I also don't mind working with Kotlin in existing projects.
I think you may have a point. At mature companies, they have largely solved the product market fit and uses a stable stack that just works. I have worked worked for such companies, and developers jumped at the chance to use the latest (untested) technologies for greenfield projects if they had the chance.
In my startup we also use a "boring" stack, but the problems we solve are innovative and motivation in itself. The developers work closely with customers and can see the impact that the product has. They are no longer working in a Jira-factory and while they are still interested in technology they also find motivation in the product itself.
I've worked in "enterprise" and have a different experience. The enterprise projects that I was working on switched to Java 8 in 2015. There were some legacy services that remained on 5 or 6 for a while, but they were mostly in "maintenance" mode and nobody wanted to spend time on them.
I have over two decades of experience and there has always been room for trying out the "new" technologies and keeping up with the latest best practices, even in enterprise. I know that not everyone has this experience, but there are actually a lot that happens outside slow big American legacy companies...
In my current startup we use the latest JVM and have a mix of Java and Kotlin. It works really well and we have never experienced any problems with development speed that was related to code or language syntax. JVM + Spring boot + Postgres may be the "boring" choice, but it has enabled us to focus on getting things done and focusing on the product. It didn't take long for juniors to be productive in our stack either. Spring itself looks a bit scary at first sight, but once you learned the basic philosophy you have less issues than a Node project in my experience.
I know that my experience may not match your experience, so I recognize that I can't make a generic statement. It's just a bit frustrating to see similar statements made by people with bad experiences.
- Not all Java development happens in enterprise. There is a thriving eco system of small to middle sized companies and startups using Java
- Not all enterprises are the same. I've actually noticed a shift to the other extreme, where enterprise uses the latest technologies to attract new employees. Nobody who has a choice wants to work with factory patterns on an old version of Java
- Old Java patterns like factories and extreme use of inheritance is out of fashion. There is of course a lag like in any trends, but remember that Java is so widely used so you will always find companies that are slow to adopt, or have legacy software that is in maintenance mode.