encoding/json unmarshal's missing JSON properties to their 0 values almost 4 years after people have asked for a fix. The alternative can possibly lead to null point dereference unless if you write a recursive checker.
No. It's a terrible language. It lacks metaclasses, macros, has shit typing (still), and it has zero utility outside of unix daemons or web services with mediocre requirements.
Its GC has been improved, and it's a usable tool.
But decent is pushing it; even Gogen is worse than C's preprocessor.
If you want decent, you want Clojure. Scala. Kotlin. C#. Even fucking Ruby is decent, despite its downfall in the last recent years. Erlang is decent. Fuck, even C is decent. Perl.
If you want good: C++, Haskell, Common Lisp, Ada, OCaml, Prolog, and others from the same arenas.
Aside from that, forget it.
Scalability is measured by one's ability to leverage good tools while striking a balance between maintainability and extensibility. Go has neither, generics or not.
Shoving if err != nil down your throat isn't the way to go about it.
Go belongs in the dustbin of Java, PHP, Python, JavaScript, and other horrors we've had to endure over the past 30 years.
You can complain a lot about Go but lack of these is actually an advantage of Go. Macros and metaclasses are the fastest way to make your code an unreadable mess.
even Gogen is worse than C's preprocessor
Do you mean go generate? Go was not designed to use a preprocessor like most other languages. Go generate is the tool of last resort and almost nobody uses it because there is no need for it.
striking a balance between maintainability and extensibility
I've been working for years on backend services in Java, Python, NodeJS, and PHP. None of them even come close to Go. The language and libraries are extremely stable, and applications written in it require almost no maintenance.
Shoving if err != nil down your throat isn't the way to go about it.
At every company I worked at, we always had a lot of unhandled exceptions because someone didn't know that some method could throw it. This occasionally caused bugs because some routines were interrupted in an unexpected place. On the other hand, I've never seen a similar problem with any Go service because Go forces you to think about how to handle errors. It's also easier to analyze it during code review. Does it require more work? Sure, but in the end we get better code.
You can complain a lot about Go but lack of these is actually an advantage of Go.
Oh gosh, here we go again. Another "Go does not support anything BUT its an advantage", fanboyism to the extreme.
These are the same people who complain about even trivial things missing from Typescript, Python, Java, C# but when it comes to GO everything is fine regardless of how many missing things it has.
It's just is crazy that the moment there is a "google" tag dev's are ready to adopt even a garbage practice as "best practice".
Oh gosh, here we go again. Another "Go does not support anything BUT its an advantage", fanboyism to the extreme.
It's not fanboyism, it's 15 years of experience in professional programming. Only young programmers think a language with more features is a better language. The more experienced have learned lessons from the mistakes made by JavaScript or latest versions of C++.
I used to work as a software architect for years, and one of the things that every software architect tries to enforce in a team is to force developers to write simple code without using all those cool features. Have you ever heard of Value Objects? POJO/POPO? Composition? Functional programming? You know, all those cool design pattern that are basically a return to the roots when programming languages were simple. Sometimes I think half the job of a software architect is to convince young programmers that complex code that uses the latest and coolest features of a language is not good code.
These are the same people who complain about even trivial things missing from Typescript, Python, Java, C# but when it comes to GO everything is fine regardless of how many missing things it has.
Only young programmers think a language with more features is a better language.
Said nobody except developers who don't know how it help in creating better abstraction, design patterns, error handling, understandable code. Remember, the use case WILL not go away and because the language does not provide good tools to solve those the complexity of handling them is shifted from language to the user code (and even that also does not always works due to limited type system). This goes against DRY coding principles and a mess of code.
The more experienced have learned lessons from the mistakes made by JavaScript or latest versions of C++.
Again, completely incorrect (looks like you are just throwing any reasoning which might stick).
ALL modern Languages are SIGNIFICANTLY better than GO and have all/most of the tools one needs to craft great code. Rust (much bigger than GO feature set and universally loved and adopted at alarming rate EVERYWHERE), Kotlin, Typescript (fabulous type system which makes up for some beautiful design patterns and strong typing at compile time), Javascript (ES6 to 2022 are awesome adding so many capabilities), .Net core. Just name one mainstream language which is as poorly designed as GO which supports so few things?
Its common sense that if your language support so few things which ARE necessary to write code then how is that a good thing.
Developers like you only said that even generics are NOT necessary just because GO didn't want to support it and after 10 long years GO team finally added half baked generics (like everything else in GO). Will you now challenge that GO team was wrong because they added Generics and increased surface area of language? GO team has been slowly bringing commonsense features which have existed in so many languages since decades 10+ years later because they get SO MANY complaints and even realize that it is not a desirable language that way. Where are developers like you when they add more things (exact same which existed in other languages).
Go does not even support sum/union types which is crazy. How does one program without that and write a code which can express those things and enforce eloquently?
Javascript/Typescript are FAR more pleasurable languages to work compared to GO. Even Dart, kotlin, Rust are beautifully designed. GO is ugly, limiting and the type system is NOT at all expressive.
GO team is lucky to have supporters like you who think getting much less support, even necessary thing is better. Hardly any language is trying to emulate Go.
Said nobody except developers who don't know how it help in creating better abstraction, design patterns, error handling, understandable code.
Of course. I've been working as a software architect without knowing it.
Can you share a link to your GitHub profile? I'm carious how your understandable code looks like. You can easily find mine.
Typescript (fabulous type system which makes up for some beautiful design patterns and strong typing at compile time), Javascript (ES6 to 2022 are awesome adding so many capabilities)
You must be trolling.
Rust (much bigger than GO feature set and universally loved and adopted at alarming rate EVERYWHERE) ... Go does not even support sum/union types which is crazy. How does one program without that and write a code which can express those things and enforce eloquently?
But did you know that the authors of Rust have similar views on OOP as the authors of Go? Rust supports similar subset of OOP as Go. Rust also doesn't have exceptions like Go. Even more, Rust doesn't have unions too! Crazy, huh? Just like Go, Rust supports very few features compared to Java, Kotlin, C++ or TypeScript because this is how modern languages should look like, not like another Java.
Enum, pattern matching and macros are the only big features that Rust has and Go doesn't.
You haven't even opened the Rust documentation.
Edit: Oh wow, you blocked me, so now I can't respond. I didn't write anything that could have offended you and the discussion was civil, so I guess you ran out of arguments.
Of course. I was hired as a software architect without knowing it.
The thing is to have been boasting about how "you are an architect" and how "you have 15 years of experience". The inherently don't add value to discussion abd you should let your points do the talking. For what is worth it, I have more experience than you number of years wise but that does not make one better or worse developer, understanding of concepts does.
You must be trolling
I honestly feel that about you because of your arguments which makes no sense. You are advocating for not having useful features in language hoping that the usecase for them will go away simply because the language does not support it. It's crazy.
But did you know that the authors of Rust have similar views on OOP as the authors of Go
Hardly answering and overlooking the fact that Rust has LOT of features backed in the language with a very powerful type system.
Honestly you answered none of the points I have raised except "you have 15 years of experience" or "you are an architect so you know better" type useless arguments.
Dude Rust is too intelligent for the average developer, companies dont want to pay for geniuses so languages like Go are pushed cause they are boring to write but very easy to read.
I picked up Go a few months ago and was ENTIRELY unaware of this until Tuesday. Spent like an hour trying to figure out why my response's data in a test was incorrect, turns out I had a typo in my JSON tag.
The fact this isn't an error is unbelievable to me, the collective hours of developers debugging issues just because of JSON struct tag typos must be in the hundreds.
I kept tabs on Golang as one of these "maybe if I got time for it" languages. But every time I actually learn something about it it's weird. Like the error handling or the details of the new generics system. And now this.
I still have no idea what this language is actually for. It seems that both the system/performance case and the high level safe niches are better served by other languages.
My impression of Go is a language that assumes you're to dumb to grasp some advanced concepts so your code ends up being a lot of simple statements, but also much longer.
With that said, at the end of the day I'm still reaching out for it for a lot of things because:
It's fast enough and faster than python
There's a pretty large ecosystem of libraries for what I usually want to do
I can be productive enough in it.
That's it. If they fixed the closure inlining performance issue with generics that'd be pretty dope because I can't stand writing for loops just to check membership or filtering slices.
(also if they could add sum types and pattern matching that'd be great too)
That's a pretty flawed comparison, considering the V8 engine is probably one of the most optimized and insane pieces of magic in the world, and the Python interpreter is a hot bag of melted candlewax and tragedy.
So how is it flawed? OP was right when they said JS is faster than python and all you said was "because v8 is heavily optimised" which basically proves OP's point. You are confusing for no reason
Also, who goes around replying to year-old comments, lol?
What has the "why did you reply on 1 year old comment" got to do? You know that the comments on reddit are forever so people stumbling on it can comment on it whenever they want, so?
people stumbling on it can comment on it whenever they want
Actually, no: most subs have archive mode set around 6 months. I'm well-aware of how Reddit works.
That doesn't change the fact that you somehow managed to find this thread (which was by no means a big deal) and then specifically singled out my comment for your need to call someone "confusing for no reason".
So yeah...it's a little strange that you'd end up here, commenting at me, while apparently unable to understand simple English in common usage.
I have never met a bigger cry baby than you on reddit abbas that is not that difficult given we are on reddit haha.
Lol you MOST reddit (even 10 years old) don't archive unless the admin does so looks like you don't know what you are taking about and the fact that I (and anyone) can comment here is a proof which most people know anyways.
May be good to get off reddit if you are afraid of people calling or your BS given how easily you cry and resort to personal attack Sheff ruffled some feathers lol.
You really need to have a checkup for yourself if you enjoy being "subjected" to read GO code and that you still enjoy it.
GO is absolutely an unreadable mess especially mix of pointer/non pointer, interface{} littered everywhere, no sum types, no discriminated unions, not possible to create a new struct by picking keys from old struct, not possible to highlight optional field in JSON struct, JSON struct tags within string is a recipe of disaster as you won't get any auto code completion there, JSON data validation/json tags/optional fields/multi value struct fields is a nightmare to read and maintain in GO, implicit interface, magic init function etc. the list goes on and on.
Honestly except concurrency, everything else is pure inconvenience in GO.
I have to use golang for a client, so I've been using it now for about 5 months. Coming from C#, where we have had templates classes for ages...so I started using these 'generics'....oh boy, much room for improvement there. And sorry to say, but the community is quite toxic. A bunch of hipsters who probably only dig apple products but chose golang by Google because it is trendy. Application Architecture? Application composition? They whine "hey, you're not doing idiomatic golang!" Biatch, software engineering is applied mathematics and in mathematics, if you encounter the need for a new concept, you define it!
So why use golang? A hybrid between FP and OOP...concurrency? Don't make me laugh! If you are serious about concurrency, go for erlang/OTP. Much nicer community too.
I agree with everything you said. I use go because it relatively fast and low memory consumption. I should be able to carry a decent workload on smaller hardware, and therefore pay less money to make money.
5-6 years ago, I wrote quite a large service in Go, mostly using the standard library. Today, I can run this project on the fly and continue working on it with the latest Go without any changes.Which language has such a feature?
Which language allows you to successfully implement a project relying only on the STD? Most of the solutions praised here for a simple project generate so many files that I'm overwhelmed right from the start.
Most of the solutions and components praised here that are part of a
given project will undergo so many different changes that updating such a
project alone involves a lot of energy and frustration.
Imagine if you will, a guy that uses the butt end of his screwdriver to drive a nail into a board. That guy probably didn't have a good time, but the guy didn't know any better because the screwdriver is the only tool he owns. Maybe he didn't a hammer even existed. The packaging definitely wasn't clear about it not being suitable for the job either, he just saw some other guy using it that way one day. It worked fine enough, so he hasn't questioned it to this day.
I think it's naive to think one language is going to be able to everything you want. Complaints I've seen tend to gloss over design limitations that may exist in their language of choice. Go really sucks to use outside of distributed systems that scale horizontally, it shares characteristic traits with Java, like having a heap and garbage collector. In contrast, Java sucks to scale out horizontally because it never wants to give up heap allocation. I wouldn't use these languages for desktop apps or building games. Another comparison to consider is perhaps Python. Everyone that advocates for Python seem to think that it's great for anything that can be written in C, but it's actually trash when you're trying to implement new algorithms in the language.
The TLDR is probably something about knowing your tools and using the right ones for the job.
It suits me perfectly for what I use it for. It's my most productive language that I use. There are loads of different languages out there so why persist with using GO if it doesn't fit your use case.
kamikazechaser@reddit
encoding/json unmarshal's missing JSON properties to their 0 values almost 4 years after people have asked for a fix. The alternative can possibly lead to null point dereference unless if you write a recursive checker.
All in all, still a decent language.
whatevers233@reddit
No. It's a terrible language. It lacks metaclasses, macros, has shit typing (still), and it has zero utility outside of unix daemons or web services with mediocre requirements.
Its GC has been improved, and it's a usable tool.
But decent is pushing it; even Gogen is worse than C's preprocessor.
If you want decent, you want Clojure. Scala. Kotlin. C#. Even fucking Ruby is decent, despite its downfall in the last recent years. Erlang is decent. Fuck, even C is decent. Perl.
If you want good: C++, Haskell, Common Lisp, Ada, OCaml, Prolog, and others from the same arenas.
Aside from that, forget it.
Scalability is measured by one's ability to leverage good tools while striking a balance between maintainability and extensibility. Go has neither, generics or not.
Shoving if err != nil down your throat isn't the way to go about it.
Go belongs in the dustbin of Java, PHP, Python, JavaScript, and other horrors we've had to endure over the past 30 years.
Meterbrot13@reddit
This comment makes me think of haute couture designers who think cargo pants and tshirts are terrible.
MichalDobak@reddit
You can complain a lot about Go but lack of these is actually an advantage of Go. Macros and metaclasses are the fastest way to make your code an unreadable mess.
Do you mean go generate? Go was not designed to use a preprocessor like most other languages. Go generate is the tool of last resort and almost nobody uses it because there is no need for it.
I've been working for years on backend services in Java, Python, NodeJS, and PHP. None of them even come close to Go. The language and libraries are extremely stable, and applications written in it require almost no maintenance.
At every company I worked at, we always had a lot of unhandled exceptions because someone didn't know that some method could throw it. This occasionally caused bugs because some routines were interrupted in an unexpected place. On the other hand, I've never seen a similar problem with any Go service because Go forces you to think about how to handle errors. It's also easier to analyze it during code review. Does it require more work? Sure, but in the end we get better code.
simple_explorer1@reddit
Oh gosh, here we go again. Another "Go does not support anything BUT its an advantage", fanboyism to the extreme.
These are the same people who complain about even trivial things missing from Typescript, Python, Java, C# but when it comes to GO everything is fine regardless of how many missing things it has.
It's just is crazy that the moment there is a "google" tag dev's are ready to adopt even a garbage practice as "best practice".
MichalDobak@reddit
It's not fanboyism, it's 15 years of experience in professional programming. Only young programmers think a language with more features is a better language. The more experienced have learned lessons from the mistakes made by JavaScript or latest versions of C++.
I used to work as a software architect for years, and one of the things that every software architect tries to enforce in a team is to force developers to write simple code without using all those cool features. Have you ever heard of Value Objects? POJO/POPO? Composition? Functional programming? You know, all those cool design pattern that are basically a return to the roots when programming languages were simple. Sometimes I think half the job of a software architect is to convince young programmers that complex code that uses the latest and coolest features of a language is not good code.
I really doubt that those are the same people.
simple_explorer1@reddit
Said nobody except developers who don't know how it help in creating better abstraction, design patterns, error handling, understandable code. Remember, the use case WILL not go away and because the language does not provide good tools to solve those the complexity of handling them is shifted from language to the user code (and even that also does not always works due to limited type system). This goes against DRY coding principles and a mess of code.
Again, completely incorrect (looks like you are just throwing any reasoning which might stick).
ALL modern Languages are SIGNIFICANTLY better than GO and have all/most of the tools one needs to craft great code. Rust (much bigger than GO feature set and universally loved and adopted at alarming rate EVERYWHERE), Kotlin, Typescript (fabulous type system which makes up for some beautiful design patterns and strong typing at compile time), Javascript (ES6 to 2022 are awesome adding so many capabilities), .Net core. Just name one mainstream language which is as poorly designed as GO which supports so few things?
Its common sense that if your language support so few things which ARE necessary to write code then how is that a good thing.
Developers like you only said that even generics are NOT necessary just because GO didn't want to support it and after 10 long years GO team finally added half baked generics (like everything else in GO). Will you now challenge that GO team was wrong because they added Generics and increased surface area of language? GO team has been slowly bringing commonsense features which have existed in so many languages since decades 10+ years later because they get SO MANY complaints and even realize that it is not a desirable language that way. Where are developers like you when they add more things (exact same which existed in other languages).
Go does not even support sum/union types which is crazy. How does one program without that and write a code which can express those things and enforce eloquently?
Javascript/Typescript are FAR more pleasurable languages to work compared to GO. Even Dart, kotlin, Rust are beautifully designed. GO is ugly, limiting and the type system is NOT at all expressive.
GO team is lucky to have supporters like you who think getting much less support, even necessary thing is better. Hardly any language is trying to emulate Go.
MichalDobak@reddit
Of course. I've been working as a software architect without knowing it.
Can you share a link to your GitHub profile? I'm carious how your understandable code looks like. You can easily find mine.
You must be trolling.
But did you know that the authors of Rust have similar views on OOP as the authors of Go? Rust supports similar subset of OOP as Go. Rust also doesn't have exceptions like Go. Even more, Rust doesn't have unions too! Crazy, huh? Just like Go, Rust supports very few features compared to Java, Kotlin, C++ or TypeScript because this is how modern languages should look like, not like another Java.
Enum, pattern matching and macros are the only big features that Rust has and Go doesn't.
You haven't even opened the Rust documentation.
Edit: Oh wow, you blocked me, so now I can't respond. I didn't write anything that could have offended you and the discussion was civil, so I guess you ran out of arguments.
simple_explorer1@reddit
The thing is to have been boasting about how "you are an architect" and how "you have 15 years of experience". The inherently don't add value to discussion abd you should let your points do the talking. For what is worth it, I have more experience than you number of years wise but that does not make one better or worse developer, understanding of concepts does.
I honestly feel that about you because of your arguments which makes no sense. You are advocating for not having useful features in language hoping that the usecase for them will go away simply because the language does not support it. It's crazy.
Hardly answering and overlooking the fact that Rust has LOT of features backed in the language with a very powerful type system.
Honestly you answered none of the points I have raised except "you have 15 years of experience" or "you are an architect so you know better" type useless arguments.
prietitohernandez@reddit
Dude Rust is too intelligent for the average developer, companies dont want to pay for geniuses so languages like Go are pushed cause they are boring to write but very easy to read.
vlakreeh@reddit
I picked up Go a few months ago and was ENTIRELY unaware of this until Tuesday. Spent like an hour trying to figure out why my response's data in a test was incorrect, turns out I had a typo in my JSON tag.
The fact this isn't an error is unbelievable to me, the collective hours of developers debugging issues just because of JSON struct tag typos must be in the hundreds.
Rixoncina@reddit
This is why you should have request validation
aanzeijar@reddit
I kept tabs on Golang as one of these "maybe if I got time for it" languages. But every time I actually learn something about it it's weird. Like the error handling or the details of the new generics system. And now this.
I still have no idea what this language is actually for. It seems that both the system/performance case and the high level safe niches are better served by other languages.
CSI_Tech_Dept@reddit
My impression of Go is a language that assumes you're to dumb to grasp some advanced concepts so your code ends up being a lot of simple statements, but also much longer.
I really don't understand the fascination of it.
k-selectride@reddit
Go deserves all the criticism leveled at it.
With that said, at the end of the day I'm still reaching out for it for a lot of things because:
That's it. If they fixed the closure inlining performance issue with generics that'd be pretty dope because I can't stand writing for loops just to check membership or filtering slices.
(also if they could add sum types and pattern matching that'd be great too)
arbyterOfScales@reddit
Even JS is faster than Python. :))
NotUniqueOrSpecial@reddit
That's a pretty flawed comparison, considering the V8 engine is probably one of the most optimized and insane pieces of magic in the world, and the Python interpreter is a hot bag of melted candlewax and tragedy.
simple_explorer1@reddit
So how is it flawed? OP was right when they said JS is faster than python and all you said was "because v8 is heavily optimised" which basically proves OP's point. You are confusing for no reason
NotUniqueOrSpecial@reddit
Because saying "Even JS" carries the implication that we should be surprised that JS is faster.
Take the common phrase: "even an idiot can do it."
It's not even remotely surprising that JS is faster than Python.
Also, who goes around replying to year-old comments, lol?
simple_explorer1@reddit
What has the "why did you reply on 1 year old comment" got to do? You know that the comments on reddit are forever so people stumbling on it can comment on it whenever they want, so?
NotUniqueOrSpecial@reddit
Actually, no: most subs have archive mode set around 6 months. I'm well-aware of how Reddit works.
That doesn't change the fact that you somehow managed to find this thread (which was by no means a big deal) and then specifically singled out my comment for your need to call someone "confusing for no reason".
So yeah...it's a little strange that you'd end up here, commenting at me, while apparently unable to understand simple English in common usage.
simple_explorer1@reddit
I have never met a bigger cry baby than you on reddit abbas that is not that difficult given we are on reddit haha.
Lol you MOST reddit (even 10 years old) don't archive unless the admin does so looks like you don't know what you are taking about and the fact that I (and anyone) can comment here is a proof which most people know anyways.
May be good to get off reddit if you are afraid of people calling or your BS given how easily you cry and resort to personal attack Sheff ruffled some feathers lol.
Sry, i made you cry
NotUniqueOrSpecial@reddit
Holy shit you're fragile, lololol.
In what way is pointing out it's odd that you'd comment on year-old posts being a crybaby?
Do you understand human emotion? Are you, in fact, a real person?
Because all signs point to no, currently.
simple_explorer1@reddit
You remind me of.... wait..... oh yeah.... toddlers, who, when caught react exactly like you did.
Looks like you are using reddit unsupervised lol
Barn07@reddit
I love Golang for it's tooling and it's reliable easy type system. I enjoy reading go code.
simple_explorer1@reddit
You really need to have a checkup for yourself if you enjoy being "subjected" to read GO code and that you still enjoy it.
GO is absolutely an unreadable mess especially mix of pointer/non pointer, interface{} littered everywhere, no sum types, no discriminated unions, not possible to create a new struct by picking keys from old struct, not possible to highlight optional field in JSON struct, JSON struct tags within string is a recipe of disaster as you won't get any auto code completion there, JSON data validation/json tags/optional fields/multi value struct fields is a nightmare to read and maintain in GO, implicit interface, magic init function etc. the list goes on and on.
Honestly except concurrency, everything else is pure inconvenience in GO.
beamologist68@reddit
So why use golang? A hybrid between FP and OOP...concurrency? Don't make me laugh! If you are serious about concurrency, go for erlang/OTP. Much nicer community too.
Intrepid-Astronaut41@reddit
I agree with everything you said. I use go because it relatively fast and low memory consumption. I should be able to carry a decent workload on smaller hardware, and therefore pay less money to make money.
pow3rlife@reddit
5-6 years ago, I wrote quite a large service in Go, mostly using the standard library. Today, I can run this project on the fly and continue working on it with the latest Go without any changes.Which language has such a feature?
Which language allows you to successfully implement a project relying only on the STD? Most of the solutions praised here for a simple project generate so many files that I'm overwhelmed right from the start.
Most of the solutions and components praised here that are part of a
given project will undergo so many different changes that updating such a
project alone involves a lot of energy and frustration.
protosam-@reddit
Imagine if you will, a guy that uses the butt end of his screwdriver to drive a nail into a board. That guy probably didn't have a good time, but the guy didn't know any better because the screwdriver is the only tool he owns. Maybe he didn't a hammer even existed. The packaging definitely wasn't clear about it not being suitable for the job either, he just saw some other guy using it that way one day. It worked fine enough, so he hasn't questioned it to this day.
I think it's naive to think one language is going to be able to everything you want. Complaints I've seen tend to gloss over design limitations that may exist in their language of choice. Go really sucks to use outside of distributed systems that scale horizontally, it shares characteristic traits with Java, like having a heap and garbage collector. In contrast, Java sucks to scale out horizontally because it never wants to give up heap allocation. I wouldn't use these languages for desktop apps or building games. Another comparison to consider is perhaps Python. Everyone that advocates for Python seem to think that it's great for anything that can be written in C, but it's actually trash when you're trying to implement new algorithms in the language.
The TLDR is probably something about knowing your tools and using the right ones for the job.
endianess@reddit
It suits me perfectly for what I use it for. It's my most productive language that I use. There are loads of different languages out there so why persist with using GO if it doesn't fit your use case.