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

251–260 of 402 posts

Re: The State of Go

#251

Post by XorNot »

Groxx wrote: post #98
skybrian wrote: post #83

Earlier quoted context omitted.

The preference for maps and folds looks like a fad to me. I can use them but I don't think it makes the code any easier to understand, just different.

I dunno, ruby has some nice tendencies here, like `out = [1,2,3].map(&:to_s)` which is small and descriptive[1]. Compare that to: out = [] [1,2,3].each do |x| out.append(x.to_s) end IMO that's not fad material - that's progress. Maps and folds can totally be abused to produce inscrutable nonsense, but for small, common operations they're often much more obviously-correct. [1]: `&:method_name` is extremely-common shor…

I had no idea what you were trying to do in the first paragraph whereas without knowing much ruby I can easily read the intent of the second.

Re: The State of Go

#252

Post by enneff »

Cyph0n wrote: post #119
shurcooL wrote: post #106

Earlier quoted context omitted.

It's `present`, a very simple tool. Written in Go, open source. Using it is a choice. I agree its ability to work on mobile is limited and that could use a CL (or a few) to improve. https://godoc.org/golang.org/x/tools/cmd/present

A beautiful example of NIH syndrome in the real world.

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.

Re: The State of Go

#253

Post by calcifer »

cetxcz wrote: post #129
niftich wrote: post #75

Conversion rules seem like an awfully specific language feature to introduce just to scratch a very particular itch. The rest of the slides are pretty standard-fare, and that's a good thing. Would've liked a reference to the lack of monotonic time, though; either an acknowledgment that it's a problem (because it's now fairly widely known), or a mention that a new proposal to fix it [1] is in the works. [1] https://ne…

The conversion feature is in fact very convenient. We often keep different types for what we get from the user (JSON) and what we write on the database (e.g: BSON). Having the ability to convert between them without having to re-type everything is useful for a lot of code out there.

To be fair, you can do that right now with unsafe.Pointer, but of course it's better to have a compile time checked version of it.

Re: The State of Go

#254

Post by Cyph0n »

enneff wrote: post #252
Cyph0n wrote: post #119

Earlier quoted context omitted.

A beautiful example of NIH syndrome in the real world.

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 if any of these (except Beamer) were available back when you wrote the tool, but given some of the complaints in this thread (e.g., not mobile-friendly), wouldn't it make sense to migrate to some other tool going forward?

[1]: Absolutely fantastic tool all-round, and written in Haskell to top it off. I used it a few years back to write a LaTeX report in Markdown. It's definitely not as good as writing LaTeX directly, but it's a great place to start. I can't praise Pandoc enough.

Re: The State of Go

#255

Post by systems »

dvirsky wrote: post #162
hota_mazi wrote: post #150

Earlier quoted context omitted.

> When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. This is probably more due to the fact that you moved from a dynamically typed language to a statically typed one rather than this new language itself.

But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now. Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back s…

i think a couple of years of experience and learning a new language .. was a far bigger factor than any intrinsict characteristics of go

Re: The State of Go

#256

Post by watwut »

jankiel wrote: post #79
user5994461 wrote: post #60

Earlier quoted context omitted.

Of course I mean ruby on rails when I say ruby. Initial release 2005. i.e. Young.

Ruby on Rails is a web framework, not a language. Also web dev is about shipping a product fast, that's why you don't see Java there.

Once you know whatever java framework well enough and your project is not something ruby on rail spits out immediately, shipping fast is not a problem. In 4 months timeframe, you can definitely produce more or as much as with node.js or something like that.

The issue is that you wont do good frontend in it (obviously), java programmers are more expensive, learning it well enough so that you can actually be that fast takes a lot of time and hosting is way more expensive. Learning language itself is easy, but absorbing necessary frameworks takes time. Moreover, people who are good in frontend prefer languages similar to javascript, because they already know it very well so those are easier to learn for them.

I think this is why it does good in enterprise - they have money to throw at hardware, most projects are under huge time pressure constantly and requirements change constantly. Frontend is super important for product, but not so much for enterprise.

Re: The State of Go

#257

Post by watwut »

baby wrote: post #178
user5994461 wrote: post #43

Earlier quoted context omitted.

Java reigns supreme because there is nothing which come close to its characteristics in terms of capabilities, libraries supports, tooling, performances, easiness to learn, simplicity and maturity. If you want faster or lower level, you gotta move to C++, which is uber-hardcore in terms of non-simplicity and impossible-to-learn. If you want easier, you gotta move to python/ruby/node.js, which are a joke in terms of p…

How is Java easy to learn, you need a huge IDE, I don't know how many SDKs or dependables and two pass compilation and 1000 layers of abstraction, ...

Ide makes learning easier and faster instead of harder. You dont have to care about compiler passes, ide compiles seamlessly.

But yeah, learning java ecosystem well enough takes a lot of time for someone who is just starting and you have to be comfortable with abstract thinking.

Re: The State of Go

#258

Post by YZF »

Most of my work is C++ but I've also used Go a fair bit since Go 1.5. I like Go a lot. The C++ crowd (including myself) keeps trying to make things that are trivial in Go easier in C++ but the best efforts still look like a mess. I think the lightweight/green threads model of concurrency wins over others (threads, processes) and is incredibly difficult to get right in C++. Channels are also very useful and difficult to get right in C++. While C++ with some aid from Boost can be a very safe language it ends up being a lot harder to write and read with all sorts of [](){} -> hacked up conventions that are a result of backwards compatibility. I find the test infrastructure in Go to also be very pleasant and easy to use. Stuff you need to go to extremes of C++ to test are just trivial to do in Go.

Things I would like to see improved:

- Package management. I think "go get" was an interesting idea that is basically a fail for anything except the most trivial of situations. Vendoring is not a great solution either IMO. Perhaps some idea that manages package versions through local git repositories can work better since a git repository is a better representation of the version history of packages.

- I didn't like the compile speed loss we took when the compiler code base moved to Go. I'm not quite sure where it stand right now but one of the things that I liked about Go from the beginning is lightning quick builds.

- In my usage there seem to a few quirks in the language including the various scoping weirdness and the declare and assign operator := ... I frequently end up with code that re-uses the same variable such that the first instance is := and the next are = which makes refactoring a pain. The compound if statement also suffers from this.

The uppercase/lowercase public/private convention is also odd. You get used to it but it seems like a hacky afterthought.

Re: The State of Go

#259

Post by fnl »

cft wrote: post #242

Go is better for applied tasks. Currently there is no faster way to write or simpler language than Go to write a highly scalable internet server that can handle 100-1000k concurrent clients on the commodity hardware. I suspect this applies to some big data analysis tasks in bioinformatics, that can be parallelized.

As a bioinformatician, I can tell you: no. Hardly anywhere you have that concurrency need. You have a few clients only, typically, but with very highly parallel work-loads (as opposed to concurrent ones). Go is a bad for there.

Re: The State of Go

#260

Post by spraak »

yawaramin wrote: post #188
spraak wrote: post #121

I'm yearning for the Golang of functional programming. That is, excellent std lib, clear documentation, awesome tooling, active community.. and after typing this, maybe that's Elixir? Though I do love static typing.

You may be interested in https://facebook.github.io/reason/ They have an active community that is very engaged in improving the entire developer experience. Plus ReasonML is just OCaml under the (new syntax) hood so you have decades of OCaml expertise and libraries to draw on. In case that's not enough, it also deploys to JavaScript and targets the npm ecosystem, so you also have the entire npm package collection at…

Wow, thanks very much for sharing that!
Post reply on HN