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

141–150 of 329 posts

Re: I Love Go; I Hate Go

#141

Post by EugeneOZ »

masklinn wrote: post #121
EugeneOZ wrote: post #109

Earlier quoted context omitted.

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

> So are you talking about error messages or about complexity of borrow-checker? Er… both? In separate sections of the comment? > Because I can [not agree] about error messages I've provided a clear example of an issue, are you denying objective reality or are you asserting that providing incorrect suggestions leading beginners in entirely the wrong direction is fine?

So you are trying to add some negative moment about borrow-checker, when my comment is not about borrow-checker, but you need something negative. Cheap trick.

Re: I Love Go; I Hate Go

#142

Post by themihai »

superswordfish wrote: post #137
themihai wrote: post #134

Earlier quoted context omitted.

You don't know what you are talking about. Have you seen any Swift backend used in production? Would you use C++ for a web API? Go was developed because C++ is a horibble language and I'm glad it didn't adopt the expressiveness and abstraction from C++.

It really depends on the project. I'd prefer Clojure or Erlang for most frontends, a Lisp for the backend of an expert system, and C++ or OCaml for any heavy lifting. Python still can be a great choice for all sorts of systems too. Swift and Rust aren't quite there yet but for a startup might be worth a look in time. We're not talking about "nobody ever got fired for choosing IBM" business here and being risk-averse…

I find swift the worst choice for a start-up right now. Why would you use a language that's only half baked? Don't you have more important things to do than porting the standard library to linux? Not to mention the lack of concurrency. Go can be a grat choice for all sort of systems too and in many cases better than any of the languages you listed. It's about using the right tool for the job and I think your comments about Go are plain ignorant.

Re: I Love Go; I Hate Go

#143

Post by mcphage »

junke wrote: post #99
laumars wrote: post #87

Earlier quoted context omitted.

> Stockholm syndrome in action. That's a very negative way of saying "that's not my personal behavioral preference" > There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghett…

> Except it does though, since that's the very behaviour you're complaining about. No, the meaning was: if someone cannot handle unused things, that someone is screwed. Go will not save him in other aspects which require a little bit of discipline and are not checked by the compiler.

> if someone cannot handle unused things, that someone is screwed.

So what you're saying is, there are two kinds of people—those who don't need the feature, and those for whom the feature isn't sufficient?

Re: I Love Go; I Hate Go

#144

Post by themihai »

clessg wrote: post #108
vertex-four wrote: post #92

Earlier quoted context omitted.

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

what about the lack of static typing?

Re: I Love Go; I Hate Go

#145

Post by runT1ME »

nutheracc wrote: post #104
superswordfish wrote: post #88

Earlier quoted context omitted.

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

I cannot imagine a scenario where Go would be a better fit for a team of skilled engineers (compared to scala). Maybe ramp up time would be the only thing, but even still the dividends you can reap from scala's more complex abstraction are worth the initial investment as they are applicable to multiple projects (as opposed to learning a complex framework or whatnot).

Re: I Love Go; I Hate Go

#146

Post by masklinn »

EugeneOZ wrote: post #141
masklinn wrote: post #121

Earlier quoted context omitted.

> So are you talking about error messages or about complexity of borrow-checker? Er… both? In separate sections of the comment? > Because I can [not agree] about error messages I've provided a clear example of an issue, are you denying objective reality or are you asserting that providing incorrect suggestions leading beginners in entirely the wrong direction is fine?

So you are trying to add some negative moment about borrow-checker, when my comment is not about borrow-checker, but you need something negative. Cheap trick.

> So you are trying to add some negative moment about borrow-checker, when my comment is not about borrow-checker, but you need something negative. Cheap trick.

Now what the hell are you talking about?

I didn't reply to your comment I replied to valarauca1, they're the one who mentioned the borrow checker, if you're unhappy about that whine to them don't include me in your pity party.

Re: I Love Go; I Hate Go

#147

Post by superswordfish »

themihai wrote: post #142
superswordfish wrote: post #137

Earlier quoted context omitted.

It really depends on the project. I'd prefer Clojure or Erlang for most frontends, a Lisp for the backend of an expert system, and C++ or OCaml for any heavy lifting. Python still can be a great choice for all sorts of systems too. Swift and Rust aren't quite there yet but for a startup might be worth a look in time. We're not talking about "nobody ever got fired for choosing IBM" business here and being risk-averse…

I find swift the worst choice for a start-up right now. Why would you use a language that's only half baked? Don't you have more important things to do than porting the standard library to linux? Not to mention the lack of concurrency. Go can be a grat choice for all sort of systems too and in many cases better than any of the languages you listed. It's about using the right tool for the job and I think your comments…

You're going after my hyperbolic recommendation (it follows "hell,") and calling me ignorant when we merely disagree. This is a waste of time.

Re: I Love Go; I Hate Go

#148

Post by _asummers »

millstone wrote: post #57
buro9 wrote: post #54

Earlier quoted context omitted.

goimports guesses the one you want and adds it back.

My question was, since goimports modifies your document (and gofmt even more so), is your undo stack preserved across saves? If so, how?

In Eclipse, this is true. The import was considered an "action" that got put into your undo stack. It was just triggered by the editor, not you.

Re: I Love Go; I Hate Go

#149

Post by masklinn »

zimbatm wrote: post #135
nneonneo wrote: post #74

Earlier quoted context omitted.

That solution (append(a[:0], a[1:]...)) doesn't look remotely performant. I don't have a copy of go handy to test, but exploding most of the list into individual arguments and passing them to a variadic function, just to pack them all back into an array, seems quite circuitous to me. Is that really the _best_ way to delete from a slice in Go?

It's because it's the wrong data-structure for the job. A slice is not sparse. If you need to delete from the middle of an ordered collection of items then it's better to use a linked or doubly-linked list (unless it's small then it doesn't matter).

> It's because it's the wrong data-structure for the job. A slice is not sparse.

So?

> If you need to delete from the middle of an ordered collection of items then it's better to use a linked or doubly-linked list (unless it's small then it doesn't matter).

Meh. Deleting from the middle of an array is one memmove, you don't get 1~2 pointers memory overhead, caches blown and having to deref' n pointers getting to the item to remove in the first place. If your language provides arrays, there are almost no cases where you should reach for linked lists without having seriously benched both cases.

And that's before the consideration that a Go linked list means loss of type safety or a hand-rolled hand-specialized implementation.

Re: I Love Go; I Hate Go

#150

Post by fauigerzigerk »

_ak wrote: post #110
millstone wrote: post #75

Earlier quoted context omitted.

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.

I think these are goals, not guarantees, and the numbers are predicated on assumptions about extra free memory available to the GC.

There is an inherent tradeoff between pauses, throughput and extra memory requirements.

Post reply on HN