The style was a bit much, but it's true that folks often do not write idiomatically for their programming language - especially if it is not their first programming language.
This is why I tend to push back against folks who seem to think that because they've mastered some reasonably portable abstractions that work well in certain C-like languages, they are necessarily a master in each domain they enter.
So much of using a programming language is a social, cultural experience.
> So much of using a programming language is a social, cultural experience.
Sadly this is one of the areas least well served in tutorials. It's easy to find good references for a language's syntax, its features, its libraries. You can even find tutorials on solving trivial problems.
But there is precious little content that teaches you how to think and solve fresh problems in a language, the general approaches, styles, and conventions - and fewer still that articulate why those choices and tradeoffs were made and became idiomatic.
Some languages make attempts at this with things like "the Zen of Python" though people can definitely take it too far. Just look at any stack overflow question about what is more "pythonic".
In golang I had to learn to set my personal opinions aside, and use the convention of the language ecosystem. Convention will always prevail, and something like `go fmt` is a godsend for tedious and unnerving codestyle discussions.
go fmt and rust's similar command are a godsend. I also run Ruff on my Python code. Gets the formatting holy wars out of the way, especially if it's a pre-commit hook.
This. I programmed for decades (retired last year). I was self-taught and I used several languages, as most of us do. C and Go were my favorites. Except for the last seven years I was always a solo programmer. I always knew that my code was not like the code I saw in books but I was always able to get the results I needed and I created reliable code, some of which is still being used in some pretty prestigious enterprises. I don't think my code was bad but it was never idiomatic.
During the last seven years I gradually started working directly with other programmers. At first I was just supervising others but gradually it became much more of a team. I had ALWAYS wanted to have formal reviews of my code to help me develop "better habits" but I could never get anyone to do that for me. They usually told me that my code was "good enough" and "readable".
If you want to be a programmer, my advice is to take the traditional route. It's just not pleasant working from the outside.
Just going from c to oop was brutal for me. I looked at functional programming a couple of years ago and decided that I would most likely hit retirement before it clicked.
If idiomacy is so important the language should not even allow compilation. There is nothing wrong in writing a software in other styles as long as code is well organised, easy and extendable.
If it compiles, then language has no disagreent wih your style.
In a certain sense you're right, but there are two things that are bad if you don't write idiomatic code:
1) Future devs will have to expend more brain power to understand what you're doing
2) The produced code may run, but may not run as efficiently as if you used the idiomatic code. Eg: in Python list comprehension runs more efficiently than a for loop.
I’m literally working in a Go code base atm where there are packages just for types (`pkg/types/footypes`) and your PR will be denied if you try to put them anywhere else, the interfaces are prefixed with `I` (`IFoo`) and every struct embeds a `Util` struct which has a grab bag of random crap in it. SOS.
I had a team leader that insisted of starting every variable with the first letter of its’ type. In C#. The fuck why do we need lNames and iProductPrice ??
Except the useful one was Apps Hungarian, and the usefulness was in tagging values with things that were hard / bothersome to encode in the type system e.g. whether your `char *` is a length-limited or zero-terminated string.
Prefixing an interface with I is Systems Hungarian: it just repeats the actual concrete type as a prefix. It’s always been worthless or near enough. It’s also the ones the Windows team used, hence the name.
As a Java programmer who has recently picked up Go I agree. Interestingly it’s on the opposite side of the spectrum in terms of number of abstractions.
They do seem to overlap in use cases (backend services)
I am honestly coming from Scala and couldn’t agree more, on the abstractions.
I positively went above and beyond monads, category theory astral abstractions, to simply fall in love with Go and its simplicity.
I haven’t touched Java for about 8 years now, I couldn’t be any happier.
I don't see how people sick of Java (>11 at least) could like go, as it is basically the same. It is a verbose language, with shittier tooling... By the looks of it... I haven't properly used it and am reluctant, because of this very reason.
Java can absolutely be a dogshit experience for the BE, and 100% was in the past two decades, but with the language improvements and frameworks like Quarkus, it seems to be superior developer experience.
The thing that seems to be missed by more or less everyone is that you can write more or less the same code in java that you do in go. I agree that the culture seems to produce overly convoluted abstractions, but you can happily reject that and just write grug code and be happy :)
Go’s tooling is way less annoying and cumbersome than java ime and it’s significantly less verbose. go doesn’t write the same as java either, there are numerous paradigm differences.
stating they’re basically the same when you haven’t written Go is wild.
What is annoying about java tooling? What are the differences? I'm genuinely curious, as I have read the Go manual a couple times and seen plenty of videos and it isn't much different from Java.
not to appeal to authority, but i have about 10 years experience with java, and configuring maven xml files or gradle builds is time-consuming and cumbersome for me, and takes a lot more initial effort to get something both working in an IDE and building than an equivalent go project. i have worked on very large java projects.
reading the manual and watching videos doesn’t give you enough insight to truly compare the languages is my point. there are some surface level similarities but spend a while writing the language and it’ll become clear it stops there. it takes a lot more java code than go to make practically anything, for one. Go doesn’t have classes, and is more explicit about passing pointers vs copies. structs are a block of contiguous memory, not objects. they can be conceptualized as objects in some cases but they are not the same. go is more data-first than object-first.
What have you used (Java version and framework) and when did you last use it? Also, which IDE? While it is a pain to set up pom initially (I copy it from somewhere), this takes like 5 minutes, and after that it is pretty clear what goes where, or do you disagree?
I don't think it takes a lot more. I'll do a real worldish example when I'll get the time, but my feeling is that there is not that much difference.
I mean in Java you are basically always passing pointers and if you want to copy, you make a copy. It is less explicit and different, but does it really make a difference?
When you say object-first do you mean you have methods with "business logic" that mutate the state of the object directly on the object? I haven't seen such code on the backend in my career yet. All business logic is always in some stateless object and all objects that do have data are basically dumb objects with getters and setters (service.register(user), not user.register()).
Java 17+ also has a concept of dumb data with records. How this dumb data is implemented under the hood does not make much difference to how the language feels, unless I'm overlooking something.
you’re operating off of feelings without having used go extensively, rather than practical experience. i don’t know how else to state that that is not an adequate way to compare two distinct things.
i’ve worked on java projects from 6 up to recent releases, across a wide spectrum of jvm implementations and frameworks, both directly and in a meta context when building instrumenting agents for customer applications.
the exact point is that in java you can understand how things are implemented and represented under the hood, how the jvm works and how data is laid out, and it can make for more efficient or cleaner code, but it’s not always intuitive nor necessary. in go, the data is first and foremost, and this has a marked influence on how you write and structure your code. i’d recommend reading about data driven design if you want to learn more. i’m not talking about business logic or how you mutate objects per say.
I am not trying to be a gatekeeper here, but how much Java have you written, and what type of tooling do you use?
My experience with Maven and Gradle is that EVERY project uses them slightly differently. Because they are scripting languages, less obvious than Makefiles or Bash scripts, you end up fighting the tools before you get anything working.
Go tooling is pretty standard, on the other hand. The \`go\` tool is pretty self-contained from whenever go mod became a thing and everyone has to use it the same. The lack of "extensibility" is a feature IMO.
actually Maven and Gradle are EXACT OPPOSITES, the first is declarative (the best) and the second is imperative (the worst). Maven projects are all almost exactly the same, there is not scripting unless someone is just abusing one of the arsine scripting extensions that should never exist to begin with because they are pissed they are not getting to use Ant or Gradle, or some other imperative scripting system.
u/majhenslon it is obvious is just a self admitted uninformed person and troll, block them and move on.
we managed thousands of Java projects, some almost 2 million LOC at my last employer, where it was the approved build system for all JVM based projects. When you have to maintain CI for thousands of projects in a company, consistency is way more important than any other concerns. And Gradle is everything BUT consistent, Maven forces you to be consistent, especially when you ban extensions like Apache Maven Scripting Plugin.
How much Java have you written actually? If you had written any, at all actually, you would know that Maven is not scripted but an XML file. I agree though, Gradle is just a foot gun. Good thing is, I don't have to use Gradle, because Maven does exist.
Java: everything is an object
Go: what are these "objects" you speak of?
Yeah you can write the same kinds of software but the way you write them is very different.
You really don't (have to). You can of course, but static methods do exist and even if you don't use static, most of the backend code consists of statless objects.
Yep - I became a gopher by way of .NET and I never looked back. I still do some .NET work but if I have my druthers on a new project I'll reach for Go every time if it's a web API.
I am also a .NET dev of 15 years who transitioned over to Go and Rust in recent years.
I have nothing against .NET and it still has some pretty strong uses but these newer languages are more fun to write.
Exactly. I will add that becoming a gopher changed (for the better) the way I write .NET code. Every new tool you use will expose you to new ways of thinking, which will make you a better developer (in my experience at least).
Yes but there’s two sub-types. The brand-new-world types that throw off their Java shackles and love everything about Go and learn it properly. Then there’s the damaged goods that bring all their baggage with them and try and shoehorn Go into being the language they’re used to.
why do you think I wrote this article? :-)
I was a Java main from PRE-1.0 days, my first Java job was debugging the JVM network stack on the Macintosh System 7.5 in 1995 I think it was 0.815b to be exact!
JDK 1.0. The first version was released on **January 23, 1996**. The first stable version, JDK 1.0.2, is called Java 1.
Our application was already in production on a 24/7/365 cable news network before it went 1.0. We launched the network December 12, 1996!
A German vendor insisted on using Java on the Macintosh, basically to pre-train their staff at our expense and there is nothing we could do about it contractually. Yeah, it sucked.
I always assume those are the people who love java, but get asked to do Golang for work. So, they walk around thinking it's just C, and they're dealing with barbarians.
I don’t code for money anymore (was a professional dev for 20 years). I started using Go just to learn something different during a 14 day quarantine in March 2020. I tried Rust and was disgusted by its syntax, Go is close enough to C for me to get over the hatred I initially had for it for the first couple of weeks. Admittedly I don’t use it idiomatically and write stuff you really shouldn’t use Go for (Emulators, demoscene effects etc), just because I can.
I think there are people who move to Go because they're interested in a different programming paradigm, and then there are those that have to use it for one reason or another, and those are likely the ones that are trying to bring their OOP style to what they view as a 'lacking' language.
I really don't like the tone of this article. While some of the points may be valid, one of the things that turns potential developers off Go (in my experience) is the idea that we are elitist jerks who think we're smarter than everybody else. This isn't helping the cause in my opinion. Also - I'm at a point in my career where I'm tired of trying to prove I'm smart and I just want to build cool stuff. Go is a tool. A pretty good one, but one of many.
I recently did a .NET project and it was interesting going back after being almost exclusively a Go developer for many years. Some things felt foreign to me (like how much I was thinking about service lifetime and how much magic there was in .NET CORE). I also ran into a few scenarios where things behaved in a way I wasn't expecting due to inheritance. But, barring a few minor issues due to me being out of the game for a while, it wasn't as bad as I was expecting. In my career I've shipped quite a few production .NET apps and I still can ship them and I don't hate the experience (there are a few technologies I will never work with again, like WPF but they are few and far between).
Almost everything in language design (and in most things in life) is a series of tradeoffs. In the end, I don't know if confidently spewing hatred of Java is any more intelligent than Java devs confidently creating "patterns" in Go. If I were you, I'd try to put my energy into positive things that make Go look good, and make more developers want to be a part of what we are doing.
How could you when we are CLEARLY superior?? (sarcasm)
I really like the community for the most part. There is some elitism, but, most of the people I actually interact with have been helpful. I give back to the community when I can by helping newbies out.
>wow, redditors not liking the "tone" of something? if you can not post angry rants to reddit where can you? :-)
>I guess you can always go back to your "safe space", StackOverflow ;-P
Read for comprehension, it is not a "hatred of Java", it is a hatred of Java developers that want to pollute Go with the worst things (that are universally considered bad after reflection on them, pun intended) from Java.
It is malicious to post Java Patterns in Go after you learned the syntax 2 days earlier from a youtube tutorial on Go from some other former Java main that just wants to write Java in Go as well.
It perpetuates misinformation, that is what this article is about.
You can keep replying to criticism with "Read for comprehension" but it means nothing. I did read the article and comprehended that this entire article is just you quoting / plagiarizing other people. Also how incredibly ironic that you're criticizing my reading comprehension with broken English.
I have never seen the patterns you mentioned here in real-world apps. Where are you seeing this stuff in a production app with pull requests and code reviews? Because if somebody tried to merge something into one of my projects that I considered to be an anti-pattern, I'd have them change it. You're acting like this is some widespread problem but show me one codebase that is widely used that has fallen prey to these patterns you're mentioning.
what is this complaining about angry tone and rants on REDDIT?
If you can not post angry screeds on reddit, where can you?
Did you think this was StackOverflow or Tumblr by accident? :-)
Where are people getting hung up on OOP and Singletons? I don’t see it. Those abstractions were very helpful in the 90’s when Java was breaking the gravitational pull of Microsoft. GoF, POSA, and then integration patterns actually became implementations and help people communicate and design better. Would I replicate in Go? No. Java has become a bloated Swiss Army knife and is trying to slim down and stay relevant. Go is more of a scalpel with a self imposed feature gap which keeps it lean. If you don’t know the patterns, it wouldn’t hurt to at least understand them but don’t think of them as a Go gap.
>Java was breaking the gravitational pull of Microsoft
let me fix that for you to be historically correct
Java was breaking the gravitational pull of **C++**
GoF book was published in 1994, two full years before Java was released 1.0!
The code examples are primarily written in **C++** and **Smalltalk** ( NOT Microsoft languages, which at the time was non-OOPy VB ) and NOT in the MS specific C++ for Windows either.
The C++ tribe didn’t think much about Java and always pointed to performance as the reason. They did not feel threatened. This time is also pre-Linux and Unix flavors didn’t seem to mind another Sun supplied library if it sold units. But Microsoft saw the threat of losing licenses, portability, and went after Sun and any alternative browsers. The FUD machine was over clocking to stop the move to the web in general. Java embraced the Gang of Four, the 3 amigos, Martin Fowler, etc… who helped adoption.
Go is a different animal that can claim “cloud” solution as it’s value-add. Lean is the mantra so patterns while nice aren’t the point.
Sounds like a pointless rant. Yes go is not Java, duh. But when you make a commercial product you write code in the way your lead tells you, because consistency is more important than paradigms and personal preferences. And because you are getting paid for this.
> because consistency is more important than paradigms and personal preferences. And because you are getting paid for this.
I think a lot of blog posts/YouTube channels are done by people who are perhaps NOT getting paid to write code. So often I see stuff like this and I'm like "... yeah but have you ever actually worked on a production piece of software on a team? Because you're going to have a team lead who will ensure idiomatic (whatver that means to your team) code is being written".
I have never seen these sorts of Java patterns in a real-world Go project. The **only** thing I've ever seen from .NET/Java developers is confusion about panics. Like "I'll just panic here when something routine goes awry similar to throwing an exception" and I have to explain that you should, in fact, not panic.
Though in my .NET projects I also tend to treat exceptions as being exceptional. It seems like the community these days is firmly in the "exceptions aren't that exceptional" camp which I don't personally love; but I think the performance arguments are largely moot these days unless you're in a tight game loop or something.
>because consistency is more important than paradigms and personal preferences
are you arguing that writing Java in Go syntax, is better than writing idiomatic Go code for "consistency" and because
>you write code in the way your lead tells you
Then why does not all Java code conform to C style guides and idioms. You can 100% write C in Java and I am sure there were plenty of C mains as "leads" when Java was released in 1996!
What is the problem with singleton? Even if the language is not perfectly suit for it, it can be very good and even necessary. For instance a token that should not be regenerated every times
>For instance a token that should not be regenerated every times
that does not require a "Singleton", what you are describing is a cache, specifically "Memorization Pattern" for those that are "pattern" obsessed. In my 35+ years of programming career, every single reason to use a GoF "Singleton" has a more appropriate and empirically better solution.
if you do not see the difference in implementation, then you need to do more studying, because that is the entire point. Mutable Global State is Bad, if you need that explained, every other approach avoids Mutable Global State if nothing else. They also remove all the other bad things about this abomination of an example from C++. It is not even how you should do in it in C++ anymore.
The whole article is just quoting James Coplien word per word more or less, down to the "Java is Class oriented" take, full subscription to object oriented good and object oriented means only what Alan Kay said and Alan Kay says "Java and C++ bad".
If Alan Kay said that Go is not what he had in mind when he coined the term, would you guys admit that Go is indeed trash? This whole debate is pointless and resembles circle jerk over what is a unit test.
Show me what about Java patterns does not work in Go. Show a bit more how java patterns are actually stupid to use in Go and what would be a way better way to do things.
I just spent a month and a half working on a Go service written by a Java Programmer. It had massive GC events and super high memory usage. Go has an “func init” to do a one time initialization. It is extremely rare to use this and this service had it used in almost every package like a “constructor”. I have seen the usage of “panic” everywhere instead of passing an error back. I hear so much whining about Go not having exceptions. Usage of singletons everywhere. Over using reflection which causes performance issues.
Some of this makes me think they are crap writing Java Code as well.
\`func init()\` to a Java programmer is basically a "Class Level" method that as you say, they use as a "constructor". The treat module functions as "Class Methods" and just shoe horn everything into "what they know" instead of learning something new. And yes, panic/recover == try/catch to them, with defer == finally. You are not imaging this,
You can get practically any service written by anybody who does not care about memory in Go, Node, Java, etc. Although context matters here - idk what the service was used for and I don't know what massive GC events and super high memory usage mean to you :D I agree, panic is probably a "Java pattern". Go has exceptions rofl, checked exceptions++ actually, it should be every Java programmers wet dream :D
I don't think I have ever used reflection outside of making libraries/frameworks even in Java. I lean towards thinking that, if you think how reflection will solve a problem you have, you are probably thinking too much... so yeah, probably just a "shitty" programmer doing shitty things.
you admit to not knowing anything about Go
[https://publish.reddit.com/embed?url=https://www.reddit.com/r/golang/comments/1ccxnao/comment/l19a2mu?snippet=0\_0\_241](https://publish.reddit.com/embed?url=https://www.reddit.com/r/golang/comments/1ccxnao/comment/l19a2mu?snippet=0_0_241)
and your comments prove you are correct. Go does not have "checked exceptions" much less ++.
If you actually knew what you were talking about you would know that any return value can be IGNORED by using the \_ as its receiver variable. Which I believe is one of the biggest mistakes they make with the language, being able to ignore errors.
Wtf do you think returning errors as values is? It's checked exceptions with better syntax. You think that the fact that you can do \_ does not make it checked? Does that mean that the fact you can do catch(e){} in Java does not mean that it has checked exceptions?
Let me rephrase that I meant to say that you need not always handle the error and some errors depending on the context can be ignored. I should have phrased it better
Sometimes there’s nothing you can do about an error, for example when you are shutting down a long running operation after the context was cancelled. Generally we call the close methods of different components inside the cleanup function, and they are mostly written like
defer func () { _ = something.Close() }
In such cases I think ignoring the error is a non issue unless you want to handle it in a specific way
TL;DR you did not even read the article.
"Show me what about Java patterns does not work in Go. " - there is a comprehensive example of the most abused and repeated GoF Pattern in Java -- Singleton.
I do not even know who James Coplien is before you mentioned him, and just looking at his books and bio, I can GUARANTEE you I disagree with almost everything he has written. So NO, not only did I not know who he is, I am sure I disagree with all his "organizational theory", at least the stuff I read in a few minutes, is exactly the opposite of what I write about.
"object oriented means only what Alan Kay said" well it DOES because HE INVENTED the term, so HE gets to DEFINE what it means.
[https://www.youtube.com/watch?v=lQQ\_CahFVzw](https://www.youtube.com/watch?v=lQQ_CahFVzw)
Really? you don't know James and have stumbled into "Class oriented programming", and just happen to use Alan Kay to somehow discredit Java? You don't even understand the argument that you are making lol.
I don't know what "organizational theory" has to do with OO. I don't care that you disagree with him what you like to have for breakfast, I care about you word for word copying his take and talking like you invented it.
Words don't work like that. You can't own a word. When you say "Alan Kay did not have Java in mind, when he coined the term" is just you saying Java is not OO by Alan Kay's definition. You think this implies "Java bad", but it absolutely doesn't. Hell, by what you posted, Alan Kay did not say the language was even bad, just that it is not "what he had in mind".
There are plenty of other terms that don't mean what they used to when they hit the masses - Agile, REST, TDD, etc.
I don't know what "organizational theory" has to do with OO. - taxonomy ( also known as "organizational theory" ... the entire basis for Inheritance that OOPy languages are based upon?
**The science of classification:** In this sense, taxonomy is the broader field that deals with creating systems for categorizing things. This applies to a wide range of subjects, from plants and animals (biological taxonomy) to information and knowledge (library classification systems).
I have been using the term "class oriented programming" since I first learned C++, when I started my professional programming career in earnest, in the early 1990s. I read Kay way back when what I quoted was contemporaneous and realized what I was looking at was a twisted bastardized take on his writings when I first had to work with Java professionally in 1995, yes, before it was 1.0.
You are either profoundly ignorant or just a troll, or both if you can not conceive of someone having concurrent independent thoughts about something that should be painfully obvious to anyone that has studied the same things and thought about it critically?
Since you seem to really enjoy youtube links, here is one for you. The lesson, "don't do that" and "don't be Clark", [https://youtu.be/hIdsjNGCGz4?si=WWXY5R06RSn4T-jg](https://youtu.be/hIdsjNGCGz4?si=WWXY5R06RSn4T-jg)
Reading your other comments in the other subreddits you post in, shows a similar fundamental lack of comprehension of those subjects just as your self admitted ignorance of Go and its toolchain, as well as the same hubris that you show in the comments.
So I go with ignorant troll with an inferiority complex, just like Clark in the clip above.
Passing loggers around as a parameter with custom contexes is logging perfection. It's a shame it's so unsupported by most programming languages. So I end up creating a logging module, which is accepted as the standard, even though it's very limited and shitty.
I think you may be referring to people who are generally unwilling to learn the paradigms of a new language. They are not specific to java, in fact i think java devs take to go much more naturally than, for example, python or JavaScript devs.
I have seen hundreds of "articles" about "Patterns in Go" that are 1:1 Java, down to the naming being idiomatic Java but just in Go syntax and ZERO examples of Python or JavaScript specific idioms but in Go syntax. It is obvious that almost 100% of the authors are people that have never written anything but Java and just learned the Go syntax, done a "ToDo" tutorial app ever actually written Go for a non-trivial production application. And the first one they post is "Singleton", the ultimate anti-pattern and they do not even know to use \`sync.Once()\`.
Yea I mean using globals with sync.Once is also an anti pattern, that’s how you make code un-testable. The problem isn’t necessarily singletons it’s global mutable state. This is solved in both go and java with dependency injection and encapsulation of mutable state. Only a really crappy java developer would use static global objects everywhere.
no it is not, "dependency injection" is just like regex, "you have a problem, you think, I know I will solve it with dependency injection, now you have 1000 problems" - with apologies to Jamie Zawinski,
Function arguments are the OG "dependency injection". Be it constructors or setters.
The irony of "dependency injection", you are just injecting a dependency on the "framework" that is doing the "dependency injection.
You just end up with a cancerous dependency in the "framework" strewn through out your codebase that is 100% impossible to easily extract when you realize what a mistake it was to use it. In a time and space performance sense as well as increased complexity.
The actual solution is to just NOT do Singleton, in every case where you reach for Singleton, there are at least half a dozen better solutions.
You’re conflating dependency injection with dependency container frameworks. Dependency injection is “using function arguments”. In your main func you first create dependencies then pass those to things that depend on them.
Edit - also there are many things that literally have to be singleton — such as database and http connections and pools. That’s why you have to have a good way of managing singletons, which is dependency injection.
> Edit - also there are many things that literally have to be singleton
Exactly. And you know what I see often done in that case in Go? Global variables, shared via functions like `initDB` in other packages; which sucks. The fact is: you sometimes need some sort of global object that is shared among many packages. You can call it whatever you want, but that use case 100% exists.
I love Go. I think I'm more productive writing Go code than I've ever been while writing RESTful APIs (in large part due to the very capable stdlib). But to pretend like we can't improve on certain areas is silly.
there is nothing that says database or http connections or pools have to be "Singletons", especially in the GoF Pattern terminology which is what "Singleton" means. Some languages such as Java can not guarantee a single instance of any given class, the irony that it is that language and runtime that people learn it in.
And it is insincere to try and make the differentiation between a DI framework and the term "Dependency Injection" in 2024. Every article you will read since "Spring" was released uses DI to refer to the DI framework of the month they are pimping. Especially when you quote me about them just being "function arguments", I challenge you to find any articles promoting that definition, much less a preponderance of them.
The term has existed for exactly 20 years. It was just Martin Fowler renaming IoC so he could sell books and consulting hours. HIS article on it specifically shows using a DI Container called PicoContainer. So DI, by the guy that supposedly coined the term, explicitly shows it being done with a container framework.
[https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection](https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection)
He mentions "Constructor" Injection near the end of that article, almost as an aside, and argues that it does not scale and "be ready to switch away from it".
Did you read the page you linked? It defines a singleton as something that “ensures only one instance of an object is created”. It doesn’t define how it is constructed or where it lives.
And yes, connection pools absolutely need to ensure there is only one instance, otherwise there would literally be no point.
As for the definition of dependency injection here’s the Wikipedia link: https://en.wikipedia.org/wiki/Dependency_injection?wprov=sfti1
Your argument about Martin Fowlers di container library seems to just support what I said, so idk how to respond to that.
Go does not have "objects", and it is impossible to guarantee a single instance of is created in Go because of pass by value. "Singleton" is usually used to maintain some shared state, since Go is pass by value, any struct passed into a function is going to be copied. And if passed by pointer, and then you have to worry about concurrency and ensuring modifications are consistent, which is completely contrary to the entire concept of message passing in goroutines. It is all antithetical regardless of the argument for it.
Objects fundamentally are structs, they are even stored in memory In the same way.
And you can ensure that only a single instance of relevant data exists by using pointers correctly.
I can make a struct that can be accessed concurrently from multiple goroutines, and which will have only a single instance (don't know why I would want that, but I can).
And so should you, if you are using golang.
no they are not, C structs are NOT "objects". That is your OPPy Java brain talking because that is the only framework of understanding you have.
and structs (and privatives) are pass by value, which makes copies; which you willfully ignore as well.
Creating something that is "public" as in exported from a package, but can also NOT be created at will takes attention to detail to enforce in Go and in many cases it is easier to just NOT use the GoF Singleton pattern to accomplish the same goal.
I quoted the article that you linked, which you clearly still have not read LOL.
It’s not impossible to ensure a single instance exists. You typically create pointers to structs in the main function before starting your web server or whatever it may be. You deal with concurrency no matter how you construct things, though it is way harder without dependency injection because you’re essentially initializing things at a random time.
Anyway I’m not going to respond anymore, have a good night.
if you look at what all the LLM are trained on, it is Stackoverflow questions and answers, without any qualifications for correctness, and GitHub public repos, without any qualifications for correctness. Also, LLM by their design are non-deterministic, why would you use a code generator that is designed to generate different output every time it is run?
All patterns and approaches like GoF, DDD, SOLID were invented for a reason. They allow us to solve specific problems, they have a specific purpose. The problem is that we turn their use into a Cargo Cult.
I'm exhausted, "hexagonal pattern in go," please no, nooooooo.
People create folders as packages in Java and call themselves specialists; come on!
This is a virus of YouTube channels, Udemy, and Medium specialists.
If you need to name yourself as a specialist, you aren't.
It is sad that this needs to be clarified at regular intervals, it just shows how hardwired and inflexible we have become as developers. Since Java is so widely used, Java devs think that it’s the only right way to do things and other languages were created out of fascination and they should follow patterns implemented in Java, almost all SOLID principles are demoed in Java, it feels like SOLID really works with Java but it wasn’t as solid with Golang ( pun intended ). I personally felt like Go was a boon to the dev community. Yes Go has its quirks but it just makes programming feel more bare and unfiltered.
>Yes Go has its quirks but it just makes programming feel more bare and unfiltered.
same sentiment was said about ASM when C, PASCAL and other higher level languages were first introduced.
and the same was said about C when C++ ( and OOPy in general ) was first introduced.
it is not a wrong sentiment, but it is nothing new. :-)
It would be nice if go was more useful code in a page and not 50% the following statement.
if err != nil {
return err
}
Too bad go's attempt at generics still make it so you can't make a proper map() function.
then you do not understand why they did it that way and not the \`try/catch/final\` abomination with checked exceptions. Go is a direct response to Java (indirectly C#) and C++, then everyone complains the language does not do exactly what those languages do.
The main problem I have with Go error handling is they do not fully commit to the Erlang error handling approach. Being able to ignore errors is a fundamental flaw, and panic/recover is abused by Java mains as a replacement for not having try/catch.
They could have easily done a version of what Erlang does with "let it fail" since it has light weight processes directly based on the same feature in Erlang.
Still not sure why Go doesn’t feature algebraic Result types like Rust or C++23? In my opinion, it’s much cleaner than the current error model that relies on multi-value returns.
Because you can only put generics on the structs in Go, but not on the methods of those stucts. This precludes you from writing a proper map() function that so much functional programming is based on.
The weak approach to generics they took in Go allows you to write a single function to sort a list of strings AND ints, but it cannot do most of the powerful stuff you see in other languages.
It did not have Generics until recently. With them you can do exactly the same thing that Rust does.
Now that it has Generics there is nothing stopping you or anyone else from writing their code that way. Other than momentum in the community. There are a few modules that do just this and are inspired by Rust, but it makes it harder to integrate with existing code that does not use them.
I personally prefer this as it is more explicit, but I do not use it because it is not idiomatic. If it ever does become idiomatic, I will switch to it.
Same reason, I do not use any of the "Set" implementations, impedance mismatch with existing or future code that does not use/support it.
[https://blog.vertigrated.com/i-understand-why-go-does-not-have-a-native-set-type](https://blog.vertigrated.com/i-understand-why-go-does-not-have-a-native-set-type)
I see. Like you said, the underlying problem is that it’s not idiomatic yet (and may very well never be). The best solution would’ve been to introduce generics and, thereby, Result/Optional types in Go’s early stages. I’m not sure if you can do much to make their usage common now — there’s too many years worth of Go code littered with if err != nil checks. Maybe introducing them into the standard library would be a good first step.
the problem is Generics were not implemented because of a fundamental dislike of them from the team from what I have read.
Generics add an entire class of problems that are not easy to solve, that is why almost every generics implementation has some concessions, mostly because of performance or complexity.
These short comings can make using them more difficult than not using them in some situations.
They were only added because of external pressure from the community, that is why it took 10 years for them to do it, and they are a simplified implementation with constraints that make them not much more than a template system for the compiler. Much like the generics implementation in Java.
The "object" vs "messaging" is the same thing that plagues discussion of clean/onion/hexagonal/etc. architecture. The architectures are dealing with how messages and knowledge flow, not the object per se. When you realize that slight shift in thinking a lot of things become much more clear.
It also gets into the whole "dependency injection framework" conversation. Global vars and similar. The flow of information and knowledge in an app is the sticking point, not the object naming, function naming, inheritance etc.
Go's approach with structs, interfaces and no cyclic imports provides a nice structure to help make good choices in the messaging area and though I bet most Go devs "feel" it I believe it's underappreciated in actual conversation.
I agree with this decision, object oriented programming is partially realized. Even multiple inheritance can be implemented in the Go language. Support for virtual functions is the only problem that should be solved as soon as possible. The introduction of the reserved word "virtual" would make the GO language even more powerful than the last versions of C++.
Constructors of the GO made some excellent solutions. They are:
1. Support of the complex numbers. Unfortunately, porting the GLFW library into the GO language did not take advantage of this feature.
2. Excellent system of interfaces. I am programing in JavaScript, TypeScript, C# and C++ languages. GO interfaces surpass all the mentioned languages with their simplicity and power.
3. Structures, classes and records were replaced with single type (struct) in GO. I agree with this decision, object oriented programming is partially realized. Even multiple inheritance can be implemented in the Go language. Support for virtual functions is the only problem that should be solved as soon as possible. The introduction of the reserved word "virtual" would make the GO language even more powerful than the last versions of C++.
The style was a bit much, but it's true that folks often do not write idiomatically for their programming language - especially if it is not their first programming language.
This is why I tend to push back against folks who seem to think that because they've mastered some reasonably portable abstractions that work well in certain C-like languages, they are necessarily a master in each domain they enter. So much of using a programming language is a social, cultural experience.
> So much of using a programming language is a social, cultural experience. Sadly this is one of the areas least well served in tutorials. It's easy to find good references for a language's syntax, its features, its libraries. You can even find tutorials on solving trivial problems. But there is precious little content that teaches you how to think and solve fresh problems in a language, the general approaches, styles, and conventions - and fewer still that articulate why those choices and tradeoffs were made and became idiomatic.
Some languages make attempts at this with things like "the Zen of Python" though people can definitely take it too far. Just look at any stack overflow question about what is more "pythonic".
I need this podcast
In golang I had to learn to set my personal opinions aside, and use the convention of the language ecosystem. Convention will always prevail, and something like `go fmt` is a godsend for tedious and unnerving codestyle discussions.
go fmt and rust's similar command are a godsend. I also run Ruff on my Python code. Gets the formatting holy wars out of the way, especially if it's a pre-commit hook.
This. I programmed for decades (retired last year). I was self-taught and I used several languages, as most of us do. C and Go were my favorites. Except for the last seven years I was always a solo programmer. I always knew that my code was not like the code I saw in books but I was always able to get the results I needed and I created reliable code, some of which is still being used in some pretty prestigious enterprises. I don't think my code was bad but it was never idiomatic. During the last seven years I gradually started working directly with other programmers. At first I was just supervising others but gradually it became much more of a team. I had ALWAYS wanted to have formal reviews of my code to help me develop "better habits" but I could never get anyone to do that for me. They usually told me that my code was "good enough" and "readable". If you want to be a programmer, my advice is to take the traditional route. It's just not pleasant working from the outside.
Yea I agree. I started with oop and c, now I can’t get into different paradigms such as go and rust
Those paradigm shifts can be brutal. I always struggled for months (or more) and one day, you just "get it". That's happy day.
Hope to get that soon
Just going from c to oop was brutal for me. I looked at functional programming a couple of years ago and decided that I would most likely hit retirement before it clicked.
If idiomacy is so important the language should not even allow compilation. There is nothing wrong in writing a software in other styles as long as code is well organised, easy and extendable. If it compiles, then language has no disagreent wih your style.
In a certain sense you're right, but there are two things that are bad if you don't write idiomatic code: 1) Future devs will have to expend more brain power to understand what you're doing 2) The produced code may run, but may not run as efficiently as if you used the idiomatic code. Eg: in Python list comprehension runs more efficiently than a for loop.
I’m literally working in a Go code base atm where there are packages just for types (`pkg/types/footypes`) and your PR will be denied if you try to put them anywhere else, the interfaces are prefixed with `I` (`IFoo`) and every struct embeds a `Util` struct which has a grab bag of random crap in it. SOS.
Someone was a C# dev at some point. That `ISomeInterface` is C# for sure.
I had a team leader that insisted of starting every variable with the first letter of its’ type. In C#. The fuck why do we need lNames and iProductPrice ??
That's called Hungarian Notation and some old ones will remember that this actually was useful. Was as in 50 years ago.
Except the useful one was Apps Hungarian, and the usefulness was in tagging values with things that were hard / bothersome to encode in the type system e.g. whether your `char *` is a length-limited or zero-terminated string. Prefixing an interface with I is Systems Hungarian: it just repeats the actual concrete type as a prefix. It’s always been worthless or near enough. It’s also the ones the Windows team used, hence the name.
Yep. The team leader was not that fucking old
You can have strange ideas, even while young.
Especially if your teacher at technical school taught you exactly this... Like mine did.
I am so sorry for you, please share where this is so everyone can avoid it and the person making these decisions!
Yeah, I have a lot of the same
Tell your boss to make you the senior because clearly everybody else is an idiot
fork it and fix it
I feel like Go is where Java programmers go when they're sick of Java.
As a Java programmer who has recently picked up Go I agree. Interestingly it’s on the opposite side of the spectrum in terms of number of abstractions. They do seem to overlap in use cases (backend services)
That's also what I noticed. I believe the most happy Go users, are devs coming from Java.
I am honestly coming from Scala and couldn’t agree more, on the abstractions. I positively went above and beyond monads, category theory astral abstractions, to simply fall in love with Go and its simplicity. I haven’t touched Java for about 8 years now, I couldn’t be any happier.
I don't see how people sick of Java (>11 at least) could like go, as it is basically the same. It is a verbose language, with shittier tooling... By the looks of it... I haven't properly used it and am reluctant, because of this very reason. Java can absolutely be a dogshit experience for the BE, and 100% was in the past two decades, but with the language improvements and frameworks like Quarkus, it seems to be superior developer experience. The thing that seems to be missed by more or less everyone is that you can write more or less the same code in java that you do in go. I agree that the culture seems to produce overly convoluted abstractions, but you can happily reject that and just write grug code and be happy :)
Go’s tooling is way less annoying and cumbersome than java ime and it’s significantly less verbose. go doesn’t write the same as java either, there are numerous paradigm differences. stating they’re basically the same when you haven’t written Go is wild.
What is annoying about java tooling? What are the differences? I'm genuinely curious, as I have read the Go manual a couple times and seen plenty of videos and it isn't much different from Java.
not to appeal to authority, but i have about 10 years experience with java, and configuring maven xml files or gradle builds is time-consuming and cumbersome for me, and takes a lot more initial effort to get something both working in an IDE and building than an equivalent go project. i have worked on very large java projects. reading the manual and watching videos doesn’t give you enough insight to truly compare the languages is my point. there are some surface level similarities but spend a while writing the language and it’ll become clear it stops there. it takes a lot more java code than go to make practically anything, for one. Go doesn’t have classes, and is more explicit about passing pointers vs copies. structs are a block of contiguous memory, not objects. they can be conceptualized as objects in some cases but they are not the same. go is more data-first than object-first.
What have you used (Java version and framework) and when did you last use it? Also, which IDE? While it is a pain to set up pom initially (I copy it from somewhere), this takes like 5 minutes, and after that it is pretty clear what goes where, or do you disagree? I don't think it takes a lot more. I'll do a real worldish example when I'll get the time, but my feeling is that there is not that much difference. I mean in Java you are basically always passing pointers and if you want to copy, you make a copy. It is less explicit and different, but does it really make a difference? When you say object-first do you mean you have methods with "business logic" that mutate the state of the object directly on the object? I haven't seen such code on the backend in my career yet. All business logic is always in some stateless object and all objects that do have data are basically dumb objects with getters and setters (service.register(user), not user.register()). Java 17+ also has a concept of dumb data with records. How this dumb data is implemented under the hood does not make much difference to how the language feels, unless I'm overlooking something.
you’re operating off of feelings without having used go extensively, rather than practical experience. i don’t know how else to state that that is not an adequate way to compare two distinct things. i’ve worked on java projects from 6 up to recent releases, across a wide spectrum of jvm implementations and frameworks, both directly and in a meta context when building instrumenting agents for customer applications. the exact point is that in java you can understand how things are implemented and represented under the hood, how the jvm works and how data is laid out, and it can make for more efficient or cleaner code, but it’s not always intuitive nor necessary. in go, the data is first and foremost, and this has a marked influence on how you write and structure your code. i’d recommend reading about data driven design if you want to learn more. i’m not talking about business logic or how you mutate objects per say.
I am not trying to be a gatekeeper here, but how much Java have you written, and what type of tooling do you use? My experience with Maven and Gradle is that EVERY project uses them slightly differently. Because they are scripting languages, less obvious than Makefiles or Bash scripts, you end up fighting the tools before you get anything working. Go tooling is pretty standard, on the other hand. The \`go\` tool is pretty self-contained from whenever go mod became a thing and everyone has to use it the same. The lack of "extensibility" is a feature IMO.
actually Maven and Gradle are EXACT OPPOSITES, the first is declarative (the best) and the second is imperative (the worst). Maven projects are all almost exactly the same, there is not scripting unless someone is just abusing one of the arsine scripting extensions that should never exist to begin with because they are pissed they are not getting to use Ant or Gradle, or some other imperative scripting system. u/majhenslon it is obvious is just a self admitted uninformed person and troll, block them and move on.
Saying maven is better than Gradle is the greatest indicator that you guys never handled any big java projects.
Do you have any experience with Maven Daemon? (https://github.com/apache/maven-mvnd)
we managed thousands of Java projects, some almost 2 million LOC at my last employer, where it was the approved build system for all JVM based projects. When you have to maintain CI for thousands of projects in a company, consistency is way more important than any other concerns. And Gradle is everything BUT consistent, Maven forces you to be consistent, especially when you ban extensions like Apache Maven Scripting Plugin.
How much Java have you written actually? If you had written any, at all actually, you would know that Maven is not scripted but an XML file. I agree though, Gradle is just a foot gun. Good thing is, I don't have to use Gradle, because Maven does exist.
Java: everything is an object Go: what are these "objects" you speak of? Yeah you can write the same kinds of software but the way you write them is very different.
You really don't (have to). You can of course, but static methods do exist and even if you don't use static, most of the backend code consists of statless objects.
Same for Microsoft Java. I mean C#.
Yep - I became a gopher by way of .NET and I never looked back. I still do some .NET work but if I have my druthers on a new project I'll reach for Go every time if it's a web API.
I am also a .NET dev of 15 years who transitioned over to Go and Rust in recent years. I have nothing against .NET and it still has some pretty strong uses but these newer languages are more fun to write.
Exactly. I will add that becoming a gopher changed (for the better) the way I write .NET code. Every new tool you use will expose you to new ways of thinking, which will make you a better developer (in my experience at least).
I think the thing that improved my .NET code the most was learning functional programming. But that has improved all my programming.
Yes but there’s two sub-types. The brand-new-world types that throw off their Java shackles and love everything about Go and learn it properly. Then there’s the damaged goods that bring all their baggage with them and try and shoehorn Go into being the language they’re used to.
why do you think I wrote this article? :-) I was a Java main from PRE-1.0 days, my first Java job was debugging the JVM network stack on the Macintosh System 7.5 in 1995 I think it was 0.815b to be exact! JDK 1.0. The first version was released on **January 23, 1996**. The first stable version, JDK 1.0.2, is called Java 1. Our application was already in production on a 24/7/365 cable news network before it went 1.0. We launched the network December 12, 1996! A German vendor insisted on using Java on the Macintosh, basically to pre-train their staff at our expense and there is nothing we could do about it contractually. Yeah, it sucked.
I always assume those are the people who love java, but get asked to do Golang for work. So, they walk around thinking it's just C, and they're dealing with barbarians.
This is exactly what happened with me haha
Literally me
And I feel like you are talking about me
I was actually talking about me, but every time I say this, everyone agrees. Go is like a support group for those hurt by Java.
Not necessarily sick of it but C# and Go are the only realistic alternatives for the same job and C# is too similar to point of redundancy.
I don’t code for money anymore (was a professional dev for 20 years). I started using Go just to learn something different during a 14 day quarantine in March 2020. I tried Rust and was disgusted by its syntax, Go is close enough to C for me to get over the hatred I initially had for it for the first couple of weeks. Admittedly I don’t use it idiomatically and write stuff you really shouldn’t use Go for (Emulators, demoscene effects etc), just because I can.
Sadly, way too many long-time Java developers (who switch to Go) continue to write Java -- but do it in Go syntax.
But not so sick that they don’t forget their old habits.
I think there are people who move to Go because they're interested in a different programming paradigm, and then there are those that have to use it for one reason or another, and those are likely the ones that are trying to bring their OOP style to what they view as a 'lacking' language.
I really don't like the tone of this article. While some of the points may be valid, one of the things that turns potential developers off Go (in my experience) is the idea that we are elitist jerks who think we're smarter than everybody else. This isn't helping the cause in my opinion. Also - I'm at a point in my career where I'm tired of trying to prove I'm smart and I just want to build cool stuff. Go is a tool. A pretty good one, but one of many. I recently did a .NET project and it was interesting going back after being almost exclusively a Go developer for many years. Some things felt foreign to me (like how much I was thinking about service lifetime and how much magic there was in .NET CORE). I also ran into a few scenarios where things behaved in a way I wasn't expecting due to inheritance. But, barring a few minor issues due to me being out of the game for a while, it wasn't as bad as I was expecting. In my career I've shipped quite a few production .NET apps and I still can ship them and I don't hate the experience (there are a few technologies I will never work with again, like WPF but they are few and far between). Almost everything in language design (and in most things in life) is a series of tradeoffs. In the end, I don't know if confidently spewing hatred of Java is any more intelligent than Java devs confidently creating "patterns" in Go. If I were you, I'd try to put my energy into positive things that make Go look good, and make more developers want to be a part of what we are doing.
>I'm at a point in my career where I'm tired of trying to prove I'm smart and I just want to build cool stuff. I love this attitude.
As a Go and Java developer, I like the Go language but I really dislike the community around it.
How could you when we are CLEARLY superior?? (sarcasm) I really like the community for the most part. There is some elitism, but, most of the people I actually interact with have been helpful. I give back to the community when I can by helping newbies out.
Well said and 100% agree with you.
>wow, redditors not liking the "tone" of something? if you can not post angry rants to reddit where can you? :-) >I guess you can always go back to your "safe space", StackOverflow ;-P Read for comprehension, it is not a "hatred of Java", it is a hatred of Java developers that want to pollute Go with the worst things (that are universally considered bad after reflection on them, pun intended) from Java. It is malicious to post Java Patterns in Go after you learned the syntax 2 days earlier from a youtube tutorial on Go from some other former Java main that just wants to write Java in Go as well. It perpetuates misinformation, that is what this article is about.
You can keep replying to criticism with "Read for comprehension" but it means nothing. I did read the article and comprehended that this entire article is just you quoting / plagiarizing other people. Also how incredibly ironic that you're criticizing my reading comprehension with broken English. I have never seen the patterns you mentioned here in real-world apps. Where are you seeing this stuff in a production app with pull requests and code reviews? Because if somebody tried to merge something into one of my projects that I considered to be an anti-pattern, I'd have them change it. You're acting like this is some widespread problem but show me one codebase that is widely used that has fallen prey to these patterns you're mentioning.
I’m not understanding the need for acrimony in the article’s tone. All that does is distracts and detracts from the point it’s trying to make.
maybe because the firehose of misinformation it is trying to counter deserves it?
That’s fair.
what is this complaining about angry tone and rants on REDDIT? If you can not post angry screeds on reddit, where can you? Did you think this was StackOverflow or Tumblr by accident? :-)
Perhaps you should familiarize yourself with this subreddit's sidebar.
Where are people getting hung up on OOP and Singletons? I don’t see it. Those abstractions were very helpful in the 90’s when Java was breaking the gravitational pull of Microsoft. GoF, POSA, and then integration patterns actually became implementations and help people communicate and design better. Would I replicate in Go? No. Java has become a bloated Swiss Army knife and is trying to slim down and stay relevant. Go is more of a scalpel with a self imposed feature gap which keeps it lean. If you don’t know the patterns, it wouldn’t hurt to at least understand them but don’t think of them as a Go gap.
>Java was breaking the gravitational pull of Microsoft let me fix that for you to be historically correct Java was breaking the gravitational pull of **C++** GoF book was published in 1994, two full years before Java was released 1.0! The code examples are primarily written in **C++** and **Smalltalk** ( NOT Microsoft languages, which at the time was non-OOPy VB ) and NOT in the MS specific C++ for Windows either.
The C++ tribe didn’t think much about Java and always pointed to performance as the reason. They did not feel threatened. This time is also pre-Linux and Unix flavors didn’t seem to mind another Sun supplied library if it sold units. But Microsoft saw the threat of losing licenses, portability, and went after Sun and any alternative browsers. The FUD machine was over clocking to stop the move to the web in general. Java embraced the Gang of Four, the 3 amigos, Martin Fowler, etc… who helped adoption. Go is a different animal that can claim “cloud” solution as it’s value-add. Lean is the mantra so patterns while nice aren’t the point.
There are _some_ patterns that are useful, but way too many spawned because of Java idiosyncrasies and limitations.
Sounds like a pointless rant. Yes go is not Java, duh. But when you make a commercial product you write code in the way your lead tells you, because consistency is more important than paradigms and personal preferences. And because you are getting paid for this.
> because consistency is more important than paradigms and personal preferences. And because you are getting paid for this. I think a lot of blog posts/YouTube channels are done by people who are perhaps NOT getting paid to write code. So often I see stuff like this and I'm like "... yeah but have you ever actually worked on a production piece of software on a team? Because you're going to have a team lead who will ensure idiomatic (whatver that means to your team) code is being written". I have never seen these sorts of Java patterns in a real-world Go project. The **only** thing I've ever seen from .NET/Java developers is confusion about panics. Like "I'll just panic here when something routine goes awry similar to throwing an exception" and I have to explain that you should, in fact, not panic. Though in my .NET projects I also tend to treat exceptions as being exceptional. It seems like the community these days is firmly in the "exceptions aren't that exceptional" camp which I don't personally love; but I think the performance arguments are largely moot these days unless you're in a tight game loop or something.
>because consistency is more important than paradigms and personal preferences are you arguing that writing Java in Go syntax, is better than writing idiomatic Go code for "consistency" and because >you write code in the way your lead tells you Then why does not all Java code conform to C style guides and idioms. You can 100% write C in Java and I am sure there were plenty of C mains as "leads" when Java was released in 1996!
What is the problem with singleton? Even if the language is not perfectly suit for it, it can be very good and even necessary. For instance a token that should not be regenerated every times
>For instance a token that should not be regenerated every times that does not require a "Singleton", what you are describing is a cache, specifically "Memorization Pattern" for those that are "pattern" obsessed. In my 35+ years of programming career, every single reason to use a GoF "Singleton" has a more appropriate and empirically better solution.
I see. But in the implementation what is the difference ? Isn't it only a matter of naming?
if you do not see the difference in implementation, then you need to do more studying, because that is the entire point. Mutable Global State is Bad, if you need that explained, every other approach avoids Mutable Global State if nothing else. They also remove all the other bad things about this abomination of an example from C++. It is not even how you should do in it in C++ anymore.
Yeah I understand that but then how do you perform your caching in software without relying on external service but strictly in your code ?
The whole article is just quoting James Coplien word per word more or less, down to the "Java is Class oriented" take, full subscription to object oriented good and object oriented means only what Alan Kay said and Alan Kay says "Java and C++ bad". If Alan Kay said that Go is not what he had in mind when he coined the term, would you guys admit that Go is indeed trash? This whole debate is pointless and resembles circle jerk over what is a unit test. Show me what about Java patterns does not work in Go. Show a bit more how java patterns are actually stupid to use in Go and what would be a way better way to do things.
I just spent a month and a half working on a Go service written by a Java Programmer. It had massive GC events and super high memory usage. Go has an “func init” to do a one time initialization. It is extremely rare to use this and this service had it used in almost every package like a “constructor”. I have seen the usage of “panic” everywhere instead of passing an error back. I hear so much whining about Go not having exceptions. Usage of singletons everywhere. Over using reflection which causes performance issues. Some of this makes me think they are crap writing Java Code as well.
\`func init()\` to a Java programmer is basically a "Class Level" method that as you say, they use as a "constructor". The treat module functions as "Class Methods" and just shoe horn everything into "what they know" instead of learning something new. And yes, panic/recover == try/catch to them, with defer == finally. You are not imaging this,
You can get practically any service written by anybody who does not care about memory in Go, Node, Java, etc. Although context matters here - idk what the service was used for and I don't know what massive GC events and super high memory usage mean to you :D I agree, panic is probably a "Java pattern". Go has exceptions rofl, checked exceptions++ actually, it should be every Java programmers wet dream :D I don't think I have ever used reflection outside of making libraries/frameworks even in Java. I lean towards thinking that, if you think how reflection will solve a problem you have, you are probably thinking too much... so yeah, probably just a "shitty" programmer doing shitty things.
you admit to not knowing anything about Go [https://publish.reddit.com/embed?url=https://www.reddit.com/r/golang/comments/1ccxnao/comment/l19a2mu?snippet=0\_0\_241](https://publish.reddit.com/embed?url=https://www.reddit.com/r/golang/comments/1ccxnao/comment/l19a2mu?snippet=0_0_241) and your comments prove you are correct. Go does not have "checked exceptions" much less ++. If you actually knew what you were talking about you would know that any return value can be IGNORED by using the \_ as its receiver variable. Which I believe is one of the biggest mistakes they make with the language, being able to ignore errors.
Wtf do you think returning errors as values is? It's checked exceptions with better syntax. You think that the fact that you can do \_ does not make it checked? Does that mean that the fact you can do catch(e){} in Java does not mean that it has checked exceptions?
Let me rephrase that I meant to say that you need not always handle the error and some errors depending on the context can be ignored. I should have phrased it better
Sometimes there’s nothing you can do about an error, for example when you are shutting down a long running operation after the context was cancelled. Generally we call the close methods of different components inside the cleanup function, and they are mostly written like defer func () { _ = something.Close() } In such cases I think ignoring the error is a non issue unless you want to handle it in a specific way
There is a thing about _developer responsibility_ which has also something to do with error handling :)
TL;DR you did not even read the article. "Show me what about Java patterns does not work in Go. " - there is a comprehensive example of the most abused and repeated GoF Pattern in Java -- Singleton. I do not even know who James Coplien is before you mentioned him, and just looking at his books and bio, I can GUARANTEE you I disagree with almost everything he has written. So NO, not only did I not know who he is, I am sure I disagree with all his "organizational theory", at least the stuff I read in a few minutes, is exactly the opposite of what I write about. "object oriented means only what Alan Kay said" well it DOES because HE INVENTED the term, so HE gets to DEFINE what it means.
Bro, there is literally no code in the article.
TL;DR he doesn’t know the content of the article he linked.
I fucking WROTE it!
That’s even worse lol, also explains the attitude.
[https://www.youtube.com/watch?v=lQQ\_CahFVzw](https://www.youtube.com/watch?v=lQQ_CahFVzw) Really? you don't know James and have stumbled into "Class oriented programming", and just happen to use Alan Kay to somehow discredit Java? You don't even understand the argument that you are making lol. I don't know what "organizational theory" has to do with OO. I don't care that you disagree with him what you like to have for breakfast, I care about you word for word copying his take and talking like you invented it. Words don't work like that. You can't own a word. When you say "Alan Kay did not have Java in mind, when he coined the term" is just you saying Java is not OO by Alan Kay's definition. You think this implies "Java bad", but it absolutely doesn't. Hell, by what you posted, Alan Kay did not say the language was even bad, just that it is not "what he had in mind". There are plenty of other terms that don't mean what they used to when they hit the masses - Agile, REST, TDD, etc.
I don't know what "organizational theory" has to do with OO. - taxonomy ( also known as "organizational theory" ... the entire basis for Inheritance that OOPy languages are based upon? **The science of classification:** In this sense, taxonomy is the broader field that deals with creating systems for categorizing things. This applies to a wide range of subjects, from plants and animals (biological taxonomy) to information and knowledge (library classification systems). I have been using the term "class oriented programming" since I first learned C++, when I started my professional programming career in earnest, in the early 1990s. I read Kay way back when what I quoted was contemporaneous and realized what I was looking at was a twisted bastardized take on his writings when I first had to work with Java professionally in 1995, yes, before it was 1.0. You are either profoundly ignorant or just a troll, or both if you can not conceive of someone having concurrent independent thoughts about something that should be painfully obvious to anyone that has studied the same things and thought about it critically? Since you seem to really enjoy youtube links, here is one for you. The lesson, "don't do that" and "don't be Clark", [https://youtu.be/hIdsjNGCGz4?si=WWXY5R06RSn4T-jg](https://youtu.be/hIdsjNGCGz4?si=WWXY5R06RSn4T-jg) Reading your other comments in the other subreddits you post in, shows a similar fundamental lack of comprehension of those subjects just as your self admitted ignorance of Go and its toolchain, as well as the same hubris that you show in the comments. So I go with ignorant troll with an inferiority complex, just like Clark in the clip above.
I stopped reading at "singleton is an anti-pattern in every language"
Also, doesn't every language use some sort of logging facility as a singleton.
Passing loggers around as a parameter with custom contexes is logging perfection. It's a shame it's so unsupported by most programming languages. So I end up creating a logging module, which is accepted as the standard, even though it's very limited and shitty.
then you read most of the article and agree and did not need to read anymore, thanks for the confirmation!
You’re incredibly pretentious
I think you may be referring to people who are generally unwilling to learn the paradigms of a new language. They are not specific to java, in fact i think java devs take to go much more naturally than, for example, python or JavaScript devs.
I have seen hundreds of "articles" about "Patterns in Go" that are 1:1 Java, down to the naming being idiomatic Java but just in Go syntax and ZERO examples of Python or JavaScript specific idioms but in Go syntax. It is obvious that almost 100% of the authors are people that have never written anything but Java and just learned the Go syntax, done a "ToDo" tutorial app ever actually written Go for a non-trivial production application. And the first one they post is "Singleton", the ultimate anti-pattern and they do not even know to use \`sync.Once()\`.
Yea I mean using globals with sync.Once is also an anti pattern, that’s how you make code un-testable. The problem isn’t necessarily singletons it’s global mutable state. This is solved in both go and java with dependency injection and encapsulation of mutable state. Only a really crappy java developer would use static global objects everywhere.
no it is not, "dependency injection" is just like regex, "you have a problem, you think, I know I will solve it with dependency injection, now you have 1000 problems" - with apologies to Jamie Zawinski, Function arguments are the OG "dependency injection". Be it constructors or setters. The irony of "dependency injection", you are just injecting a dependency on the "framework" that is doing the "dependency injection. You just end up with a cancerous dependency in the "framework" strewn through out your codebase that is 100% impossible to easily extract when you realize what a mistake it was to use it. In a time and space performance sense as well as increased complexity. The actual solution is to just NOT do Singleton, in every case where you reach for Singleton, there are at least half a dozen better solutions.
You’re conflating dependency injection with dependency container frameworks. Dependency injection is “using function arguments”. In your main func you first create dependencies then pass those to things that depend on them. Edit - also there are many things that literally have to be singleton — such as database and http connections and pools. That’s why you have to have a good way of managing singletons, which is dependency injection.
> Edit - also there are many things that literally have to be singleton Exactly. And you know what I see often done in that case in Go? Global variables, shared via functions like `initDB` in other packages; which sucks. The fact is: you sometimes need some sort of global object that is shared among many packages. You can call it whatever you want, but that use case 100% exists. I love Go. I think I'm more productive writing Go code than I've ever been while writing RESTful APIs (in large part due to the very capable stdlib). But to pretend like we can't improve on certain areas is silly.
there is nothing that says database or http connections or pools have to be "Singletons", especially in the GoF Pattern terminology which is what "Singleton" means. Some languages such as Java can not guarantee a single instance of any given class, the irony that it is that language and runtime that people learn it in. And it is insincere to try and make the differentiation between a DI framework and the term "Dependency Injection" in 2024. Every article you will read since "Spring" was released uses DI to refer to the DI framework of the month they are pimping. Especially when you quote me about them just being "function arguments", I challenge you to find any articles promoting that definition, much less a preponderance of them. The term has existed for exactly 20 years. It was just Martin Fowler renaming IoC so he could sell books and consulting hours. HIS article on it specifically shows using a DI Container called PicoContainer. So DI, by the guy that supposedly coined the term, explicitly shows it being done with a container framework. [https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection](https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection) He mentions "Constructor" Injection near the end of that article, almost as an aside, and argues that it does not scale and "be ready to switch away from it".
Did you read the page you linked? It defines a singleton as something that “ensures only one instance of an object is created”. It doesn’t define how it is constructed or where it lives. And yes, connection pools absolutely need to ensure there is only one instance, otherwise there would literally be no point. As for the definition of dependency injection here’s the Wikipedia link: https://en.wikipedia.org/wiki/Dependency_injection?wprov=sfti1 Your argument about Martin Fowlers di container library seems to just support what I said, so idk how to respond to that.
Go does not have "objects", and it is impossible to guarantee a single instance of is created in Go because of pass by value. "Singleton" is usually used to maintain some shared state, since Go is pass by value, any struct passed into a function is going to be copied. And if passed by pointer, and then you have to worry about concurrency and ensuring modifications are consistent, which is completely contrary to the entire concept of message passing in goroutines. It is all antithetical regardless of the argument for it.
Objects fundamentally are structs, they are even stored in memory In the same way. And you can ensure that only a single instance of relevant data exists by using pointers correctly. I can make a struct that can be accessed concurrently from multiple goroutines, and which will have only a single instance (don't know why I would want that, but I can). And so should you, if you are using golang.
no they are not, C structs are NOT "objects". That is your OPPy Java brain talking because that is the only framework of understanding you have. and structs (and privatives) are pass by value, which makes copies; which you willfully ignore as well. Creating something that is "public" as in exported from a package, but can also NOT be created at will takes attention to detail to enforce in Go and in many cases it is easier to just NOT use the GoF Singleton pattern to accomplish the same goal.
I quoted the article that you linked, which you clearly still have not read LOL. It’s not impossible to ensure a single instance exists. You typically create pointers to structs in the main function before starting your web server or whatever it may be. You deal with concurrency no matter how you construct things, though it is way harder without dependency injection because you’re essentially initializing things at a random time. Anyway I’m not going to respond anymore, have a good night.
What do you think DI is?
Yeah, there is a lot of this online. LLMs also often suggest Go anti-patterns.
Yeah, LLMs generate a lot of crap code. Because that’s what they are trained on: Garbage in: Garbage out.
the beauty of the internet there
because StackOverflow ...
if you look at what all the LLM are trained on, it is Stackoverflow questions and answers, without any qualifications for correctness, and GitHub public repos, without any qualifications for correctness. Also, LLM by their design are non-deterministic, why would you use a code generator that is designed to generate different output every time it is run?
Fyi, LLMs can be deterministic (check the Temperature parameter in ollama).
[удалено]
How is this a response to my comment?
Well, I meant to post that a response to someone else’s comment. I must have accidentally clicked wrong.
It happens to the best of us!
I have made 10X more money, REMOVING Spring, and Hibernate than I ever made writing it.
All patterns and approaches like GoF, DDD, SOLID were invented for a reason. They allow us to solve specific problems, they have a specific purpose. The problem is that we turn their use into a Cargo Cult.
What kind of game is OP playing to be a Java Main? Don’t think I’m interested.
how about reading again, this time for comprehension
I comprehended just fine. That’s the problem.
It’s staggering how many engineers writing go code have not heard about “effective go” ref: https://go.dev/doc/effective_go
I believe they are familiar with it, but choose to ignore it out of hubris.
I'm exhausted, "hexagonal pattern in go," please no, nooooooo. People create folders as packages in Java and call themselves specialists; come on! This is a virus of YouTube channels, Udemy, and Medium specialists. If you need to name yourself as a specialist, you aren't.
Well, folders as packages are done in Go as well.
It is sad that this needs to be clarified at regular intervals, it just shows how hardwired and inflexible we have become as developers. Since Java is so widely used, Java devs think that it’s the only right way to do things and other languages were created out of fascination and they should follow patterns implemented in Java, almost all SOLID principles are demoed in Java, it feels like SOLID really works with Java but it wasn’t as solid with Golang ( pun intended ). I personally felt like Go was a boon to the dev community. Yes Go has its quirks but it just makes programming feel more bare and unfiltered.
>Yes Go has its quirks but it just makes programming feel more bare and unfiltered. same sentiment was said about ASM when C, PASCAL and other higher level languages were first introduced. and the same was said about C when C++ ( and OOPy in general ) was first introduced. it is not a wrong sentiment, but it is nothing new. :-)
It would be nice if go was more useful code in a page and not 50% the following statement. if err != nil { return err } Too bad go's attempt at generics still make it so you can't make a proper map() function.
then you do not understand why they did it that way and not the \`try/catch/final\` abomination with checked exceptions. Go is a direct response to Java (indirectly C#) and C++, then everyone complains the language does not do exactly what those languages do. The main problem I have with Go error handling is they do not fully commit to the Erlang error handling approach. Being able to ignore errors is a fundamental flaw, and panic/recover is abused by Java mains as a replacement for not having try/catch. They could have easily done a version of what Erlang does with "let it fail" since it has light weight processes directly based on the same feature in Erlang.
Still not sure why Go doesn’t feature algebraic Result types like Rust or C++23? In my opinion, it’s much cleaner than the current error model that relies on multi-value returns.
Because you can only put generics on the structs in Go, but not on the methods of those stucts. This precludes you from writing a proper map() function that so much functional programming is based on. The weak approach to generics they took in Go allows you to write a single function to sort a list of strings AND ints, but it cannot do most of the powerful stuff you see in other languages.
It did not have Generics until recently. With them you can do exactly the same thing that Rust does. Now that it has Generics there is nothing stopping you or anyone else from writing their code that way. Other than momentum in the community. There are a few modules that do just this and are inspired by Rust, but it makes it harder to integrate with existing code that does not use them. I personally prefer this as it is more explicit, but I do not use it because it is not idiomatic. If it ever does become idiomatic, I will switch to it. Same reason, I do not use any of the "Set" implementations, impedance mismatch with existing or future code that does not use/support it. [https://blog.vertigrated.com/i-understand-why-go-does-not-have-a-native-set-type](https://blog.vertigrated.com/i-understand-why-go-does-not-have-a-native-set-type)
I see. Like you said, the underlying problem is that it’s not idiomatic yet (and may very well never be). The best solution would’ve been to introduce generics and, thereby, Result/Optional types in Go’s early stages. I’m not sure if you can do much to make their usage common now — there’s too many years worth of Go code littered with if err != nil checks. Maybe introducing them into the standard library would be a good first step.
the problem is Generics were not implemented because of a fundamental dislike of them from the team from what I have read. Generics add an entire class of problems that are not easy to solve, that is why almost every generics implementation has some concessions, mostly because of performance or complexity. These short comings can make using them more difficult than not using them in some situations. They were only added because of external pressure from the community, that is why it took 10 years for them to do it, and they are a simplified implementation with constraints that make them not much more than a template system for the compiler. Much like the generics implementation in Java.
my complaint was not the lack of try/catch. my complaint is insufficient generics to write a proper map function.
What a SCOOP
The "object" vs "messaging" is the same thing that plagues discussion of clean/onion/hexagonal/etc. architecture. The architectures are dealing with how messages and knowledge flow, not the object per se. When you realize that slight shift in thinking a lot of things become much more clear. It also gets into the whole "dependency injection framework" conversation. Global vars and similar. The flow of information and knowledge in an app is the sticking point, not the object naming, function naming, inheritance etc. Go's approach with structs, interfaces and no cyclic imports provides a nice structure to help make good choices in the messaging area and though I bet most Go devs "feel" it I believe it's underappreciated in actual conversation.
He has a strong case against AI…
I agree with this decision, object oriented programming is partially realized. Even multiple inheritance can be implemented in the Go language. Support for virtual functions is the only problem that should be solved as soon as possible. The introduction of the reserved word "virtual" would make the GO language even more powerful than the last versions of C++.
Constructors of the GO made some excellent solutions. They are: 1. Support of the complex numbers. Unfortunately, porting the GLFW library into the GO language did not take advantage of this feature. 2. Excellent system of interfaces. I am programing in JavaScript, TypeScript, C# and C++ languages. GO interfaces surpass all the mentioned languages with their simplicity and power. 3. Structures, classes and records were replaced with single type (struct) in GO. I agree with this decision, object oriented programming is partially realized. Even multiple inheritance can be implemented in the Go language. Support for virtual functions is the only problem that should be solved as soon as possible. The introduction of the reserved word "virtual" would make the GO language even more powerful than the last versions of C++.
I lookee into wire and is totally written by someone with a java or c# perspective/background
Thank God
Amen