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

I Love Go; I Hate Go

dtrace.org

Post reply on HN
Print view View original

101–110 of 329 posts

Re: I Love Go; I Hate Go

#101

Post by mulltiq »

gkya wrote: post #69
_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

I really would like to see what happens when somebody forks go to create a sort of Go++ (tm) which, while still compiling code written for actual Go, didn't strictly prohibit unused variables and imports but only issued warnings and, added function templating as a means of generics. Regardless of whether these are good ideas or not to have in Golang, it'd be interesting to follow how the community orientates itself i…

Well, there's Oden experimental language that compiles to Go, but it's Haskell inspired (even written in Haskell itself) https://oden-lang.org

Re: I Love Go; I Hate Go

#102

Post by nutheracc »

EugeneOZ wrote: post #96

> Contrast this with Rust whose errors read like mind-bindingly inscrutable tax forms. It was "lol what?" for me. Rust's compiler error messages are very informative and sometimes contains tips what to change in your code to make it work (not just general words, but code you can use right now, with your variables/functions etc.). Borrow checker explains step-by-step where ownership starts, where it ends and where you…

Yes, agreed, the Rust error messages are very helpful. Failure to understand the messages is a lack of familiarity with Rust, not a problem with the error messages.

Re: I Love Go; I Hate Go

#103

Post by _ph_ »

millstone wrote: post #55
dpc_pw wrote: post #49

Oh. Go love-hate relationship post. My turn. So I really like channels and coroutines built into language and used everywhere: it makes some patterns compose nicely and language very productive. But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provide…

> How do you decrement an atomic in Go? Ooh. How do you delete from a slice in Go? With append() of course! http://stackoverflow.com/questions/25025409/delete-element-i...

If the order of the elements in a slice does not matter, this should be the easiest solution for deleting the element "n":

slice[n] = slice[len(slice)-1]

slice = slice[:len(slice)-1]

Probably one should campaign for adding a delete operator to slices, though so far I have never missed it.

Re: I Love Go; I Hate Go

#104

Post by nutheracc »

superswordfish wrote: post #88
dpc_pw wrote: post #49

Oh. Go love-hate relationship post. My turn. So I really like channels and coroutines built into language and used everywhere: it makes some patterns compose nicely and language very productive. But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provide…

> ignoring years of research and good ideas And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least prete…

You've hit the nail on the head for me at my current place of work. The only alternative I have here is Scala, which I wouldn't choose, but higher quality ecosystem and community, and closer to Rust which I'm enjoying at home, so am thinking of doing the switch.

Re: I Love Go; I Hate Go

#105

Post by masklinn »

valarauca1 wrote: post #98
EugeneOZ wrote: post #96

> Contrast this with Rust whose errors read like mind-bindingly inscrutable tax forms. It was "lol what?" for me. Rust's compiler error messages are very informative and sometimes contains tips what to change in your code to make it work (not just general words, but code you can use right now, with your variables/functions etc.). Borrow checker explains step-by-step where ownership starts, where it ends and where you…

This was where I stopped reading. The author clearly hasn't worked with Rust. Not only are the messages very descriptive, but you have an extended explaination for each error in the form of: rustc --explain EXXX Which pulls up a long form explaination, and code samples of what is happening/why it is happening/how to fix it. The blog explaining the author's disdain for Rust mostly just seems to whining about the borro…

> The author clearly hasn't worked with Rust.

The author links to a previous post on the subject, from mid-2015, so they clearly have at least tried Rust in the past.

And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good).

Here's a clearer example (fixed since): http://dbeck.github.io/My-First-Steps-In-Rust/ note two issues:

* the error message is busy as all hell which is a common issue in Rust, before you've built the habit and learned how they're structured Rust error messages often look daunting. By comparison Elm makes much more extensive use of spacing and tries to avoid repeating the same information (e.g. file names) over and over.

* the suggestion it provides is just plain wrong, it suggests implementing Debug for T, but T is always a standard number which already implement Debug, what's missing is a trait bound. To a beginner that was not a helpful suggestion as it would only send them on a wild goose chase (of trying to implement Debug on either T or i32/f32, and good luck with those).

> The blog explaining the author's disdain for Rust mostly just seems to whining about the borrow checker.

So? Just like monads in haskell, the borrow checker is hard until it "clicks" (and then it fundamentally shifts your understanding and it becomes hard to understand not getting it).

[0] and experience/understanding for the various possible sources of the most common ones, but that you can build for any compiler, even G++'s pages of template expansion garbage from the early aughts

Re: I Love Go; I Hate Go

#106

Post by masklinn »

nutheracc wrote: post #102
EugeneOZ wrote: post #96

> Contrast this with Rust whose errors read like mind-bindingly inscrutable tax forms. It was "lol what?" for me. Rust's compiler error messages are very informative and sometimes contains tips what to change in your code to make it work (not just general words, but code you can use right now, with your variables/functions etc.). Borrow checker explains step-by-step where ownership starts, where it ends and where you…

Yes, agreed, the Rust error messages are very helpful. Failure to understand the messages is a lack of familiarity with Rust, not a problem with the error messages.

> Failure to understand the messages is a lack of familiarity with Rust

You could have said the exact same thing of G++'s pages of template error messages. That's indictment not praise.

If you must be highly familiar with the language to understand the compiler's error messages you might as well remove the messages altogether and just print "?" as ed(1) does, developers familiar with the language obviously don't need them and beginners apparently aren't allowed to understand them so why even bother?

(good thing the Rust developer team disagrees with your vision of the subject).

Re: I Love Go; I Hate Go

#107

Post by _ak »

_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

> The most frustrating thing for me, by far, is that Go won't let you import unused packages.

If you want to explicitly import unused packages, you just prefix it with `_`, like this: https://play.golang.org/p/ltfQgco22t

Remove the `_` in the import of `crypto/rand`, and the program won't compile anymore.

Re: I Love Go; I Hate Go

#108

Post by clessg »

vertex-four wrote: post #92
dpc_pw wrote: post #49

Oh. Go love-hate relationship post. My turn. So I really like channels and coroutines built into language and used everywhere: it makes some patterns compose nicely and language very productive. But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provide…

I think that a lot of people who like Go for its channels/coroutines would like one of the BEAM VM languages - Erlang or Elixir - with its OTP. It's a bit more heavyweight, and the community is a bit smaller than Go's, but it works nicely for lots of sorts of problems. I'd keep using Go for one-off scripts (grab SSH keys from LDAP for sshd, that sort of thing) and system integration stuff, though.

> the community is a bit smaller than Go's

For now! Phoenix [0] will hopefully help turn the tide.

I switched from Go to Elixir/Phoenix a year ago and I couldn't be happier. I've used a lot of web frameworks over my decade as an engineer, and Phoenix is the first one that has remained fun to use, fast (!), and productive.

Crucially, its community has remained accepting and helpful under Jose's leadership - in contrast to the unfixably toxic Go community.

[0] http://www.phoenixframework.org/

Re: I Love Go; I Hate Go

#109

Post by EugeneOZ »

masklinn wrote: post #105
valarauca1 wrote: post #98

Earlier quoted context omitted.

This was where I stopped reading. The author clearly hasn't worked with Rust. Not only are the messages very descriptive, but you have an extended explaination for each error in the form of: rustc --explain EXXX Which pulls up a long form explaination, and code samples of what is happening/why it is happening/how to fix it. The blog explaining the author's disdain for Rust mostly just seems to whining about the borro…

> The author clearly hasn't worked with Rust. The author links to a previous post on the subject, from mid-2015, so they clearly have at least tried Rust in the past. And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good). Here's a clearer example (fixed since): http://dbeck.githu…

So are you talking about error messages or about complexity of borrow-checker? Because I can agree about borrow-checker, but not about error messages (although there is a lot of noise, yes).

Re: I Love Go; I Hate Go

#110

Post by _ak »

millstone wrote: post #75
_ak wrote: post #64

Earlier quoted context omitted.

Do you even know Go's GC guarantees?

I don't! What are they?

40 ms mutator time per 50 ms time window. That means that your program will never be interrupted for longer than 10 ms within 50 ms.

In practice, the STW mark and sweep phases are in the sub-millisecond range, and the GC runs not nearly as often as 20 times a second, so 10 ms of interruptions per 50 ms is the absolute worst case.

Post reply on HN