Go is seriously limited language by design. If the limitations are starting to bother a person, they're better off just using a different language.
Why I’m Frustrated with Go
141–150 of 233 posts
Re: Why I’m Frustrated with Go
#142It's so interesting how the hype cycle works. Only 1 year ago, people on HN were bashing Node.js hard and saying that you should use Go instead and everyone was praising Go.
Now it seems everyone is bashing Go. Moral of the story; never buy into the hype whether it is positive or negative. I think that Go is just fine and so is Node.js.
Maybe the author of the article makes a valid point, but no language is perfect and ultimately you have to understand it well in order to use it well.
Re: Why I’m Frustrated with Go
#143In addition to what you describe, my other big complaint with Go is the attitude you find from the devs, in threads discussing these types of challenges.
"Oh, you think you want an ordered map? No you don't. Your reasons are stupid. You're stupid. Now gtfo and start using Go to write things we deem to be respectable."
Re: Why I’m Frustrated with Go
#144I am not sure where the authors exact requirements fit in the greater picture of the desired application. But one important tool which works great in Go is functional representation. If you want e.g. an immutable map, make it a structure with private fields, and give access vial functions (methods). The first comment to the article describes a nice example of this approach. I often read criticism of Go which is based…
The author discounts this as a good solution because you'd have to re-implement the structure and functions for every single type you might put in the map; i.e. that would be a valid solution iff Go supported generics, but it does not.
People say this, but it isn't really true- you could use the sort.Interface interface like everyone else. Consumer wants to use your custom map with their custom type? Make sure it supports Less.
Speaking of sort.Interface, people say they want generics, but I think there is an implicit ask for operator overloading, too. Or the code they are asking to not write is probably still going to be there.
Re: Why I’m Frustrated with Go
#145I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…
>I found it a chore to maintain Go-based systems My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week. I don't have much…
I tried Go and so far I'm feeling that Go forces me to abandon error checking and even if error is catched, I have no idea where this error comes from, because there's no stacktrace or anything like that. Best thing I've come to is using strings as errors (completely throwing out any error hierarchy) and returning new error string for every call with call information (doing poor job which Java would do for me automatically).
Re: Why I’m Frustrated with Go
#146Earlier quoted context omitted.
> This is especially true when your system is interacting with external data - like user input and a database. I did C# and Java for years. These interactions are, at best, painful with static languages. Why? I find when you're importing external data or user input, that's exactly where you want strong types as that's the most likely place unexpected values are going to be generated (e.g. unexpected null values, stri…
I don't disagree. It's just more tedious in static languages. Let's say we're doing a user registration. In most dynamic languages the JSON body will get parsed into a map. Excuse the fat controller and pseudo-language, but it'll end up looking something like: func create(conn, params) do if not Validator.is_email?(params["email"]) do return error(conn, "email is not valid") end if not Validator.min_length?(params["p…
Your example actually illustrates why dynamically typed languages should be avoided in general, especially when manipulating data coming from outside.
Your code starts by making a few checks on the shape of the data you're receiving and failing earlier if some conditions are not met. Great.
Once these checks are cleared, you now know that you can materialize an object with valid values in it, something the rest of your business code will be able to manipulate. So you instantiate that new object, return it and... all the knowledge about the shape of that data is lost.
The only thing your callers will see is an Object and zero information about what operations or fields are available on this object. They'll have to guess.
With a statically typed language, you don't have such a problem. You have asserted all these properties about the data that came in, you know exactly the class of the object you are creating, why forget all this precious information that will keep your code robust?
In my experience, dynamically typed languages are at an evolutionary dead end and offer close to zero advantages over modern statically typed languages (e.g. Kotlin, Swift).
Re: Why I’m Frustrated with Go
#147Earlier quoted context omitted.
No, Generics make it possible to create a generic immutable data structure which can be used instead of re-writing the same boilerplate for every data type, which is the authors complaint.
You are still talking about immutable data structures, which has nothing to do with generics.
No, YOU are still talking about immutable data structures, where as I am talking about the need to write boilerplate code in Go due to lack of Generics.
The blog posts topic was not "immutable data structures", rather the need for boilerplate code in Go because of the lack of generics. The particular example was one of immutable data structures, however that was an example rather than the topic. The author themselves notes that "generics would solve all of the issues above".
Re: Why I’m Frustrated with Go
#148The sorted map alternative is really only viable for insert-only maps or really small maps. You'd have to remove keys from the list when they're removed from the map.
Most sorted map implementations are based on trees.
Re: Why I’m Frustrated with Go
#149Earlier quoted context omitted.
> This is almost always unacceptable in production, This is not true for almost all software outside of embedded domains. In fact responding to an error near where the error occurred is almost always a mistake. The rare exceptions to this are when "error" is unavoidable due to concurrency (e.g. I/O), and even then many errors shouldn't be handled (misconfiguration, incomplete system initialization, etc.) or should be…
> If you support this position, you'd support checked exceptions like Java - something that's widely considered a mistake. The primary problem of checked exceptions in java is not that they exist, it's that they are very badly integrated with the rest of the language e.g. it's impossible to be generic or transparent over checked exceptions, their hierarchy is messy and it's often unclear why specific exceptions are c…
Haskell doesn't encourage runtime polymorphic module boundaries. That's the key difference with Java, not hierarchies. Abstractions invoked through runtime polymorphic interfaces compose poorly with statically typed exception specifications.
Generic composition that lets error types flow through abstractions also lets implementation details flow through, so it is an architectural choice, make no mistake. You don't dodge the tradeoff between abstraction and error handling.
Re: Why I’m Frustrated with Go
#150Earlier quoted context omitted.
> I don't have much experience with elixir, but that's because I like to stay employed. While the previous commenter gave an objective and rational overview why he think Go gives him a hard time you can't resist to get polemic.
I gave rational counter arguments and employment is pretty important too imo. It seems a lot of the anti-Go people tend to favor languages that no one gets paid to use.
Paid for Elixir full time, and there is definitely a market :)