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

171–180 of 233 posts

Re: Why I’m Frustrated with Go

#171

Post by lobster_johnson »

dvfjsdhgfv wrote: post #79
nhumrich wrote: post #46

Earlier quoted context omitted.

Go is nowhere near the speed of C. But why not consider Rust?

The Rust team decided to promote Rust as a "systems programming" language. And even though it can obviously do much more, and the bindings for most popular libraries are available [1], this label somehow attracts programmers who are more systems oriented and I think the language will continue to develop in this way, whereas Go/D/Nim will tend to try to be more general. [1] Imagine how surprised I was the other day to…

Rust is getting to be popular for graphics and games, precisely because it has the performance of, and easy interoperability with, C, without GC, and in a much more modern environment.

Low memory requirements means portability to memory-constrained platforms. Interoperability with C presumably also implies easier access to low-level resources such as GPUs, and being able to take advantage of existing libraries for C, such as SDL.

People are also experimenting with Go in the same space, but it seems much less promising. Go is notoriously slow at calling C (or being called from C) due to goroutine context save/restore. It also has GC and a runtime.

Re: Why I’m Frustrated with Go

#172

Post by fauigerzigerk »

jpz wrote: post #69

I think you have to work with the language you're in. I had similar frustrations when I first moved into doing some dev in Java and C# and it really bugged me that there was no compile-time guarantee that an Object reference passed as a method parameter would not be modified within that method (as I was so used to using const-refs with in C++) In retrospect however, I was frustrated with these languages because I was…

I don't see what's wrong with venting frustrations with particular technologies. It helps no one if people just move on silently.

It deprives the creators of that technology of the opportunity to react to any complaints and it deprives everyone else of the opportunity to choose a different technology from the start.

Re: Why I’m Frustrated with Go

#173

Post by harpiaharpyja »

hota_mazi wrote: post #146
latch wrote: post #61

Earlier quoted context omitted.

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

> 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 something preventing create_user(params) from emitting an object with a well defined interface?

Re: Why I’m Frustrated with Go

#174

Post by hota_mazi »

harpiaharpyja wrote: post #173
hota_mazi wrote: post #146

Earlier quoted context omitted.

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

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

Re: Why I’m Frustrated with Go

#175

Post by japano1se »

fauigerzigerk wrote: post #169
japano1se wrote: post #127

Earlier quoted context omitted.

Absolutely. With respect to this article and immutability, the strongest arguments I've seen for it are for concurrent programming, like the very successful Erlang solutions used at Ericsson, which I generally don't have an interest in. So, it is reason #4 on your list. For the types of program and the types of problem I need to solve, it's a moot point - people have been getting along just fine without immutable sta…

Limiting mutability is not new and it's not a fad. It is at the very core of every single principle of modularity and dependency management ever invented by mankind, even beyond programming. Almost 30 years ago when I first learned C one of the first design principles I was taught was to avoid mutable global variables. And ever since that time I haven't found anything as key to avoiding bugs as knowing and controllin…

Don't move the goalposts. Global state is not the same issue as immutable data. And even if it was, Go has the `const` keyword anyway, making it entirely irrelevant to the OP article.

This fad of using immutability everywhere and treating it like a silver bullet absolutely is new and is a fad.

Re: Why I’m Frustrated with Go

#176

Post by pebers »

meesterdude wrote: post #118
pebers wrote: post #113

Earlier quoted context omitted.

Why not? Plenty of languages don't come with one built in at all, or not one widely used in production (e.g. Python's http.server, there are a heap of other Python web servers out there).

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.

Re: Why I’m Frustrated with Go

#177

Post by pebers »

nine_k wrote: post #123
pebers wrote: post #112

> 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. Java doesn't do that well at all though; its immutable maps can be used in place of mutable maps, since there's no way of having a Map interface that extends ImmutableMap to add extra operations, so you can get nasty runtime surprises if you've got the wrong one. Conversely, if…

Lombok takes care of most of such boilerplate in Java. Code generating tools for Go also exist. The difference is that they produce source code, while things like Lombok, or any reasonable macro system, never surface intermediate code, unless explicitly asked.

That's still solving the problem by working around the language though. And surely it's the job of your build system to automate and hide the codegen process? Admittedly go build & go generate don't do that well, but they aren't the only options out there.

Re: Why I’m Frustrated with Go

#178

Post by coldtea »

43224gg252 wrote: post #18
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 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 don't have much experience with elixir, but that's because I like to stay employed.

Yeah, because Go is the epitome of employability...

>"Central error checkers" are almost never robust enough for mission critical systems.

Go is not used in mission critical (embedded, medical, aviation, communications, etc) systems anyway.

Besides the notion is wrong: mission critical systems DO centralize error checking. The code local to the error wouldn't have enough context (and shouldn't have the reach) to call the right procedures for cleaning up and moving on.

Re: Why I’m Frustrated with Go

#179

Post by wott »

dboreham wrote: post #110
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…

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 would mean doing this and this... hmmm... okay... and why would I want to do that? I could do it in C, if I haven't done it yet, that's because I didn't see the benefit of it, and I still don't.

Re: Why I’m Frustrated with Go

#180

Post by coldtea »

oceanghost wrote: post #168
ejcx wrote: post #136

Earlier quoted context omitted.

Wat. OpenResty as an alternative to go? Wat? Please, nobody write full fledged WebApps or all of your middleware in lua. Trust me that's a horrible idea. I have seen about everything you can do in lua/nginx and it does not turn out pretty.

I honestly thought the OP's post was a troll. Lua is for masochists.

>Lua is for masochists

Is this a happy-hour for Reddit users on HN?

Post reply on HN