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

291–300 of 402 posts

Re: The State of Go

#291

Post by Cyph0n »

enneff wrote: post #271
Cyph0n wrote: post #254

Earlier quoted context omitted.

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

Re: The State of Go

#292

Post by didibus »

Go's success is attributable to the fact that it is the first compiled language in a long time which is backed by a major company and has managed to deliver a simple and enriched experience compared to the old company backed compiled languages.

1. Fast compilation is a killer feature.

2. Ease of deployment, as a self contained executable (static linked), is a joy.

3. Channels are a revolutionary concept to every programmer who had only touched mainstay languages.

4. Type inference is a revolutionary concept to every programmer who had only touched mainstay languages.

5. Go's syntax is less verbose than all other earlier mainstay languages. Such as how public/private is handled through casing, and not having to type public or private.

6. Go's structural typing is a revolutionary concept to every programmer who had only touched mainstay languages.

7. Everything that's new in Go to a programmer who had only touched mainstay languages before it is not there in Go as an extra set of features, but the only thing for them to use. This greatly focuses them on learning those new features. Also, non of the features are too radical to throw them off completely.

8. All the tools for Go, are built by the team behind Go.

9. Go's battery included, and has a great selection of modern standard libs.

When compared to Java, Go lacks very little, and brings a lot to the table. Generics are probably the biggest omission, but that's probably going to make it in the language eventually.

Re: The State of Go

#293

Post by geoka9 »

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.

IDE functionality, similar to what godef/guru for Golang offer. But I'd settle on any mostly working jump-to-definition tool for Ruby/Python/Java that can be integrated with Vim/Emacs.

Re: The State of Go

#294

Post by Scriptor »

sagichmal wrote: post #238
Cthulhu_ wrote: post #165

Earlier quoted context omitted.

It does though. Maps and folds - and functional programming in general - focuses on the /what/. For-loops on the other hand tell the compiler / cpu the /how/. Summing is a nice example. A naive for-loop will just iterate through the list, keep a variable around, add the next item in the list to it. In functional programming (or with a reduce), you tell it to sum in a more concise way - but more importantly, you don't…

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?

Re: The State of Go

#295

Post by pvg »

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…

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 operating system'. By your strange definition, writing an NFS server would not be 'systems programming' because for some reason networking is excluded. I don't find this seemingly arbitrary distinction convincing either.

Re: The State of Go

#296

Post by bitexploder »

kuschku wrote: post #154
bitexploder wrote: post #73

Earlier quoted context omitted.

They probably mean you can use interface{} and create a typing black hole if you really wanted to. Otherwise, I don't know.

Or maybe they mean that you HAVE to use interface{} for any reasonable kind of generics, such as developing generic data structures, or generic handlers for RPC interfaces allowing arbitrary nesting? Even the stdlib uses interface{} everywhere now: https://tip.golang.org/pkg/sort/#Slice

Is a good point. Smells of void pointers and old school Java collections.

Re: The State of Go

#297

Post by prodigal_erik »

chimeracoder wrote: post #198
prodigal_erik wrote: post #169

Earlier quoted context omitted.

>I strongly reject the criticisms that Go is meant for "mediocre" programmers I don't know how else to describe people who don't resent being second-class citizens under the library designers, who don't insist on being able to create their own abstractions and use them with the operators that slices or maps support. The language has extensible interfaces but doesn't use them for things like iteration and equality.

> I don't know how else to describe people who don't resent being second-class citizens under the library designers... One suggestion: describe them as "people who have a different opinion than I do", rather than automatically concluding that anyone who doesn't feel the same way as you do about something must be "mediocre". There are popular languages that I can't stand writing, and languages that I think are badly d…

"How do I iterate over a slice?"

"for...range."

"How do I iterate over my own type?"

"The hard way."

"What interface can I implement to make for...range work?"

"You can't. Our types are important enough to support properly, yours aren't."

As a programmer I expect more than that, and I don't respect people who meekly agree that creating types is properly left to their betters.

Re: The State of Go

#298

Post by oscargrouch »

steveklabnik wrote: post #231
oscargrouch wrote: post #224

Earlier quoted context omitted.

For me C++ (or Rust) would be the languages to go for Browsers, VM's, Compilers, Game Engines, Glue Code for a OS(platform layer to prepare things for a app to run) etc.. The problem is, there's a lot of code in C++ already for all of this. V8, Dart, Java Vm's in C++, Webkit, Chrome, Firefox in C++, great game engines in C++. Is not that i wouldnt use Rust.. on the contrary. But the problem is, for the usecase i thin…

Cool, totally get this argument. I was mostly curious if you were thinking about something in Rust, but then found the libraries lacking, as we're trying to work on filling in gaps here.

Yes. And just to make it clear, when i say "in limbo" is actually a compliment, in a sense that i want to use it, but didnt found the right opportunity to do so.

I would be glad to be able to use Go, Swift and Rust, instead of Go, Swift and C++. Its just that i cant find a way to do so, and it has nothing to do with Rust the language, the ecosystem and the community. They are all awesome.

Re: The State of Go

#299

Post by lewisl9029 »

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…

Functions are trivially composable, while imperative loops are not. The difference that makes in terms of maintainability and readability of non-trivial applications is hard to overstate.

Writing code in terms of small, composable, reusable functions with a clear single intent (through good naming), that you can then mix, match, and reuse to compose into larger functions is what makes good functional code so much easier to write, test, and reason about than imperative code.

My favorite intro to functional programming concepts for those used to imperative coding is Sott Sauyet's Functional Programming presentation: http://scott.sauyet.com/Javascript/Talk/FunctionalProgrammin...

The presentation makes heavy use of JavaScript and the RamdaJS library in its examples, but the concepts are universally applicable to any language with the necessary functional programming primitives. It also does a great job of comparing imperative and OO implementations of a solution to a problem vs the functional implementation. I highly recommend taking a look if you're even slightly interested in why so many people are starting join the functional programming bandwagon.

So what I'm trying to say is, it's not just a matter of readability. Although if anyone still wants to argue that imperative looping is anywhere close in readability compared to functional composition for non-trivial cases (think multi-level nested loops vs composing multiple functions), then we should just agree to disagree since I don't foresee that becoming a productive discussion.

Re: The State of Go

#300

Post by s_ngularity »

mattnewton wrote: post #123
tu7001 wrote: post #100

Earlier quoted context omitted.

I don't know go, can't you write a map in it?

Not a type safe one that works on your own types.

You can't define a polymorphic function map, but you definitely could definitely define a map method for your own monomorphic container type.
Post reply on HN