Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m Frustrated with Go

dev.to

Post reply on HN
Print view View original

91–100 of 233 posts

Re: Why I’m Frustrated with Go

#91

Post by masklinn »

rumcajz wrote: post #78
fnord123 wrote: post #71

Earlier quoted context omitted.

>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 + "sorry, try again"). You are correct that this is how it's often done - 9 out of 10 errors probably ARE "handled" by a central error handler. But this is an incorrect approach if the goal is a reduction of catastrophic errors. In the following paper, "Simpl…

Depends on the app. In GUI, yes, why not, display an error message and you are done. In infrastructure software, OTOH, you want to handle errors in thoughtful manner. If you can't it's often better to crash the application than to continue with broken state.

Erlang/Elixir is pretty interesting there in that it will "crash the application" but said application's scope is a single process (unless others are linked to it, which lets you build supervision tree and take down and restart the entire tree when one of the processes crashes).

Re: Why I’m Frustrated with Go

#92

Post by humanrebar »

searealist wrote: post #83
humanrebar wrote: post #82

Earlier quoted context omitted.

> const std::set s // This is immutable. > Foo() : s(helper()) {} // This is a move, not a copy. First, I'll point out that the data of s is not immutable. The fact that you can const_cast away the const and change the value makes that clear. If people do things like that (or corrupt memory or have race conditions in the code), C++ doesn't necessarily give you clear exceptions or compiler errors. Many of the ways to…

const std::set s; // This is immutable. const_cast &>(s).emplace(); // This is UB.

And what do the assignment operators of Foo look like?

Re: Why I’m Frustrated with Go

#93

Post by ue_ »

masklinn wrote: post #30
dvirsky wrote: post #26

Earlier quoted context omitted.

I don't know specifically why that is for this specific project, but in general Go has GC and bounds checking that slow things down.

Rust bounds-checks indexes by default (there exist indexing methods which bypass that, they are unsafe).

If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. I'm not sure why people talk about Rust being safe when this sort of thing happens and it can't catch it at compile time. At least C compilers have sanitizers that pick up things like that.

Re: Why I’m Frustrated with Go

#94

Post by falcolas »

oelmekki wrote: post #72

Out of curiosity, what is the use case for immutable structs? (asking as I'm a ruby/js/go dev and as such I've never used such idiom)

It's a code safety thing. If you create it and the compiler makes it immutable, then you can't screw it up later with an accidental mutation.

Basically, something that takes coder discipline in Ruby/JS/Go is handled a compiler/runtime enforced restriction.

Re: Why I’m Frustrated with Go

#95

Post by humanrebar »

kuschku wrote: post #49
user5994461 wrote: post #36

Earlier quoted context omitted.

And java doesn't have them either. You need to use an external library, likely the google containers library.

But you can build and use generic immutable collections.

This is true. My beef with Java collections is the type-tree-gymnastics library authors have to do to get the interfaces exposed properly. Generally people end up with a family of ImmutableContainers and a family of Containers that parallel each other. The mutable Containers usually inherit from the immutable versions.

This is possible, but it's an unfortunate form of code duplication.

Re: Why I’m Frustrated with Go

#96

Post by freeone3000 »

43224gg252 wrote: post #32
thinbeige wrote: post #27

Earlier 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.

You have the ability to choose Go - you could as easily have chosen Elixir.

Re: Why I’m Frustrated with Go

#97

Post by jorgec »

latch wrote: post #11

I 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'm a huge fan of dynamic languages. I think they're so much more productive. This is especially true when your system is interacting with external data - like user input and a database." Im not so sure about it. Database is not dynamic and user input should be controlled, or number, or date, or text, for example an user could enters the price of a product a text.

Re: Why I’m Frustrated with Go

#98

Post by falcolas »

PeterisP wrote: post #57
_ph_ wrote: post #34

I 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.

Go's introspection tools do provide enough support to offset the lack of generics, at the cost of having to write your own type checks, and at the cost of having runtime instead of compile time type checking.

But it can be done.

Re: Why I’m Frustrated with Go

#99

Post by Pxtl »

latch wrote: post #61
seanwilson wrote: post #23

Earlier 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…

In C# MVC, the JSON gets deserializrd into a tree of statically-typed objects you declared beforehand. Any malformations of the JSON are an error.

Re: Why I’m Frustrated with Go

#100

Post by tonetheman »

I asked this same question on reddit. And I am not trying to be snarky. I have programmed a long time and I cannot think of a single time where I thought, "this would be easier with generics."

Where is the list of problems that are easier to solve with generics?

Post reply on HN