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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

311–320 of 402 posts

Re: The State of Go

#311

Post by aeturnum »

omginternets wrote: post #160
aeturnum wrote: post #86

Earlier quoted context omitted.

When I think about Go in comparison to other languages, I think of car metaphors. Lots of people talk about cars that are good. Some people think a good car is fast, some people think a good car is low maintenance, some people think a good car is eye-catching. They are all right, those are all descriptors of good cars. Go, however, is like a Toyota Corolla or a Honda Civic. It's dependable, but relatively plain. It's…

>Go is a useful language, but it's a language that has purposefully stripped out all the magic. People like magic, they miss it. Agreed, and I'd further argue: 1) most people driving Ferraris aren't skilled enough to drive them properly 2) most people driving Ferraris have no need to corner at 120 MPH 3) most people driving Ferraris are just trying to show off 4) most people driving Ferraris are more likely to hurt t…

Yes, I think there are a lot of parallels between high performance cars and high performance languages. Both are held in high esteem and are frequently mis-used when a more balanced vehicle would do better.

Re: The State of Go

#312

Post by kuschku »

cube2222 wrote: post #261
kuschku wrote: post #246

Earlier quoted context omitted.

> There's no point returning an error and letting the program try to recover, just blow up with as much information as you can, so the bug can be fixed. Well, imagine a game letting the user roll a dice. "Chose a number of sides for your dice". In such cases, handling such a panic might be useful. And knowing that it exists might be useful, too. If the language does not allow specifying a range of a type (for example…

You should ALWAYS check the input you get from users. So this really wasn't a good counter argument.

As I said above, panics should ideally never be able to occur, but be part of the type system.

In languages with dependent types, for example, it’s common to represent a Stack in a way that number and type of elements are stored in the type (so you can’t even pull from an empty stack – that’d be a compile time error).

In the same way, the random number generator should either return an error, or use a number type that can only encode positive numbers as input.

Especially if combined with the interface{} everywhere across the new stdlib functions this all smells very much like C's problems.

Re: The State of Go

#313

Post by grzm »

kmicklas wrote: post #310

And yet no generics still. What a joke.

Is go something you'd like to use? Are you happy with the stack you're currently using? What is that stack?

There are clearly people who are getting things done using go, and finding generics aren't something they require. Dumping on a language you don't like is boring and gratuitously negative.

Re: The State of Go

#315

Post by Scriptor »

sagichmal wrote: post #304
Scriptor wrote: post #294

Earlier quoted context omitted.

map doesn't do any magic behind the scenes, it goes through a sequence exactly once. Can you given an example where map might increase algorithmic complexity like that where the imperative version would not?

Map hides a loop behind a statement. That's all I meant.

You can hide a loop behind a function call in Go, Python, really any imperative language.

What makes map different is that it separates the looping mechanics (incrementing, initializing and appending to the collection) from the actual computation we want to perform on each element. It's just separation of concerns.

Re: The State of Go

#316

Post by jpgvm »

sidlls wrote: post #279
Cthulhu_ wrote: post #170

Earlier quoted context omitted.

Today's startups are tomorrow's huge stack of legacy software that Nobody Wants To Touch Because It's Our Core Business though; I'd say Go is a pretty good choice for those due to its simplicity and shunning of 'clever' code. Companies like Paypal, Ebay, and probably a few others have (had?) a huge load of old Java code and only recently spent a lot of time cleaning that up (iirc Paypal went with Node, at least for i…

Today's startups are, mostly, tomorrow's failed businesses. The majority of the most successful startups of the last 15 years have generally used tried-and-true battle tested technologies in their successes: Java, C, C++ and PHP. This isn't to say Go doesn't belong in that list, but simply to reinforce my point that what startups are using today shouldn't be an indicator of high quality technology that can (or should…

And Ruby. Ruby is basically the new Java. As in it's no longer cool but is considered battletested and is now at the core of 10+ year old companies with code bases just as old that noone enjoys working on anymore.

Re: The State of Go

#317

Post by jpgvm »

jrs95 wrote: post #204
prodigal_erik wrote: post #146

Earlier quoted context omitted.

That's just a jailed process. There's no reason to need a completely different language, especially one without any specific support for running untrusted code.

Well clearly that isn't a requirement, it just so happens that Docker, rkt, and most related technologies are all built with Go. etcd even uses grpc

gRPC isn't Go specific in any way. In fact I would imagine it's main implementation would be in C++, secondly Java and then maybe Go.

Re: The State of Go

#318

Post by artursapek »

strken wrote: post #274
artursapek wrote: post #92

Earlier quoted context omitted.

> Go is a useful language, but it's a language that has purposefully stripped out all the magic. People like magic, they miss it. I agree with everything you wrote except this. After 3 years in a job where I had to use Ruby on Rails, I am utterly tired of "magic" and I regret the many hours of my life I have wasted debugging issues that were created/concealed by it. Lack of magic is a feature in my opinion. But as yo…

I find Forth, Ruby, Elixir, various Lisps, etc. almost impossible to reason about because of this. Powerful metaprogramming tools can lead to really hard to understand and hard to refactor code.

Refactoring is the worst part, so bad that people just don't do it. This naturally leads to very convoluted code bases. Ugh. Never again.

And actually, this is another place Go shines. Refactoring Go code is easy because the compiler helps you along. There's even standard tooling that automates some of it. Amazing.

Re: The State of Go

#319

Post by thewhitetulip »

spraak wrote: post #107
thewhitetulip wrote: post #52

Earlier quoted context omitted.

I agree with you, I didn't know how to build a webapp, two years ago, I learned the basics and implemented a fully working webapp in Go along with the REST client, all without having to buy a single book, the docs are amazing, the community is amazing and the language made me build things fast, I love GOPATH, I love gofmt. Apart from the tooling, I felt as if I have been writing Go since a long time, even though I wa…

I am really glad for that guide. I came across it last week and really appreciate the methodology (i.e. an anti-textbook) thank you for that.

Thank you for your kind words! I am happy that you like it, I am writing a series of guides on vi, python, git and probably bash along with their YouTube series, you can find them here http://github.com/thewhitetulip/multiversity

Re: The State of Go

#320

Post by coldtea »

pvg wrote: post #295
coldtea wrote: post #262

Earlier quoted context omitted.

"System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers" Most of those things can be summed up as "operating systems" (operating system, device drivers, and utility software, e.g. basic backend services) plus some essential supporting stuff (compiler and linker). So, yeah, it's pretty much constrained to "operating systems" and the few essentia…

So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced. It's just not a precisely defined technical term and in a computer language really has more to do with the intent and purpose of the designers and implementors and the operational context than things like 'has manual memory management' or 'must be used for writing an actual oper…

>So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced.

It's just that operating systems is not just the kernel. The POSIX userland of tools (ls, cat, ps, etc) are also systems programming, and essential part of an OS. And of course device drivers (which they even get linked or loaded directly to the kernel).

Postgres, Varnish, redis, or Apache on the other hand, or some ad-hoc enterprise backend service, is not "systems programming".

>* By your strange definition, writing an NFS server would not be 'systems programming' because for some reason networking is excluded.*

Never said that "networking is exclude". The TCP/IP stack is very much systems programming, as an example. And NFS would be too, as it's still a kind of filesystem (and thus working with the kernel and OS at a low level), and an essential part of a POSIX system.

Some load balancer for MySQL, on the other hand (one of Go's touted examples), not that much.

Post reply on HN