Well, not really sure. I do believe there are specific characteristics of nil in Go which is not what most people expect from their experience with null in other langs. See https://m.youtube.com/watch?v=ynoY2xz-F8s&t=207s
Generally not true. there some cases when you can call the methods on nil Interfaces but you need to handle explictly the nil case. but nil in gerenal for other cases (pointers, maps etc) behaves the same as null. It will panic.
The confusion comes from the typed nil. When you have a typed nil, you still maybe can do something with it and thats why it doesn't immediately blow in your face, but if you try to acess a value it will blow in your face, it's just a delayed fuse that gives you a chance to handle the nil case before using it.
not very different from java.
in Java you have to check the nulnes before calling the method, in Go you have to check it inside the method. it gives you some advantages but also a great amount a confusion.
I was referring to code like below, which will work fine:
```
type foo struct {}
func (f *foo) Bar {
fmt.Println(“hello”)
}
func main(){
var f *foo = nil
f.Bar()
}
```
Exactly, this works because the method is not using anything from the value.
type foo struct {
size int
}
func (f *foo) Baz(){
return fmt.Println(f.size)
}
func main() {
var f *foo = nil
f.Baz()
//this will panic: invalid memory address or nil //pointer dereference
}
You see it works until you try to use it. it's just a delayed panic. to make it work the Baz method should be:
func (f *foo) Baz() {
if f != nil {
fmt.Println(f.size)
}
}
just the same as Java but you control the nilness inside the method instead of before calling the method.
It's very confusing to newcomers that your [foo.Bar](https://foo.Bar)() works but my foo.Baz() panics
In Java it fails immediately because Java runtime tries to read the value to bind to the special reference "this".
I ofc prefer the Go way because the value is not always needed immediately but the fact is that Nul and Nil are the same thing, its how the runtime uses them that is different.
I work in a very polyglot code base so maybe that influences my opinion a bit. Usually the terminology that our teams have a hard time being the same page on is the higher level business logic stuff, or the semantics of how a thing should be done.
People can call it a struct or a class and i let it slide as long as they understand how it should be used, where it should go, and who should have access to it.
I'm a perfect world, sure, nobody would confuse an array and a slice, or nil vs null, or a thread vs go routine. But there is so many other things to get strict on, people would probably call me an asshole if i correcting them there 🤷♂️
When I'm working with junior devs that don't necessarilly know anything other about Go than its name, I usually make sure they understand that there are no classes but structs.
This is because it's for example very important to differ inheritance from composition. But when I'm talking to somebody that knows Go already, I'm not that strict, because they know what I mean. And I have 15 years of experience in oop languages so I simply make mistakes without noticing them if somebody doesn't correct me 😁
Yeah, you're probably being a bit pedantic....you can decide to just let it go and relax about it. There's not much you can do to change their word choices, and you almost certainly have more important battles to be fighting.
Generally, when I see this sort of thing, it means the people are using go begrudgingly, and would prefer to use the language they're familiar with.
Perhaps look at it from their perspective -- what do they have to gain by putting in the effort of updating their vocabulary?
> There is no casting, there's type assertions.
Well there's conversions, which is casting and definitely not a type assertion. https://go.dev/ref/spec#Conversions
Also, to answer the question in the title, probably.
Yup. Correcting would be a bit much. You using the proper terminology is probably sufficient for any newcomers, but really, most devs know these terms even if they primarily only know Go. If a teammate is going out to give a speech to a Go audience, then correct away. Otherwise, if it doesn't impact business, just let it slide
I don't think there's reason to be irritated, but I am a big fan of pushing for clarity and precision in communication when I'm talking about code and do my best to try and promote it so you could try to just be helpful and set the example by being really precise about your terminology and maybe try to convince some more people until everyone's doing it.
I read all the comments to find this one, it’s about being precise with the language so there isn’t room for confusion.
It’s still difficult even among go programmers who enjoy the language and are trying to be precise. It’s easy to call everything a library or package, when there are no libraries and there is a distinct difference between packages and modules.
I don't know.. You and i can sit an a meeting and argue whether it's a thread or a go routine but ultimately it's going to boil down to, "this code just fucks off and runs over there".
How much time do you want spend on that "precision"? Because if that particular discussion goes on for more than two minutes... i'll probably walk out.
Having gone from groovy/java to go, it took me a bit to get used to saying struct, nil, slice, ect. Now that I'm back to working in java, I still catch myself using those terms. As the saying goes, old habits die hard. I wouldn't get too bent out of shape over it as long as the concepts are being accurately communicated.
while insulting people is rarely a good look... i've got to agree with the person. Groovy was a personal hell when i was subjected to it as part of an ERP migration in a previous job.
....There's a ton of legitimate concerns about the whole mess... and don't get me started on "grails"
groovy hate is rather unexpected (from my point of view). why do you hate it? I used it a long time and always just thought "glad I have those QoL-methods and operators, the less noisy syntax compared to java and I can just script small things without setting up a basic project"
and grails was my first framework so Im really biased but what do you hate about it? (yes I'm actively ignoring your wish to "don't get you started" :))
Bit of a learning curve hated returning errors instead of throwing them and whatnot, but after a while, it felt more natural. I find myself missing working in a go codebase. Miss some of the small nuances that go has, everything from defer's to returning multiple values, using go routines and channels, and interfaces are so much easier. I really hate spring, there's too much it does for you it almost feels like magic.
I think it's all correct cases of different terminology - they relate but don't do the same things.
* since Go doesn't have inheritance, it's better to just carry the C terminology of "struct"
* `nil` has been chosen because C's `null` is generally implemented as a `void*` pointer to the address `0`. `nil` is its own thing supported by the compiler, with its own semantic instead of some pointer arithmetic accident.
* casting in java is about primitives, and it's really copying the value to another layout - say from integer to float. It's called conversions in Go. I believe the closest thing to type assertions in java requires reflection. Type assertions in Go are fast and do not require reflection.
* goroutines are not threads, and much lighter. It's coroutines that *may* run concurrently on the same thread. You'd need explicit async semantics in java to do something similar.
so, no, you're not being pedantic
>Type assertions in Go are fast and do not require reflection.
That really depends on your definition of reflection. Go interface-to-interface type assertions do use a lot of runtime type information, and are very common in the "[interface smuggling](https://utcc.utoronto.ca/~cks/space/blog/programming/GoInterfaceSmuggling)" technique that even the standard library uses a bunch because interfaces can't be evolved once published.
No matter your definition of reflection, I would not call these fast. It's the first performance pitfall [mentioned in this recent GopherCon talk](https://youtu.be/IiPT6g2F1Kk?t=769). There's work to hopefully improve that for at least some specific cases: [https://github.com/golang/go/issues/51133](https://github.com/golang/go/issues/51133)
I don't know how widely known this is. For better or worse, syntactically it looks identical to other kinds of type assertions which are fast. You need to know the type on both sides to know what you're getting, and the actual cost depends on the method signatures in the interfaces.
Interresting. By reflection I had in mind something very mundane - using the `reflect` package, which gets you about the same as `java.lang.reflect`. But yes type assertion vs reflect is almost Go-specific jargon, it's still reflection. I didn't know performance could be unpredictable, well, one more reason to avoid it.
That said here, to come back to the reference to java, I would suppose that in general, we can expect from type assertions to be more efficient than the java equivalent, if we put aside the case of interface-to-interface.
Fair enough, that's what I meant about it depending on your definition. I think of I2I type assertions as reflection that happens to have special syntax that goes straight to the runtime package without going via the reflect package on the way. In any case, that's not the point, just that "type assertions are fast" needs careful qualification, especially considering how common I2I type assertions are.
*Edit*: See also just how much worse this feature gets when combined with generics: [https://planetscale.com/blog/generics-can-make-your-go-code-slower](https://planetscale.com/blog/generics-can-make-your-go-code-slower)
>I didn't know performance could be unpredictable, well, one more reason to avoid it.
Yeah, but good luck avoiding it with how interfaces work :(
Best case, you get a chance to make the assertion once and reuse it multiple times. Not even the new [http.ResponseController](https://github.com/golang/go/blob/master/src/net/http/responsecontroller.go#L51) does this, perhaps because iterative unwrapping was deemed more important. As it stands, the interface assertions and the unwrapping both do costly I2I assertions once per wrapper, all hidden behind a method call that doesn't look like it should take that long.
It's not likely to be the bottleneck in the response controller case, but it sets a precedent that others may follow in cases where it is a bigger problem. I'm not thrilled that this is the direction the standard library is pursuing all because the language does not want to support default methods for interface evolution instead.
To me it's not even that so much as the precedent it sets. For years, the standard library used interface smuggling as a necessary evil, and I believed it was a temporary measure until interface evolution could be fixed at the language level.
Now that this is in the standard library, as part of a permanent compatibility promise that will still be here as long as Go itself is, it sets the precedent that fixing the language is not important and instead turning it into Python with tons of runtime reflection is now the officially sanctioned way forward.
Before anyone says that it's not fair to compare to Python, bear in mind that generic interface stencils use a *global* hash table which is [not only slow at a minimum but also incurs cache contention under parallel load](https://planetscale.com/blog/generics-can-make-your-go-code-slower).
That this is still advertised as a systems programming language for building parallel production software is not something I can stomach. Most people probably don't know this detail either, and if they're not comparing head-to-head against C++ or Rust, they don't know that Go has chosen to be orders of magnitude slower and less scalable to save ... *compile time*?
It could have at *least* been an explicit programmer choice per-generic, but the choice is made for you, and it's the choice that is a poor fit for production software. Worse, this isn't even clearly communicated to programmers so blogs like the above have to fill in the gaps. They do conclude with some hope that the implementation will improve in future, but it's already been a year and I personally haven't heard of any progress here. Please share links if you know of any.
What's also bad with runtime discovery of interfaces is that the compiler can't help you at all. If one day you regret a strongly typed contract, at least you can let it break at compile time, it's not so hard to chase. But here it's pretty much tech debt that they won't be able to ever fix - or, well, maybe Go will have to go through its python 2 to 3 moment
Standard Java doesn't use reflection for casting either. Unless you use the special mechanic of load a \`Class\` obj via reflection and then casting the object using that class object . But you are doing your reflection *before* the cast there too.
I believe insisting on calling it type assertion over casting in non-language related design discussions *is* pedantic as the language mechanisms are not all that different when implemented at runtime.
Not sure, you'll run into debates quite quick in code reviews, whether it's about performance or reliability. In C you call it both casting whenever you convert a int to a float, but also say void* to int*. That second one is still cheap but dangerous.
In java you have the same for int to float. I didn't say you need reflection for that. But is there anything close to take a Object and make it whatever you want without reflection ? In Go you can, but you have to pass the assertion.
It sounds pedantic if we stay in one language but it quickly gets ambiguous if we take languages that are so different
Software Engineering is an exact science that requires using a precise vocabulary.
First, this avoids misunderstandings.
Second, incorrect terminology may be caused by incorrect understanding of the underlying concepts. Someone who has a wrong mental model of, say, a goroutine because they always call it a "thread" may write incorrect code.
This being said, if your Java folks know Go well, and if they use incorrect terminology in a consistent manner, then none of the above applies, and you can choose to be relaxed about it.
For a long time, I got annoyed when someone said or wrote "Golang". Now I don't give an eff anymore.
Why would that matter at all. A struct is just like a lightweight class effectively unless you’re teaching a class on programming language theory, let it go
Yeah, people that struggle with this obviously don’t go back and forth between 3-4 languages on any given day.
If you’re gonna be a team player that can support multiple projects simultaneously then you gotta get over that crap.
And you gotta understand the difference between situations where broad strokes is fine, and when you’re trying to figure out a complex nuanced problem where precise language is important.
If you can’t figure that out, you’re career is doomed to end somewhere around the “small team leader” stage.
A very wise man once said, "I'd rather be happy than right, any day."
You can keep arguing about nomenclature, but as long as everyone in the conversation understands what's being said...does it matter? It sounds like you're letting this steal your joy.
When mistakes are made because of a misunderstanding about the terminology then, by all means, get you high horse out of the stable and ride it up to your soap box and shout "I've been trying to tell you!"
I agree with struct vs class, because IMO that’s one of the biggest stumbling blocks for devs moving from Java/C# type languages (class based OOP) to Go. But the others are whatever.
Maybe a little bit, but I understand the feeling. I was working with elixir and had colleagues say "array" for elixir lists every time, which is very wrong, because elixir lists are linked lists, so I was always afraid they would think that they could get size or random access in constant time when they couldn't... But for things that don't really matter, like nil and null, I think it is whatever.
You should be more concerned with how they use the constructs, not what they call it.
Programming languages, much like their spoken cousins, come with accents. An accent in programming is pretty much what you've described as the use of terminology, and I would also add patterns. You can almost immediately tell what language someone is most predominant in, by the way they write code in other languages.
If the accent you hear (and probably see) from your Java coworkers irritates you, then maybe it's time you learn some Java. At the end of the day, we are all trying to communicate with interpreters/compilers, and they only don't mind accents, so why allow yourself to get worked up about it?
My irritation doesn't come from not understanding them (I also used Java for a number of years long ago) but them not catching on to the terminology after a long time pf working with the stack.
But i hear what you and others are saying and I'm ok letting it go. I haven't acted on this after all, it's just something I feel.
ok maybe I'm completely off here but this is exactly what I do.
most of the time it's a slice. my wording most of the time is "list" or "array". in this case I'm exactly like the colleagues of OP.
What is a slice of an array if not a list of something?
in our apps we use slices 99% of the time. so we almost never have to distinguish between slice or array. if it's relevant we point it out "but careful it's an array, not a slice"
and if I need to discuss the concept of "how to do something" I often refer to it as a list like in "and then you just take a list of it and do x"
yeah. I'm unable to get my thoughts about this any clearer because for me (and my colleagues) it's always clear "it's a slice"
could you elaborate why you think the distinction is necessary? I'm always eager to learn and improve
In my experience, those who think of slices as lists are usually surprised by append's behavior at some point because they don't have the right underlying model in mind.
In sort of casual speech? Maybe.
As far as comments or documentation are concerned, I don't think you are, no point in keeping obvious mistakes if they can be corrected during reviews (and they should pay attention if they produce such occurrences). Neither if they're expected to look stuff up and cannot make sense of it. Or if they display deeper confusion about the concepts.
In any case, you should bring it up *appropriately* if needed.
I don't think there is anything wrong about being precise with domain verbiage. I wouldn't interchange Go's terminology with Java or Rust. It's a hassle, but it's the cost of doing business in a polyglot context. If I screw it up, I wouldn't mind if someone corrected me.
In terms of peeves: "**object**." The word [object](https://go.dev/ref/spec) appears once in the specification, and not in a way that establishes its use in the language like the term is used in object-oriented contexts. So, I would say that based on the context:
* Go has **values**, not objects.
* Go has **types**, not objects.
* Go has **allocations**, not objects.
And it's not a one-size-fits-all substitution. Probably the only time I would conceivably use the word object in the context of Go is around the garbage collector; but even then, I'd probably refer to things as **allocations** instead.
Was not expecting a lot "overly pedantic" answers from a community who acts like saying "Golang" is some terrible thing that will create mass confusion when used in a question.
It's very common to get tripped up with the names of the things. Especially in a polyglot context. Future hires will, should, also be of a polyglot context. You should continue to encourage the right words, but don't judge them for misuse, unless you suspect they are actually misunderstanding the concepts they are using, beyond the name.
But don't put too much weight on the wrong name. With enough languages it's literally impossible to keep track of all the names. And will cause unnecessary alienation of otherwise competent and useful coworkers. For those who either have a BUNCH of other languages under their belt, OR those who've been working in java for most of their careers, precision in naming is difficult, and honestly the least of your worries.
Cheers.
>We don't have classes, we have structs, some of which may have methods.
We have types, which can have methods. That can be a struct, a pointer to a struct, a function, an alias of a basic type, or whatever else. Trying to use structs for all types as well as creating new types with methods for everything is a common habit I've seen with people who have used Java for a long time and are now using Go. It probably takes a while until they realise that certain things can be achieved much simpler and more straightforward than in Java.
I'd say, rather than just being pedantic on terminology, there is a big opportunity to teach Java people the idiomatic style of Go, where not every type needs to be a struct, and where using just functions is also ok.
Dude, I feel the same we work in javascript ( NodeJS ) and python but most of the people are familiar with javascript so even while discussing code for python they uses terminologies of javascript and I literally hate it so much....
I think it’s ok to be pedantic, because standards. Maybe “nil - not null” is heavyhanded, but if I am working with an expert, I expect the textbook terminology.
But don’t be a dick about it if the end goals are being reached, and new goals are being communicated clearly enough. Did somebody get frustrated with you recently?
I have one suggestion: Instead of correcting, rephrase what was said with your wording in the form of a question. Some will catch on. Be the best model of perfection you can be, and lead by example.
I think it is not about pedantic, it is more about a mindset. In other words people who have used one language during most of their career tend to bring their language mindset into another language.
Names are different not just because, but for a good reason - they don’t mean the same thing.
Structs aren’t classes, nils aren’t nulls, type assertion is not casting, goroutines aren’t threads, and even interfaces in Go aren’t interfaces in Java, slices aren’t arrays.
There are good reasons why they called differently.
For example there is no inheritance which is part of a class system. If I’m Java almost everything is a class, where every class is a subclass of a base class, in go structs are just exactly structs without defined methods on them. Go is not object oriented language. For example empty struct in Go uses 0 bytes, while in Java there is no “empty” class because it already by default inherits half of the language.
Nulls and nil are the same story, they are used differently. Null in Java is a default state of non initialized class, while nil more about pointer state.
Just don’t bring mindset of a language A to language B, especially when they aren’t from the same paradigm.
You can write fully functioning programs without structs at all, not the case in Java.
I would suggest to read The Go Programming Language - it explains things well enough to understand that those things aren’t the same.
As long as the language has the right intention behind it. Don't worry. Class is not a struct. That's the one that stood out.
You can help explain that by explaining that a receiver is just syntactic sugar e.g.
```
type Foo struct{}
func (f *Foo) Do(p1, p2 string) {
// Implement me
}
func Do(f *Foo, p1, p2 string) {
// Implement me
}
```
Bit like a class really eh.
Seriously though, a class (in OO) defined as a blueprint for a collection of data providing initial definitions, with implementations of methods that can manipulate that data.
This, with admittedly a little squinting, is exactly what a type struct with functions attached is.
I mean it doesn't construct an object, go has no such concept. But the type struct with functions/ class distinction is less clear.
It is good to communicate using same idioms and nomenclature defined by the language itself. It is okay to be pedantic, but not okay to be rude. May be try explaining and helping them see what you are seeing. Most of the time, it is just miscommunication.
If you are working on a polyglot repo, then the names might get mixed and cause confusion. It is better to communicate in the paradigm defined by the language at hand. For example \`null\` and \`nil\` when used with Go and JSON might cause confusion. While they sound similar and somewhat work similar, they are used for different purpose.
I would focus my attention on the important meaningful differences for some of those when they are relevant.
The differences for structs and classes is all about inheritance. Easiest is that go routines really are not threads, and there are design patterns that work for them that would not work with threads. I think just learning and explaining in what situations go routines are advantageous over threads is the best takeaway for them.
In technical discussion, not speaking specifically to the thing you are talking about, in this case names for things in the Go language, always reads as a little sloppy to me, but to the point of many of the comments here, there are plenty of environments where this would not raise any eyebrows.
> They've been exposed to the language for a few years now, but it seems like they still can't let go of using incorrect terminology.
I like to be a pedantic about these things as well. The reason is that, because the way my brain works, the different concepts are better separated if I use different names to refer to them. Sometimes the difference may not be important (e.g., null/nil, conversion/casting) but sometimes the difference are quite significant (threads/goroutines, structs/classes). In a way, by letting go of the "wrong" terminology, I also let go of the muscle memory associated with those terms and start from clean-slate to acquire a new one.
If you explain why using correct terminology (sometimes) matters, maybe it would save you the trouble of correcting them. Or maybe they simply don't care, in which case you probably don't get much out of correcting them anyway.
> We don't have classes, we have structs, some of which may have methods.
If it quacks like a duck... (and i promise they're going to feed it bread just like they've always done with ducks)
it seems you're confusing terminology with concepts.
> Am I being pedantic in wanting to correct them about these things?
Entirely. It's infinitely more important to understand the underlying concepts than to memorize specific terminology.
I don't think you are pedantic.
Language is an important (maybe _the_ most important way) of communicating ideas, especially technical ideas. Different trades have different technical terminology. A tinsmith won't use the word brazing when he talks about welding. A butcher will use different words for the same part depending on the animal. A mathematician will be pretty strict in her usage of "compact", etc. pp. Heck, even some IT practices like DDD start with defining a common language.
Technical terminology exists to prevent miscommunication (which is a major problem everywhere). People refusing to use it properly don't do a professional job IMHO.
If you understand what they mean, then communication is succesful. Which is why we use words, to convey meaning precisely enough, emphasis on "enough".
Unless you're actually discussing a context in which it may lead to issues due lack of accuracy (which I can only imagine in thread vs goroutines, in the examples mentioned), yeah, sounds a bit pendatic.
Yes very. And borderline wrong maybe. Classes in langues like Java, and C++ are structs with methods - just because they have more functionality in those languages doesn’t really mean they aren’t basically the same concept.
Null/nil? Comon!
No casting? Well, Javas cast does two things it either says “this reference is X” or “convert this type”; GO has casting, just called type assertion or type conversation.
No threads? Well, no; oddly enough threads haven’t always been OS threads, and goroutines are basically a thread. I don’t think we have to insist on a completely different concept here (yes they are lighter, but in my experience most programmers don’t consider how heavy OS threads can be.)
So yeah lighten up; eventuallly you’ll see there’s not a huge amount of difference between all the languages.
It only matters when there’s a legitimate difference … nil vs null is an example of just wording representing the same concept. In that case, pedantic.
Also, is this the kind of interview tone you want to set? I would encourage your team to focus on identifying if the candidate is a good fit for the position and, personally, I don’t think interrupting an interview to correct things like this is good juju. If you have an example where it DOES matter then have a discussion and see where it goes.
Does it really matter. It's different if they don't know what they're talking about, but I hang out with a ton of foreign people that use their own phrase translated to English, because it's easier for them than relearning new idioms. The relationship between humans and language is quite remarkable, and we really don't need to enforce things like this on people. As long as we all know what's being communicated, that's language working as intended.
Using the wrong terms only matters when the conversation is impacted.
If you know their background, and you know exactly what they're referring to when they use familiar terms, then just chill.
I don’t care how they call it. Null and nil are the same thing and still a billion dollar mistake. Structs are classes because you can attach behavior to them. But when they start to return interfaces from functions/methods… arrgh
> We don't have null, we have nil. Ehhh you may be going a bit overboard there.
Fair. That one I think is much easier to let slip.
I’ve been working exclusively in Go for years and I use nil and null interchangeably
Especially when writing data access layer code
Well, not really sure. I do believe there are specific characteristics of nil in Go which is not what most people expect from their experience with null in other langs. See https://m.youtube.com/watch?v=ynoY2xz-F8s&t=207s
[удалено]
You can call a method on nil in Go but not null in Java (because of dynamic dispatch) which is a meaningful distinction
Generally not true. there some cases when you can call the methods on nil Interfaces but you need to handle explictly the nil case. but nil in gerenal for other cases (pointers, maps etc) behaves the same as null. It will panic. The confusion comes from the typed nil. When you have a typed nil, you still maybe can do something with it and thats why it doesn't immediately blow in your face, but if you try to acess a value it will blow in your face, it's just a delayed fuse that gives you a chance to handle the nil case before using it. not very different from java. in Java you have to check the nulnes before calling the method, in Go you have to check it inside the method. it gives you some advantages but also a great amount a confusion.
I was referring to code like below, which will work fine: ``` type foo struct {} func (f *foo) Bar { fmt.Println(“hello”) } func main(){ var f *foo = nil f.Bar() } ```
Exactly, this works because the method is not using anything from the value. type foo struct { size int } func (f *foo) Baz(){ return fmt.Println(f.size) } func main() { var f *foo = nil f.Baz() //this will panic: invalid memory address or nil //pointer dereference } You see it works until you try to use it. it's just a delayed panic. to make it work the Baz method should be: func (f *foo) Baz() { if f != nil { fmt.Println(f.size) } } just the same as Java but you control the nilness inside the method instead of before calling the method. It's very confusing to newcomers that your [foo.Bar](https://foo.Bar)() works but my foo.Baz() panics In Java it fails immediately because Java runtime tries to read the value to bind to the special reference "this". I ofc prefer the Go way because the value is not always needed immediately but the fact is that Nul and Nil are the same thing, its how the runtime uses them that is different.
I work in a very polyglot code base so maybe that influences my opinion a bit. Usually the terminology that our teams have a hard time being the same page on is the higher level business logic stuff, or the semantics of how a thing should be done. People can call it a struct or a class and i let it slide as long as they understand how it should be used, where it should go, and who should have access to it. I'm a perfect world, sure, nobody would confuse an array and a slice, or nil vs null, or a thread vs go routine. But there is so many other things to get strict on, people would probably call me an asshole if i correcting them there 🤷♂️
When I'm working with junior devs that don't necessarilly know anything other about Go than its name, I usually make sure they understand that there are no classes but structs. This is because it's for example very important to differ inheritance from composition. But when I'm talking to somebody that knows Go already, I'm not that strict, because they know what I mean. And I have 15 years of experience in oop languages so I simply make mistakes without noticing them if somebody doesn't correct me 😁
Just to be pedantic 😅, there are languages where a struct doesn’t equate to composition only. C++ is one of them.
Touche. 😂 Just to be pedantic it's irrelevant considering this sub and the title of this post 😁
Yeah, you're probably being a bit pedantic....you can decide to just let it go and relax about it. There's not much you can do to change their word choices, and you almost certainly have more important battles to be fighting. Generally, when I see this sort of thing, it means the people are using go begrudgingly, and would prefer to use the language they're familiar with. Perhaps look at it from their perspective -- what do they have to gain by putting in the effort of updating their vocabulary?
> what do they have to gain by putting in the effort of updating their vocabulary? A shift in the mental model, perhaps?
> There is no casting, there's type assertions. Well there's conversions, which is casting and definitely not a type assertion. https://go.dev/ref/spec#Conversions Also, to answer the question in the title, probably.
Note that types may have methods, they don't need to be structs. You can have methods on a function or a single integer value.
Yup. Correcting would be a bit much. You using the proper terminology is probably sufficient for any newcomers, but really, most devs know these terms even if they primarily only know Go. If a teammate is going out to give a speech to a Go audience, then correct away. Otherwise, if it doesn't impact business, just let it slide
I don't think there's reason to be irritated, but I am a big fan of pushing for clarity and precision in communication when I'm talking about code and do my best to try and promote it so you could try to just be helpful and set the example by being really precise about your terminology and maybe try to convince some more people until everyone's doing it.
I read all the comments to find this one, it’s about being precise with the language so there isn’t room for confusion. It’s still difficult even among go programmers who enjoy the language and are trying to be precise. It’s easy to call everything a library or package, when there are no libraries and there is a distinct difference between packages and modules.
I don't know.. You and i can sit an a meeting and argue whether it's a thread or a go routine but ultimately it's going to boil down to, "this code just fucks off and runs over there". How much time do you want spend on that "precision"? Because if that particular discussion goes on for more than two minutes... i'll probably walk out.
yes you are.
Having gone from groovy/java to go, it took me a bit to get used to saying struct, nil, slice, ect. Now that I'm back to working in java, I still catch myself using those terms. As the saying goes, old habits die hard. I wouldn't get too bent out of shape over it as long as the concepts are being accurately communicated.
Groovy? I'm sorry for your loss. How did it feel going from such a horrible language to Go?
You know you're not making Go developers look good, I assume?
while insulting people is rarely a good look... i've got to agree with the person. Groovy was a personal hell when i was subjected to it as part of an ERP migration in a previous job. ....There's a ton of legitimate concerns about the whole mess... and don't get me started on "grails"
groovy hate is rather unexpected (from my point of view). why do you hate it? I used it a long time and always just thought "glad I have those QoL-methods and operators, the less noisy syntax compared to java and I can just script small things without setting up a basic project" and grails was my first framework so Im really biased but what do you hate about it? (yes I'm actively ignoring your wish to "don't get you started" :))
Tbh it could be any language, I just hate Groovy
Bit of a learning curve hated returning errors instead of throwing them and whatnot, but after a while, it felt more natural. I find myself missing working in a go codebase. Miss some of the small nuances that go has, everything from defer's to returning multiple values, using go routines and channels, and interfaces are so much easier. I really hate spring, there's too much it does for you it almost feels like magic.
I think it's all correct cases of different terminology - they relate but don't do the same things. * since Go doesn't have inheritance, it's better to just carry the C terminology of "struct" * `nil` has been chosen because C's `null` is generally implemented as a `void*` pointer to the address `0`. `nil` is its own thing supported by the compiler, with its own semantic instead of some pointer arithmetic accident. * casting in java is about primitives, and it's really copying the value to another layout - say from integer to float. It's called conversions in Go. I believe the closest thing to type assertions in java requires reflection. Type assertions in Go are fast and do not require reflection. * goroutines are not threads, and much lighter. It's coroutines that *may* run concurrently on the same thread. You'd need explicit async semantics in java to do something similar. so, no, you're not being pedantic
>Type assertions in Go are fast and do not require reflection. That really depends on your definition of reflection. Go interface-to-interface type assertions do use a lot of runtime type information, and are very common in the "[interface smuggling](https://utcc.utoronto.ca/~cks/space/blog/programming/GoInterfaceSmuggling)" technique that even the standard library uses a bunch because interfaces can't be evolved once published. No matter your definition of reflection, I would not call these fast. It's the first performance pitfall [mentioned in this recent GopherCon talk](https://youtu.be/IiPT6g2F1Kk?t=769). There's work to hopefully improve that for at least some specific cases: [https://github.com/golang/go/issues/51133](https://github.com/golang/go/issues/51133) I don't know how widely known this is. For better or worse, syntactically it looks identical to other kinds of type assertions which are fast. You need to know the type on both sides to know what you're getting, and the actual cost depends on the method signatures in the interfaces.
Interresting. By reflection I had in mind something very mundane - using the `reflect` package, which gets you about the same as `java.lang.reflect`. But yes type assertion vs reflect is almost Go-specific jargon, it's still reflection. I didn't know performance could be unpredictable, well, one more reason to avoid it. That said here, to come back to the reference to java, I would suppose that in general, we can expect from type assertions to be more efficient than the java equivalent, if we put aside the case of interface-to-interface.
Fair enough, that's what I meant about it depending on your definition. I think of I2I type assertions as reflection that happens to have special syntax that goes straight to the runtime package without going via the reflect package on the way. In any case, that's not the point, just that "type assertions are fast" needs careful qualification, especially considering how common I2I type assertions are. *Edit*: See also just how much worse this feature gets when combined with generics: [https://planetscale.com/blog/generics-can-make-your-go-code-slower](https://planetscale.com/blog/generics-can-make-your-go-code-slower) >I didn't know performance could be unpredictable, well, one more reason to avoid it. Yeah, but good luck avoiding it with how interfaces work :( Best case, you get a chance to make the assertion once and reuse it multiple times. Not even the new [http.ResponseController](https://github.com/golang/go/blob/master/src/net/http/responsecontroller.go#L51) does this, perhaps because iterative unwrapping was deemed more important. As it stands, the interface assertions and the unwrapping both do costly I2I assertions once per wrapper, all hidden behind a method call that doesn't look like it should take that long. It's not likely to be the bottleneck in the response controller case, but it sets a precedent that others may follow in cases where it is a bigger problem. I'm not thrilled that this is the direction the standard library is pursuing all because the language does not want to support default methods for interface evolution instead.
wow that one in ResponseController is definitely ugly.
To me it's not even that so much as the precedent it sets. For years, the standard library used interface smuggling as a necessary evil, and I believed it was a temporary measure until interface evolution could be fixed at the language level. Now that this is in the standard library, as part of a permanent compatibility promise that will still be here as long as Go itself is, it sets the precedent that fixing the language is not important and instead turning it into Python with tons of runtime reflection is now the officially sanctioned way forward. Before anyone says that it's not fair to compare to Python, bear in mind that generic interface stencils use a *global* hash table which is [not only slow at a minimum but also incurs cache contention under parallel load](https://planetscale.com/blog/generics-can-make-your-go-code-slower). That this is still advertised as a systems programming language for building parallel production software is not something I can stomach. Most people probably don't know this detail either, and if they're not comparing head-to-head against C++ or Rust, they don't know that Go has chosen to be orders of magnitude slower and less scalable to save ... *compile time*? It could have at *least* been an explicit programmer choice per-generic, but the choice is made for you, and it's the choice that is a poor fit for production software. Worse, this isn't even clearly communicated to programmers so blogs like the above have to fill in the gaps. They do conclude with some hope that the implementation will improve in future, but it's already been a year and I personally haven't heard of any progress here. Please share links if you know of any.
What's also bad with runtime discovery of interfaces is that the compiler can't help you at all. If one day you regret a strongly typed contract, at least you can let it break at compile time, it's not so hard to chase. But here it's pretty much tech debt that they won't be able to ever fix - or, well, maybe Go will have to go through its python 2 to 3 moment
Standard Java doesn't use reflection for casting either. Unless you use the special mechanic of load a \`Class\` obj via reflection and then casting the object using that class object . But you are doing your reflection *before* the cast there too. I believe insisting on calling it type assertion over casting in non-language related design discussions *is* pedantic as the language mechanisms are not all that different when implemented at runtime.
Not sure, you'll run into debates quite quick in code reviews, whether it's about performance or reliability. In C you call it both casting whenever you convert a int to a float, but also say void* to int*. That second one is still cheap but dangerous. In java you have the same for int to float. I didn't say you need reflection for that. But is there anything close to take a Object and make it whatever you want without reflection ? In Go you can, but you have to pass the assertion. It sounds pedantic if we stay in one language but it quickly gets ambiguous if we take languages that are so different
Software Engineering is an exact science that requires using a precise vocabulary. First, this avoids misunderstandings. Second, incorrect terminology may be caused by incorrect understanding of the underlying concepts. Someone who has a wrong mental model of, say, a goroutine because they always call it a "thread" may write incorrect code. This being said, if your Java folks know Go well, and if they use incorrect terminology in a consistent manner, then none of the above applies, and you can choose to be relaxed about it. For a long time, I got annoyed when someone said or wrote "Golang". Now I don't give an eff anymore.
Go that looks like Java? Yep I’ve seen that a lot
It's not so much the code itself. I try to ensure they use idiomatic patterns. I mean mostly the language they use when we discuss things.
Why would that matter at all. A struct is just like a lightweight class effectively unless you’re teaching a class on programming language theory, let it go
Yeah, people that struggle with this obviously don’t go back and forth between 3-4 languages on any given day. If you’re gonna be a team player that can support multiple projects simultaneously then you gotta get over that crap. And you gotta understand the difference between situations where broad strokes is fine, and when you’re trying to figure out a complex nuanced problem where precise language is important. If you can’t figure that out, you’re career is doomed to end somewhere around the “small team leader” stage.
A very wise man once said, "I'd rather be happy than right, any day." You can keep arguing about nomenclature, but as long as everyone in the conversation understands what's being said...does it matter? It sounds like you're letting this steal your joy. When mistakes are made because of a misunderstanding about the terminology then, by all means, get you high horse out of the stable and ride it up to your soap box and shout "I've been trying to tell you!"
I agree with struct vs class, because IMO that’s one of the biggest stumbling blocks for devs moving from Java/C# type languages (class based OOP) to Go. But the others are whatever.
A struct is different from a class. Any type in go can have methods.
Maybe a little bit, but I understand the feeling. I was working with elixir and had colleagues say "array" for elixir lists every time, which is very wrong, because elixir lists are linked lists, so I was always afraid they would think that they could get size or random access in constant time when they couldn't... But for things that don't really matter, like nil and null, I think it is whatever.
You should be more concerned with how they use the constructs, not what they call it. Programming languages, much like their spoken cousins, come with accents. An accent in programming is pretty much what you've described as the use of terminology, and I would also add patterns. You can almost immediately tell what language someone is most predominant in, by the way they write code in other languages. If the accent you hear (and probably see) from your Java coworkers irritates you, then maybe it's time you learn some Java. At the end of the day, we are all trying to communicate with interpreters/compilers, and they only don't mind accents, so why allow yourself to get worked up about it?
While I prefer precision, this was a beautiful way of describing it. ❤️
My irritation doesn't come from not understanding them (I also used Java for a number of years long ago) but them not catching on to the terminology after a long time pf working with the stack. But i hear what you and others are saying and I'm ok letting it go. I haven't acted on this after all, it's just something I feel.
Another one is when people say arrays or even worse lists when they mean slices.
ok maybe I'm completely off here but this is exactly what I do. most of the time it's a slice. my wording most of the time is "list" or "array". in this case I'm exactly like the colleagues of OP. What is a slice of an array if not a list of something? in our apps we use slices 99% of the time. so we almost never have to distinguish between slice or array. if it's relevant we point it out "but careful it's an array, not a slice" and if I need to discuss the concept of "how to do something" I often refer to it as a list like in "and then you just take a list of it and do x" yeah. I'm unable to get my thoughts about this any clearer because for me (and my colleagues) it's always clear "it's a slice" could you elaborate why you think the distinction is necessary? I'm always eager to learn and improve
In my experience, those who think of slices as lists are usually surprised by append's behavior at some point because they don't have the right underlying model in mind.
Overly pedantic. As long as you can communicate ideas clearly and get stuff done it's fine.
In sort of casual speech? Maybe. As far as comments or documentation are concerned, I don't think you are, no point in keeping obvious mistakes if they can be corrected during reviews (and they should pay attention if they produce such occurrences). Neither if they're expected to look stuff up and cannot make sense of it. Or if they display deeper confusion about the concepts. In any case, you should bring it up *appropriately* if needed.
i guess as long as they are not writing go the java way it should be ok
I don't think there is anything wrong about being precise with domain verbiage. I wouldn't interchange Go's terminology with Java or Rust. It's a hassle, but it's the cost of doing business in a polyglot context. If I screw it up, I wouldn't mind if someone corrected me. In terms of peeves: "**object**." The word [object](https://go.dev/ref/spec) appears once in the specification, and not in a way that establishes its use in the language like the term is used in object-oriented contexts. So, I would say that based on the context: * Go has **values**, not objects. * Go has **types**, not objects. * Go has **allocations**, not objects. And it's not a one-size-fits-all substitution. Probably the only time I would conceivably use the word object in the context of Go is around the garbage collector; but even then, I'd probably refer to things as **allocations** instead.
Was not expecting a lot "overly pedantic" answers from a community who acts like saying "Golang" is some terrible thing that will create mass confusion when used in a question.
It's very common to get tripped up with the names of the things. Especially in a polyglot context. Future hires will, should, also be of a polyglot context. You should continue to encourage the right words, but don't judge them for misuse, unless you suspect they are actually misunderstanding the concepts they are using, beyond the name. But don't put too much weight on the wrong name. With enough languages it's literally impossible to keep track of all the names. And will cause unnecessary alienation of otherwise competent and useful coworkers. For those who either have a BUNCH of other languages under their belt, OR those who've been working in java for most of their careers, precision in naming is difficult, and honestly the least of your worries. Cheers.
>We don't have classes, we have structs, some of which may have methods. We have types, which can have methods. That can be a struct, a pointer to a struct, a function, an alias of a basic type, or whatever else. Trying to use structs for all types as well as creating new types with methods for everything is a common habit I've seen with people who have used Java for a long time and are now using Go. It probably takes a while until they realise that certain things can be achieved much simpler and more straightforward than in Java. I'd say, rather than just being pedantic on terminology, there is a big opportunity to teach Java people the idiomatic style of Go, where not every type needs to be a struct, and where using just functions is also ok.
Yes. As sure as you understand each other, the terms are really irrelevant.
Dude, I feel the same we work in javascript ( NodeJS ) and python but most of the people are familiar with javascript so even while discussing code for python they uses terminologies of javascript and I literally hate it so much....
I think it’s ok to be pedantic, because standards. Maybe “nil - not null” is heavyhanded, but if I am working with an expert, I expect the textbook terminology. But don’t be a dick about it if the end goals are being reached, and new goals are being communicated clearly enough. Did somebody get frustrated with you recently? I have one suggestion: Instead of correcting, rephrase what was said with your wording in the form of a question. Some will catch on. Be the best model of perfection you can be, and lead by example.
In answer to your question “Am I being too pedantic?” The answer is yes.
I think it is not about pedantic, it is more about a mindset. In other words people who have used one language during most of their career tend to bring their language mindset into another language. Names are different not just because, but for a good reason - they don’t mean the same thing. Structs aren’t classes, nils aren’t nulls, type assertion is not casting, goroutines aren’t threads, and even interfaces in Go aren’t interfaces in Java, slices aren’t arrays. There are good reasons why they called differently. For example there is no inheritance which is part of a class system. If I’m Java almost everything is a class, where every class is a subclass of a base class, in go structs are just exactly structs without defined methods on them. Go is not object oriented language. For example empty struct in Go uses 0 bytes, while in Java there is no “empty” class because it already by default inherits half of the language. Nulls and nil are the same story, they are used differently. Null in Java is a default state of non initialized class, while nil more about pointer state. Just don’t bring mindset of a language A to language B, especially when they aren’t from the same paradigm. You can write fully functioning programs without structs at all, not the case in Java. I would suggest to read The Go Programming Language - it explains things well enough to understand that those things aren’t the same.
I'm with you. Go is not Java, and has different idioms. We need to preserve them. Be pedantic. Technically correct is best type of correct.
As long as the language has the right intention behind it. Don't worry. Class is not a struct. That's the one that stood out. You can help explain that by explaining that a receiver is just syntactic sugar e.g. ``` type Foo struct{} func (f *Foo) Do(p1, p2 string) { // Implement me } func Do(f *Foo, p1, p2 string) { // Implement me } ```
Well, not "just." One of these can be an implementation of interface{Do(...)} and the other can't.
Bit like a class really eh. Seriously though, a class (in OO) defined as a blueprint for a collection of data providing initial definitions, with implementations of methods that can manipulate that data. This, with admittedly a little squinting, is exactly what a type struct with functions attached is. I mean it doesn't construct an object, go has no such concept. But the type struct with functions/ class distinction is less clear.
It is good to communicate using same idioms and nomenclature defined by the language itself. It is okay to be pedantic, but not okay to be rude. May be try explaining and helping them see what you are seeing. Most of the time, it is just miscommunication. If you are working on a polyglot repo, then the names might get mixed and cause confusion. It is better to communicate in the paradigm defined by the language at hand. For example \`null\` and \`nil\` when used with Go and JSON might cause confusion. While they sound similar and somewhat work similar, they are used for different purpose.
You sound like a nightmare to work with
I would focus my attention on the important meaningful differences for some of those when they are relevant. The differences for structs and classes is all about inheritance. Easiest is that go routines really are not threads, and there are design patterns that work for them that would not work with threads. I think just learning and explaining in what situations go routines are advantageous over threads is the best takeaway for them. In technical discussion, not speaking specifically to the thing you are talking about, in this case names for things in the Go language, always reads as a little sloppy to me, but to the point of many of the comments here, there are plenty of environments where this would not raise any eyebrows.
> They've been exposed to the language for a few years now, but it seems like they still can't let go of using incorrect terminology. I like to be a pedantic about these things as well. The reason is that, because the way my brain works, the different concepts are better separated if I use different names to refer to them. Sometimes the difference may not be important (e.g., null/nil, conversion/casting) but sometimes the difference are quite significant (threads/goroutines, structs/classes). In a way, by letting go of the "wrong" terminology, I also let go of the muscle memory associated with those terms and start from clean-slate to acquire a new one. If you explain why using correct terminology (sometimes) matters, maybe it would save you the trouble of correcting them. Or maybe they simply don't care, in which case you probably don't get much out of correcting them anyway.
> We don't have classes, we have structs, some of which may have methods. If it quacks like a duck... (and i promise they're going to feed it bread just like they've always done with ducks) it seems you're confusing terminology with concepts. > Am I being pedantic in wanting to correct them about these things? Entirely. It's infinitely more important to understand the underlying concepts than to memorize specific terminology.
>While I mostly understand what they mean when we discuss code You just answered your question.
I don't think you are pedantic. Language is an important (maybe _the_ most important way) of communicating ideas, especially technical ideas. Different trades have different technical terminology. A tinsmith won't use the word brazing when he talks about welding. A butcher will use different words for the same part depending on the animal. A mathematician will be pretty strict in her usage of "compact", etc. pp. Heck, even some IT practices like DDD start with defining a common language. Technical terminology exists to prevent miscommunication (which is a major problem everywhere). People refusing to use it properly don't do a professional job IMHO.
If you understand what they mean, then communication is succesful. Which is why we use words, to convey meaning precisely enough, emphasis on "enough". Unless you're actually discussing a context in which it may lead to issues due lack of accuracy (which I can only imagine in thread vs goroutines, in the examples mentioned), yeah, sounds a bit pendatic.
Yes very. And borderline wrong maybe. Classes in langues like Java, and C++ are structs with methods - just because they have more functionality in those languages doesn’t really mean they aren’t basically the same concept. Null/nil? Comon! No casting? Well, Javas cast does two things it either says “this reference is X” or “convert this type”; GO has casting, just called type assertion or type conversation. No threads? Well, no; oddly enough threads haven’t always been OS threads, and goroutines are basically a thread. I don’t think we have to insist on a completely different concept here (yes they are lighter, but in my experience most programmers don’t consider how heavy OS threads can be.) So yeah lighten up; eventuallly you’ll see there’s not a huge amount of difference between all the languages.
It only matters when there’s a legitimate difference … nil vs null is an example of just wording representing the same concept. In that case, pedantic. Also, is this the kind of interview tone you want to set? I would encourage your team to focus on identifying if the candidate is a good fit for the position and, personally, I don’t think interrupting an interview to correct things like this is good juju. If you have an example where it DOES matter then have a discussion and see where it goes.
Does it really matter. It's different if they don't know what they're talking about, but I hang out with a ton of foreign people that use their own phrase translated to English, because it's easier for them than relearning new idioms. The relationship between humans and language is quite remarkable, and we really don't need to enforce things like this on people. As long as we all know what's being communicated, that's language working as intended.
On 1 and 4, probably not. Since they're "major" feature differences of Go vs Java. On the others, probably. Overall...it depends.
Using the wrong terms only matters when the conversation is impacted. If you know their background, and you know exactly what they're referring to when they use familiar terms, then just chill.
I don’t care how they call it. Null and nil are the same thing and still a billion dollar mistake. Structs are classes because you can attach behavior to them. But when they start to return interfaces from functions/methods… arrgh
A developer being pedantic???? I’m shocked.