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

301–310 of 402 posts

Re: The State of Go

#301

Post by enneff »

Cyph0n wrote: post #291
enneff wrote: post #271

Earlier quoted context omitted.

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

> Can any of those tools execute code from within the slides? > And do they let us store our code snippets in actual testable (or at least buildable) source files? Not that I'm aware of, no. That's a pretty cool feature actually! As you kindly said, Reveal.js may probably work for you as a frontend for your tool.

Those features were the impetus for the tool, and as far as I'm aware they were Not Invented Anywhere at the time. :-)

Re: The State of Go

#302

Post by XorNot »

Groxx wrote: post #151
cdelsolar wrote: post #148

Earlier quoted context omitted.

You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.

At which point you're back to the original complaint of: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) (except for "- Should I throw a checked or unchecked excep…

I feel like the type system is involved? If there's a problem it's that Go doesn't make throwing typed errors a common convention (and we lack the tooling to make handling them a habit I.e. inspect this call and find me all the error types which can come back.

Re: The State of Go

#303

Post by oscargrouch »

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)

"bussiness" languages will never change. It will be Cobol, Java, C#, Go, and then something like that in the future.

The truth is, theres not enough smart people to do things in the hundreds or thousands in a more sophisticated language.

And also speaking of smartness, sometimes, using simple tools, can help you focus on algorithms. Linus and crew coded the whole Linux in C, a language with very few resources, and considered pretty ugly by today's standard.

So i can see the beauty of that, even when you are able to use any sort of more sophisticated language, sometimes chosing something that can be shared with more people can pay off, instead of a more "elitist" language, with a higher barrier of entry. And also lets not forget, that theres always some economics at play. Where companies not focused in IT will choose tech that can scale by the number of employees, do its job and be cheap as possible.

I think there will be no antidote for that. It will always be some reincarnation of Java.

Re: The State of Go

#304

Post by sagichmal »

Scriptor wrote: post #294
sagichmal wrote: post #238

Earlier quoted context omitted.

Yes, that's exactly right. And Go takes a relatively strict stance on making the _how_ obvious to the programmer. It goes out of its way to avoid hiding O(n^k) loops behind language sugar like map or fold, for example.

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.

Re: The State of Go

#305

Post by sidlls »

solidsnack9000 wrote: post #282
sidlls wrote: post #70

Earlier quoted context omitted.

Maps and folds are implicit loops. For some explicit is simpler.

Loops are just implicit goto... The argument for maps and folds is the same as the argument for structured programming in general: using common/reusable idioms brings clarity and familiarity.

Terseness doesn't necessarily bring clarity.

Re: The State of Go

#306

Post by [deleted] »

solidsnack9000 wrote: post #282
sidlls wrote: post #70

Earlier quoted context omitted.

Maps and folds are implicit loops. For some explicit is simpler.

Loops are just implicit goto... The argument for maps and folds is the same as the argument for structured programming in general: using common/reusable idioms brings clarity and familiarity.

[deleted]

Re: The State of Go

#307

Post by ovidnis »

solidsnack9000 wrote: post #287
geoka9 wrote: post #105

Earlier quoted context omitted.

To each their own, but Go is probably the only mainstream language that has first class integration with text editors. So I wouldn't let that stop me from using it, unless you can't see yourself using a text editor at all.

What is the first class integration? My experience using Ruby, Python and Rust (via Racer) with Vim+Syntastic has been pretty good.

In my Emacs I've got 1) eldoc (displaying signature of function at point), 2) function source lookup, 3) function documentation lookup, 4) flycheck (display compiler err/warn on save), 5) auto-completion. Among a few other things like go-guru integration which I haven't used much yet but I can see its use.

All of those features come from editor agnostic golang tools.

Re: The State of Go

#308

Post by mindcrime »

coldtea wrote: post #262
pvg wrote: post #225

Earlier quoted context omitted.

Why would I? They support what I said directly - 'system programming' is not limited to operating systems. Here's a bit from one of the Wikipedia entries you mention. "System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software is computer software designed to operate and control the computer hardware, and to p…

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

In my experience, pvg is correct. It's been ages since "systems programming" was limited to just "operating systems" from what I can see. I don't know anybody who wouldn't refer to writing middleware or network servers as "systems programming".

Re: The State of Go

#309

Post by mindcrime »

andrewprock wrote: post #208
pvg wrote: post #166

Earlier quoted context omitted.

I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.

Given Pike's extensive experience inside a world of his own making (Plan 9 and Go), it's entirely reasonable to attribute the misconception that Go is a system language to Pike's idiosyncratic use of the phrase. If I understand things correctly, Go came about as fallout related to the non-scalability of Python and the massive technical debt associated with Python within Google. The projects to automagically port Pyth…

Pike's idiosyncratic use of the phrase.

There's nothing idiosyncratic about it. "Systems Programming" has meant a lot more than just "operating systems" for at least as long as I've been doing this stuff, which dates back into the 90's. Maybe in some earlier age it was the case that "Systems Programming" was limited to "operating systems" but if so, it was quite some time ago. Language evolves...

Post reply on HN