tm-guimaraes

22 giorni fadiscuss

I think more than meta chasing, the problem comes from laxk of actual community due to the crazy effectiveness of online matchmaking. When all you had where community servers and rooms, toxicity was more manageable. With other players all being nameless folks you will never play with again, the worst side of people can more easily come out.

tm-guimaraes

3 mesi fadiscuss

Also, the fact that other tech leaders know very well how Sam Altman operates doesn’t help OpenAI secure deals with big tech.

Domain knowledge, expertise, is a big thing in tech, because code can be written fast if you know what to do, and so by having that expertise, building a frontier model is a matter of time and capex. Anthropic is founded by top ex-openAi, so they are not lacking in expertise, and are not attached to SamAlt. It’s an easy choice of who to finance.

Anthropic will win long term because big tech knows how much of a loud mouth sam is, how much of the piee he wants, he is more of a rival then some company they could use to grow. While Anthropic (even though they aren’t really good guys) seems more like a shared common good for the big tech then openAi, like linux corporate business deals version.

tm-guimaraes

3 anni fadiscuss

New features makes lot of reflection use cases unnecessary.

Spring already bumped base to java 17, and the plan is to improve the internals, but changing public APIs is a different story.

Still, other options appear everyday so you don't have to use Spring. But yeah, glaciar speed, but with that comes low churning rate and old stuff needing very low maintenance.

tm-guimaraes

3 anni fadiscuss

Depends if they are talking about Spring the framework, or Spring Boot, the "conventions bootstrapper"

Both of them do not have bad docs, maybe some sub project might have, but compared to RoR (sorry never used Django), Spring's projects docs are magnificent. Their problem could be navigation for someone new to it, or in the case of Spring Framework, just too much concepts.

So, Spring Framework is basically "make everything configurable extensible etc", its code if full of old java patterns for generic stuff (the infamous "AbstractSingletonProxyBeanFactory" , ye, not great), to not only have a very feature full dependency injection, but to allow stuff like AOP and setting up via xml and many other things. This is the base of spring so you will have to kinda deal with its concepts if you hit an issue.

Ruby on Rails was a reaction to things like Spring, it's philosophy is "convention over configuration" in contrast to Spring's unparalleled configuration options. And so Spring Boot is born as a reaction to Rails.

Spring Boot is at its core 2 things

* an annotation engine for Spring configuration, instead of using all those hellish factories or XML

* Sane Defaults for Spring Framework There were also many other projects under its umbrella to streamline with those 2 things other components of the Spring ecosystems, from Http Apis to Repository patterns

Ok so reflection and magic:

* Both are full of reflection. That's how it keeps being very generic at its core.

* Magic is an issue of Boot, you just put some annotation and it would do who knows what. Still way less magic than Rails, as at least you see the annotations, and search for it in the docs. Framework isn't really "magic", as you would have to explicitly configure everything in either XML or through its classes. ( Spring Data does have weird magic, worse that Rails, generating full SQL queries from method names? C'mon)

Nowadays, modern java (server side) either uses Spring Boot (due to easily supporting most kind of infra you might use from persistence to messaging), something specific for their use case (quarkus makes it easy for small image and quick startup) or not use a DI framework at all, as most servers nowadays are fine, and language has plenty of features to not need some management of Injected. I actually see no value now to "minimal DI frameworks", because manually wiring is not actually hard except when you have a circular dependency, which you should not have anyway. (The codebases I had better time working with were either on Boot or had no managed DI)

Spring Boot and Framework new releases actually require Java17, with the objective of being able to start to clean up their codebase from old patterns that were kinda required in the old times.

tm-guimaraes

3 anni fadiscuss

that's a culture issue that is changing rapidly to avoid that. Also that was common due to previous limitations in the language.

regarding the "com.lol.myapp", i actually think this is a good think for package management, it avoids naming issues with packages for different vendors and forks. On the code itself you should only see these on the import lines on top of the file, which isn't really a big deal.

I think most people issues with java come from old legacy codebases that had over the top patterns like that due to limitations in the language and culture. Nowadays, with a proper conventions guide, java can be quite clean. Sure it won't ever be as clean as something new as Kotlin, as it tries hard to maintain backwards compatibility, so old ugly stuff will remain in the language (even if you don't use it, you might see old code that does), and new stuff designs are restricted by what already exists, but it still has its advantages over new shiny things like kotlin for example: new pattern matching, compile time and compatibility (kotlin "100% compatibility" doesn't actually cover everything, and compatibility is important for Big Co with loads of teams and loads of internal and external dependencies and tools)

comments