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

Why I Don't Like Golang (2016)

teamten.com

Post reply on HN
Print view View original

121–130 of 237 posts

Re: Why I Don't Like Golang (2016)

#121

Post by richardwhiuk »

serial_dev wrote: post #101
implying wrote: post #5

They've fixed the import / modules situation to a point where it's usable and much improved, and generics have been added. However, the issue this brings up about structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem, especially in large codebases. The only tool that I'm aware of that finds implementations is GoLand, at steep JetBrains prices. Figuring out what typ…

> structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem Isn't it a feature? You can have a "writer" as long as it can "write", and then use that writer anywhere where a function expects a writer?

But do you obey all of the semantics of the writer interface which aren't expressed in code?

Re: Why I Don't Like Golang (2016)

#122

Post by morelisp »

sam0x17 wrote: post #89
gabereiser wrote: post #87

Earlier quoted context omitted.

This isn’t true. Go has a basic standard package list. https://pkg.go.dev/std

Yes, and it's missing tons of things we take for granted in other langauges. If you look at the "strings" section it's so short. There aren't even convenience things like string reverse.

Why do you want a string reverse?

- Do you want to reverse bytes, or codepoints?

- Do you want to reveres codepoints, or grapheme clusters?

- Do you really want to reverse grapheme clusters, or do you want to reverse some grapheme clusters while leaving e.g. sequences of control characters in the same order?

- Do you really want to reify any of this rather than iterate backwards in the existing memory?

Re: Why I Don't Like Golang (2016)

#123

Post by kstenerud »

szundi wrote: post #116
kstenerud wrote: post #78

Earlier quoted context omitted.

Sorry, no. I have JetBrains and have since stopped using it for go development. It's too slow, too buggy, and lacks the ecosystem that VS code has. I still use it for Java because the rest are even worse A language that depends too much on IDE integration for usability is a real problem, because now you have tool fragmentation as everyone goes different routes with varying levels of success to fix the deficiencies in…

While I am getting your points, but IDE support is an incentive to use a language in my eyes.

I'm not complaining about IDE support. IDE support is great!

IDE dependence is not.

Re: Why I Don't Like Golang (2016)

#124

Post by richardwhiuk »

yashap wrote: post #55

Agreed with the article, though obviously it’s a bit dated (especially around generics and package management). My take is that Go is basically the new Java, with fewer abstractions and faster compilation. Although, the pre-Java 8 Java, before Java started to get a bit functional. Like Java it’s a practical, imperative, statically typed, garbage collected language with very good performance. Also like (pre-Java 8) Ja…

It's the new Java 4. Eventually they'll add the missing stuff and it'll get current with Java 6.

Re: Why I Don't Like Golang (2016)

#125

Post by philderbeast »

sriram_malhar wrote: post #18
xigoi wrote: post #9

Earlier quoted context omitted.

Professional developers in the USA usually make 6 figures.

Musicians and carpenters make far less than programmers, but they still buy their tools. Software people are too entitled. Even if you are not professional, you can still afford 54c a day ($200 a year). Even a programmer in India can.

If you work for a company, in any field, and they don't supply the tools for you to do your job, they are doing them selves a disservice.

If you want your employees to be productive, you provide them tools to achieve that, otherwise you get what you pay for.

It's the Companies that are acting entitled in this situation, not the workers.

Re: Why I Don't Like Golang (2016)

#126

Post by weatherlite »

justanorherhack wrote: post #50
weatherlite wrote: post #44

Earlier quoted context omitted.

Crud APIs...

IMO it’ll be slower to write crud apis and there are some missing batteries you have to look for, it’s fairly verbose but I think some of that will change with generics and hopefully more pattern matching. On the flip side when you deploy it, it will like just work and run smoothly. Also very easy to add full integration tests as you can create a mock http server at runtime, paired with some db tools (go migrate) it’…

OK thanks for this, the easily mock thing is indeed very nice to have. And maybe Generics will improve things. I don't get why there isn't a function to remove element from a slice (there's some append[:i],[i+1] trick instead) why wouldn't this be wrapped in a stdlib function? call it delete or something. I keep hearing good things about the stdlib - what am I missing? It's that do it yourself mentality I really don't like, and taking huge compromises on readability to preserve low language keyword count (like the lack of private keyword / capitalization the article discussed and the consequences) and then calling this whole setup "simple". There's nothing major but many many small things I think that make it a subpar experience. I don't care that much about performance and concurrency though which I think are Go's strong suits.

Re: Why I Don't Like Golang (2016)

#127

Post by imaginaryNumb3r »

foolfoolz wrote: post #77
bmitc wrote: post #25

Earlier quoted context omitted.

What's even worse is getting companies to pay for this stuff. Getting a company to buy software to help you do your job is like pulling teeth.

any company will let you expense a few hundred dollars for a tool you use literally every day many hours a day. if you’re having trouble they are not good to work for or you’re asking the wrong way

how is this not common sense

Re: Why I Don't Like Golang (2016)

#128

Post by TheDong »

benhoyt wrote: post #100
sam0x17 wrote: post #89

Earlier quoted context omitted.

Yes, and it's missing tons of things we take for granted in other langauges. If you look at the "strings" section it's so short. There aren't even convenience things like string reverse.

Odd, I find the standard library very full-fledged and useful, including the strings package. I've almost never needed to reverse a string, except in interviews. :-) The stdlib has a full (and good) HTTP server with HTTP/2 and TLS support, HTML templating, excellent I/O support, compression, even image encoding/decoding and drawing. That said, the container types are pretty sparse, but that may change a bit now that…

Not that person, but I'll call out a few issues I've had with the go stdlib:

First, it has a lot of useless packages you typically wouldn't use, like "log" and "flag" (which work, but are way worse than third party alternatives like logrus and pflag), but also like "syscall" (as it says 'deprecated, use 'golang.org/x/sys' instead), "image/draw" (nope, you wanted 'golang.org/x/image/draw' usually), "path" for working with paths (you wanted "filepath"), "net/rpc" and "rpc/jsonrpc", "plugin" (almost always a bad idea), a chunk of "strings" (use "golang.org/x/text" for proper unicode support) and so on. Some of those are marked deprecated, most of them are not, and are just waiting for someone to accidentally use them.

That's issues I have with the stdlib and not stuff I'm missing though... Though I guess I really do miss a good logging library, or at least interface for external packages to implement so I can plug in logging libraries without rewriting the world.

One thing I do find missing frequently is a reasonable set type with the ability to do things like basic set operations (intersect, diff, etc). I constantly have to write ad-hoc for loops in go to do set operations, and it's verbose, non-obvious what the code does, and easy to get wrong.

But honestly, the main thing I'm missing isn't actually a package, but more about error handling for the stdlib as a whole, which is more a language issue. I really wish I could know what possible errors stdlib functions returned without, fairly often, having to read huge chunks of stdlib code to determine that.

Perhaps 40% of the stdlib documents the error type it returns in a message (like 'os.Chdir' always returns '*os.PathError'), but for the rest, good luck. Want to figure out what errors you might have to check for 'tar.Writer.Close()'? Well, the docs says "returns an error", the interface is "error", you have to read hundreds of lines of code to figure out the possible concrete types it could be. Maybe 15% of the time, you end up having to string-match on error messages because the error var or type is unexported.

Re: Why I Don't Like Golang (2016)

#129

Post by sa46 »

moron4hire wrote: post #105
benhoyt wrote: post #30

My thoughts on his points, from someone who really likes Go and has used it heavily on small and large projects (1M LoC): 1. Probably a matter of taste, but I love this feature, just because of the lack of noisy public/private keywords everywhere that you see in Java et al. It also means you can tell from a usage (not just the definition) that something is exported, which is often useful. As far as renaming goes, eit…

On point #2: I don't know anything about Go, but I've spent a lot of time working in a lot of languages. Structural typing is a bad idea. There are a few, limited cases where it's necessary, e.g. we have it in TypeScript because TS ultimately has to work within the limitations of JS. But if you don't have those sorts of limitations, intentionally implementing structural typing in your language is borderline negligent…

The upside of structural typing, with some help from Go idioms, is that it encourages composition and narrow types. A type like bytes.Buffer implements Reader, Writer, ByteWriter, ByteReader and another 5 or so interfaces but the call site can declare which set of methods it needs.

The downside of nominal interfaces seems worse: you have to import the interface which can lead to awkward situations like cyclic dependencies and type-only packages (a la Haskell). In practice, the extra friction of nominal interfaces also seems to encourage wide interfaces in contrast to Go's narrow interfaces.

Re: Why I Don't Like Golang (2016)

#130

Post by einpoklum »

sriram_malhar wrote: post #18
xigoi wrote: post #9

Earlier quoted context omitted.

Professional developers in the USA usually make 6 figures.

Musicians and carpenters make far less than programmers, but they still buy their tools. Software people are too entitled. Even if you are not professional, you can still afford 54c a day ($200 a year). Even a programmer in India can.

1. A Musician has one tool. Ok, maybe a note-stand etc. But in software, there are thousands of "tools" you can buy.

2. Physical tools vs making copies of some bytes. No need to retread this here, but bottom line: Not comparable.

Post reply on HN