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

271–280 of 402 posts

Re: The State of Go

#271

Post by enneff »

Cyph0n wrote: post #254
enneff wrote: post #252

Earlier quoted context omitted.

Can you suggest another presentation tool that makes it as easy to author and maintain slides? Nothing like this existed when Rob and I wrote present.

I'm not sure what your exact requirements were, but I immediately thought of the following: * Beamer: write slides in LaTeX, maintainable for a long time to come and easy to build. * Reveal.js: use JS and HTML to author slides, easy to present, and pretty maintainable I think. * Pandoc[1]: use Markdown or RST to write your slides, then compile to HTML (e.g., Reveal.js) or LaTeX (Beamer). * Google Slides I'm not sure…

Reveal wasn't a thing when I wrote present. I probably would have used it as a front end, had it existed.

Tools like Keynote and Google Slides were exactly the kind of thing we were trying to improve upon. They're great for making pretty slides, but a total PITA for authoring and editing technical content.

Can any of those tools execute code from within the slides?

https://youtu.be/f6kdp27TYZs?t=380

https://talks.golang.org/2012/concurrency.slide#16

And do they let us store our code snippets in actual testable (or at least buildable) source files?

Re: The State of Go

#272

Post by fnl »

knodi wrote: post #227

I think Go is an amazing lang, its simple yet powerful. I have been using it in production for over 3 years.

Mind to elaborate on what? Writing servers/services, and devops tasks, or something different?

Re: The State of Go

#273

Post by pmontra »

artursapek wrote: post #20
grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

What on earth is a "good" language? > you're clearly pitching for that vast bulk of mid-quality developers that make up the huge middle chunk of corporate devs That was actually something Google aimed for with Go, and I don't see what is shameful about it. It's a simple language on purpose. It is meant to be easily learned by any developer, and similarly Go code is meant to be easily read. Also, what sets Go apart fo…

> What on earth is a "good" language?

I've seen enough languages to make comparisons.

Some languages get in my way and slow me down as a developer. For example I'll always pick Ruby over Java if I have to deliver something quickly. However some languages get in the way of the CPU and slow it down and if that's important I'll pick Java over Ruby.

So both Ruby and Java can be good or bad languages depending on the use case. Some languages make both the developer and the CPU lose time so I won't say they are good.

I have no first hand knowledge of Go but it seems it's fast so it should be good at least where the CPU matters.

Re: The State of Go

#274

Post by strken »

artursapek wrote: post #92
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. 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.

Re: The State of Go

#275

Post by tdestan »

DrBazza wrote: post #42

Given some of the comments, I'll make the same comment I've made before: Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. I'm a C++ dev, and I really enjoy using Go. If you don't like what it does or how it does it, it's not for you. Either way, people are out there using it, making systems from it, and generally getting on with…

> Stroustrup is right, there are languages that people complain about, and languages that no-one uses.

This quote has always struck me as an intellectually lazy cop out to avoid engaging with criticism. It's an indirect appeal to the fallacy of false equivalence: "If people actually used language $Foo, surely they would complain about it just as much, because all programming languages are basically the same."

> Either way, people are out there using it, making systems from it, and generally getting on with it.

See, this argument could be used to dismiss any criticism of just about anything.

Re: The State of Go

#276

Post by MichaelRenor »

dvirsky wrote: post #236
watwut wrote: post #226

Earlier quoted context omitted.

Is there a good resource where those good transferable go idioms are written? I dont think I will have time to learn go anytime soon, but would definitely spent time with an article or something like that.

Not that I know of, but Go is super easy to learn. You will get a grip of the basics and be productive over a few hours or weekend at most, and one or two hobby projects later you'll learn to appreciate the stuff I'm talking about. BTW I've only felt I really knew the language and its inner workings and idioms deeply - after much longer, maybe a year and 2-3 big projects. But you get very productive very fast.

Not only that, but rarely am I supporting a library that I'm the sole developer on. Go takes away so much "individuality" of code. On most teams I've been on with Python and Java I can open up a file and immediate tell who wrote the library based on various style and other such. It's a lot harder with Go and that's a very good thing.

Re: The State of Go

#277

Post by enneff »

Hydraulix989 wrote: post #268
enneff wrote: post #250

Earlier quoted context omitted.

Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip doesn't support needs to be done in software, and we don't have a reliable platform for testing against ARM6.

I guess I am a bit more upset about ARM6. How were you testing before? Have you considered using an emulator? Even Linux still supports ARM6.

I don't remember the details of our testing platform, it's been a while since I've been involved in ARM6 builders.

I do remember that we used to test against emulators but they diverged significantly enough from the real hardware that we stopped using them.

Re: The State of Go

#278

Post by bitmapbrother »

tigershark wrote: post #212
oscargrouch wrote: post #147

Earlier quoted context omitted.

And those are the secret ingredients of a great language for team programming. And thats why Go will dominate the market that once was meant for Java.

I really hope not, there is already a lot of awful code around written in Java. I can't imagine codebases on the MLOC range written in a language even worse than java 1.4 (it didn't have generics, but at least it had exceptions)

There are MLOC of awful code in every language including your favorite.

Re: The State of Go

#279

Post by sidlls »

Cthulhu_ wrote: post #170
sidlls wrote: post #72

Earlier quoted context omitted.

I'm not convinced that using startups as a metric for anything programming related is a good idea. At least not startups here in the Bay Area, which seem to me to be very fad driven.

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) gain more traction and use in the future.

Re: The State of Go

#280

Post by solidsnack9000 »

watwut wrote: post #264
MichaelGG wrote: post #65

Earlier quoted context omitted.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

The loop and map are equally readable, it is just that some people are used to one form more then the other. More importantly, how many character needs to be used for simple idiom like that has zero influence on how maintainable your system is going to be few months later on, how fast it is and so on. The difference between loop and map wont make you do less or more bugs. It may make you read the code few seconds lon…

It is not necessarily easy to recognize when a loop is a map or filter -- I think that's the issue. It's why someone like McSweeney would bring it up.

The Python approach -- where maps and loops share a lot of syntax -- is maybe the middle way. On the one hand, it's not an approach that gives rise to `.map()`, `.collect()`, `.flat_map()` and so forth; on the other, it's marked out as something returning a result.

Post reply on HN