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

101–110 of 233 posts

Re: Why I’m Frustrated with Go

#101

Post by mercurial »

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…

Well, the dynamic version won't complain until runtime the day you mix up the order of your parameters and invoke "create(params, conn)", for instance. Besides, you can make it statically impossible to generate an invalid user object with a static language. In a dynamic language, an invalid user object is just an assignation away.

Now, if we are talking about error handling, the way it is done in Go is not particularly representative. Most static languages would go with exceptions (or maybe checked exceptions in Java). Haskell/Rust/Scala would probably go with a Result type, and then it's more a question of the language giving you the tools to propagate the errors and wrap them (Rust with error-chain is excellent at this kind of thing).

Re: Why I’m Frustrated with Go

#102

Post by blub »

humanrebar wrote: post #88
blub wrote: post #75

Earlier quoted context omitted.

Yes, humanrebar is really grasping at straws. :) I would also mention that using mutable and const_cast is frowned upon and it can be trivially searched for and forbidden. Their comment about const iterators also misses the mark. Yes, the designers of the C++ standard library did a bit more work and now everyone has a high-quality type-safe dictionary implementation available. That's how it's supposed to work...

> humanrebar is really grasping at straws. :) On the contrary, I've had to mentor a lot of C++ developers where they were surprised when their put-const-on-it approach to providing safety resulted in production bugs. I think it's fair for people to be surprised by this sort of thing. And I don't think the things Go developers have to do are all that much worse than equivalent code in C++. In C++, 'const' mostly means…

Context is everything. If you come in the middle of a topic about declaring a bog-standard map and start discussing the subtleties of const, container design and the map implementation you will confound people and are frankly off-topic. :)

I mean the discussion was about declaring a simple map. In that context, it really is as easy as writing

    const std::map map;
Go can't do that. C++ can do that. Seems pretty straightforward.

Re: Why I’m Frustrated with Go

#103

Post by logicchains »

jpz wrote: post #64
humanrebar wrote: post #12

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read…

Let's take this const map: const std::map constMap = { {1,1}, {2,2 } }; Or take a const map copy-constructed from from a non-const map, if you wish. How is this not immutable data, and "only provides a read-only view"? It is linguistically guaranteed to be non-mutating - const-casts excepted of course. All languages that are constructing const data types on the fly are putting them in a writeable pages in memory, aft…

>It is linguistically guaranteed to be non-mutating - const-casts excepted of course.

Technically even after const-casting, if it was declared const then it's still not possible to mutate it, as doing so is undefined behaviour. "Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior." - http://en.cppreference.com/w/cpp/language/const_cast

It could for instance have been stored in non-writable memory, so any attempt to write to it will instantly segfault. This is one of my favourite things about C++ as people engaging in terrible programming practices like const-casting a const object get their just desserts, so to speak.

Re: Why I’m Frustrated with Go

#104

Post by tannhaeuser »

_urga wrote: post #42
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 +…

The Node event loop (the control plane) is single threaded, but the data plane is multi-threaded, you can easily write C++ bindings to run in the thread pool to handle CPU intensive work.

Speaking of Node in the context of error handling, what are current best practices in Node (other than running node-forever respawning)? Up to v0.12, Node used to have heuristic cleanup code for file handles and other resources on exception domain error handler execution, but the domain API has been deprecated for some time now ([1], [2]).

[1]: " rel="nofollow">https://nodejs.org/api/domain.html>

[2]: " rel="nofollow">https://github.com/nodejs/node/issues/66>

Re: Why I’m Frustrated with Go

#105

Post by dbattaglia »

seanwilson wrote: post #23
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 +…

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

Couldn't agree more. In my current life as a Ruby dev I've found the dry-struct (http://dry-rb.org/gems/dry-struct/) library a huge help in getting some level of sanity when dealing with converting inputs to data types. It also helps being able to reason about the inputs structure outside of just looking at some hash field indexing at time of use.

Re: Why I’m Frustrated with Go

#106

Post by _ph_ »

kuschku wrote: post #54
_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…

But you still have to write the function a hundred times — once each for every immutable map you'll use. This is the opposite of DRY.

Yes, if you needs lots of different immutable maps as your interface to a library, then the lack of generics is annoying. But the question is, is the immutable map such a common interface, or should your library and abstraction barrier be something else? I am a professional programmer and have prefer abstractions via objects/functions.

Re: Why I’m Frustrated with Go

#107

Post by alkonaut »

eterm wrote: post #35
alkonaut wrote: post #24

Having to encapsulate data to ensure read only semantics seems like par for the course from an OO perspective. In C# (which is 15ish years old at least) I don't think there has been an immutable map until very recently. Also (and this is probably a code style thing) I can't remember having reached for an immutable ordered map in a long career.

ReadOnlyDictionary has been around for 5 years, and even before that you could implement this with generics in a way that is re-usable everywhere rather than having to constantly 're-write the wheel' as in Go as the author laments.

Yeah lack of generics with the argument of "simplicity" is a special kind of crazy.

I was thinking of the ImmutableDictionary that's more recent. Normally in C#/Java you should rarely expose collection types directly so you almost always encapsulate the list/dictionary and provide e.g GetReservation(string id) to the outside, which makes it less common to even need the readonly types at all. Immutable ones are a whole different thing since they enable proper sharing of whole collections.

Re: Why I’m Frustrated with Go

#108

Post by vince14 »

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

>Node is single threaded

You can still utilize all of your cores in Nodejs. So which problem are you encountering?

Re: Why I’m Frustrated with Go

#109

Post by fnord123 »

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.

Sure, if you're in a GUI then you report to the user that an operation failed and it's up to them to figure out what they can do about it.

As for infrastructural software, yes you want to handle errors in a more thoughtful manner. If you can't and the process has corrupted it's own stack or heap (in the case of C or C++) then sure, abort. But I'm saying this line is often chucked over to "log the exception and do nothing" too quickly because it's often the easier thing to do. 25% of catastrophic failures in this one study appear to occur because of this.

tl;dr: The devil is in the "If you can't".

Re: Why I’m Frustrated with Go

#110

Post by dboreham »

japano1se wrote: post #74

Of course the problem he has is that it doesn't follow the hot new immutability fad, and of course he doesn't explain what he needs it for, just links to a stack exchange question which essentially says that it might be useful for some cases. It seems a lot of these articles, and programming language theory in general, is just complaining about features without any thought as to why they matter. What is this "problem…

Spot on. As a card-carrying dinosaur I've found myself from time to time needing to read up on some "new" (usually turns out to have been invented in the 60's) coding thing.

Once I figure out what it is, I ask myself what problem it solves (the literature typically doesn't say). The answer tends to be one of:

1. Saves some typing.

2. Saves some work when refactoring.

3. Avoids some class of bug.

4. Highly useful in a kind of programming I don't do (e.g. compilers).

#1-2 in my experience are much more common than #3-4 and often #1-2 can be dealt with through tooling (IDEs for example).

Post reply on HN