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

201–210 of 233 posts

Re: Why I’m Frustrated with Go

#201

Post by meesterdude »

pebers wrote: post #176
meesterdude wrote: post #118

Earlier quoted context omitted.

when you set out to solve a particular problem, do you really think its a worthwhile use of your time and effort to create a webserver? Mind you i'm not talking so much about "built-in" webservers than I am about reusing an existing, battle tested one from a 3rd party (e.g. OSS) so you can focus on the actual problem your trying to resolve.

If the problem I'm trying to solve is "I want a better webserver", then yes :) That's a little tongue-in-cheek, but I assume is more or less the motivation behind all web servers in use today; otherwise we'd all be using httpd or something.

Yes, if you want to build a better webserver, go right ahead. But I think we're in agreement, that you shouldn't be reinventing wheels that you are not purposefully trying to reinvent. If we always started from scratch, nobody would get anything done.

Re: Why I’m Frustrated with Go

#202

Post by harpiaharpyja »

hota_mazi wrote: post #174
harpiaharpyja wrote: post #173

Earlier quoted context omitted.

> 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. I'm not really seeing how that necessarily falls out of the example given by GP. Could you go into that in more detail? Is there somethi…

That function does create an object with a well defined interface, but because you are using a dynamically typed language, that object has the type "Object" (or Any, or whatever the mono type of that language is). If you call that function, you have no idea what the type of that object is. Only the function knows it and that information is lost as soon as the function returns.

I think I will have to disagree with that. The type of object is not enforced by the compiler, but that's a long way off from "you have no idea what the type of that object is."

Re: Why I’m Frustrated with Go

#203

Post by dboreham »

wott wrote: post #179
dboreham wrote: post #110

Earlier quoted context omitted.

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…

For me, it goes like this: 1. What the heck is this thing everybody keeps talking about, with an impressive fancy name? It must a major step forward, after all this time, I should finally have a look at it. and then 2.a. Oh, it's just a big shiny name for something I accidentally kinda do sometimes, I didn't know it bore a name. Why is it suddenly a fad to base everything on this? or 2.b. Hmmm... right... so in C it…

Being able to see it happen in the debugger is my top peeve in this space. Yes there's a magic short cut for something, but no you can't see wtf is happening at runtime so when inevitably something seems to happen that doesn't accord with the expected outcome you are none the wiser as to why.

Re: Why I’m Frustrated with Go

#204

Post by hota_mazi »

harpiaharpyja wrote: post #202
hota_mazi wrote: post #174

Earlier quoted context omitted.

That function does create an object with a well defined interface, but because you are using a dynamically typed language, that object has the type "Object" (or Any, or whatever the mono type of that language is). If you call that function, you have no idea what the type of that object is. Only the function knows it and that information is lost as soon as the function returns.

I think I will have to disagree with that. The type of object is not enforced by the compiler, but that's a long way off from "you have no idea what the type of that object is."

The fact that the compiler cannot enforce it is a big deal since it prevents automatic refactorings, often impairs performance and overall, hinders readability.

And yes, you really have no idea what the type of that object is unless you look at the source of the function. Which is obviously suboptimal, especially if you don't have access to that source.

Re: Why I’m Frustrated with Go

#205

Post by seanwilson »

sametmax wrote: post #76
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…

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. See marshmallow for Python: https://marshmall…

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict.

You mean a dynamic check? It's better than nothing but I don't exactly want my e.g. scheduled data import process crashing because it was sent some bad data. I'd much rather have static checking and have all the possibilities accounted for before the code runs.

> As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful.

Why couldn't you write this with static checks? Statically checked functional languages for example are great for writing compilers.

Re: Why I’m Frustrated with Go

#206

Post by seanwilson »

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…

> What safety does Go's version buy you?

A statically typed version guarantees you haven't made some fundamental mistakes and enables automatic refactoring.

Say we wanted to change an ID field from being a string to an int later in development for example. You've now got to hunt around all your files making sure the right type is being used. It feels incredibly primitive when you need to do this manually or have to rely on an exhaustive and annoying to maintain test suite for this.

Re: Why I’m Frustrated with Go

#207

Post by KallDrexx »

regulation_d wrote: post #199
KallDrexx wrote: post #158

Earlier quoted context omitted.

I don't think a central exception handler means ONLY handle exception in one very specific point. It means that if you can handle an error handle it, otherwise let the central exception handler handle it. I really like Elixir and the Erlang VM but supervisor trees are not a perfect solution either. For all the talk about how in Erlang you just let things fail and don't have to do defensive coding, any non-trivial app…

If you need an ETS table to have greater resiliency move it up higher in the supervision tree. Nothing prevents you from starting it at the application level. Also you have a lot of control of your supervision tree. You can specify the quantity and frequency of failures that would cause a supervisor to fail. For some use cases, 3 failures in 5 seconds might be reason enough to restart that supervisor. For other use c…

Right, so you have to make a lot of decisions on what things can fail, how often they should be allowed to fail, what side effects can be tolerated with a major failure, what happens if a bad process fails when it comes back up (thus risking causing the supervisor itself to cascade restart itself), etc...

These decisions are not trivial and are exacerbated because of the Actor style of flow due to the independent pieces.

So from my experience you have non-BEAM languages where a single error can take down your whole application if you don't plan your failure scenarios properly, where as in BEAM languages if you don't plan your failure scenarios properly you are more likely to end up with an inconsistent system. The former isn't that bad in a lot of circumstances as you should have an external application monitoring and restarting a critical server that's no longer running (even for BEAM systems) but the latter can be very bad because it can be a silent issue.

I have systems working at my job written in .net that have been running for over 6 months without a restart, even when Azure had failures and it could not talk to its command and control server for an hour and kept running perfectly fine with using a well thought out architecture and a well placed central error handler for generic errors without things cascading throughout the whole system.

So resiliency has less to do with language or supervisor trees and more to do with making every step has failure scenarios thought about and planned for.

Re: Why I’m Frustrated with Go

#208

Post by rumcajz »

fnord123 wrote: post #109
rumcajz wrote: post #78

Earlier quoted context omitted.

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

Yep. And lack of exceptions in languages like C or Go makes it harder to pretend you have done the right thing, if you in fact did not, given that it forces you handle every single error condition explicitly.

Re: Why I’m Frustrated with Go

#210

Post by fnord123 »

rumcajz wrote: post #208
fnord123 wrote: post #109

Earlier quoted context omitted.

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

Yep. And lack of exceptions in languages like C or Go makes it harder to pretend you have done the right thing, if you in fact did not, given that it forces you handle every single error condition explicitly.

Yes, exactly.
Post reply on HN