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

241–250 of 402 posts

Re: The State of Go

#241

Post by kibwen »

kajecounterhack wrote: post #144
nine_k wrote: post #132

Earlier quoted context omitted.

The target audience is people who don't know Elixir and Rust, have no time and not enough conceptual base to learn them in a reasonable time, and have to ship concurrent code, fast. Go is stupidly simple; this can also be an upside . Python's concurrency story is much better in 3.5+ than in 2.x, but a lot of people use 2.x for various reasons.

Turns out also that, from an organizational perspective, it can take a lot to support n+1 programming languages. A codebase with 10 languages is more difficult to maintain than one with 2 or 3. As a result I think there is large benefit to having a language like Go -- it satisfies many overlapping needs, and organizations can avoid adopting too many other languages that fulfill niche areas. At Google there are only (…

You forgot Dart and Typescript, which power AdWords and Angular respectively.

Re: The State of Go

#242

Post by cft »

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.

Re: The State of Go

#243

Post by fauigerzigerk »

danellis wrote: post #194
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.

Perhaps you could help clear up the misconception by fixing Wikipedia's 'System Programming' and 'System Programming Language' entries. It might also be worth commenting on these[0] Stack Exchange answers, too. [0] http://softwareengineering.stackexchange.com/q/151610/54726

Wikipedia says:

The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or both https://en.wikipedia.org/wiki/System_programming

By that definition it seems pretty clear that systems programming covers a lot more than just operating systems. But calling a language a systems programming language if it is unsuitable for writing operating systems seems a bit unusual. At least it would have been unusual at the time these terms were originally coined.

Re: The State of Go

#244

Post by eeZah7Ux »

cookiecaper wrote: post #118
chimeracoder wrote: post #74

Earlier quoted context omitted.

> Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I've been writing Go full-time as my primary language for nearly five years. Before that, my languages of choice were Lisp[0] and Python, with R as a very distant third choice[1]. I have always been a polyglot and enjoyed experimenting with any new language I could try out - you'd be hard pressed to name a non-esoteric la…

>If some people don't want to use Go, that's fine with me. But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, or somehow an inferior language because it lacks feature X or Y from language Z. I think such complaints are the predictable backlash that's correlated with the final stage of its hype-cycle. Tech hipsters always need a…

At the beginning of the Java and the XML hype cycles few people called that out the new toys weren't as shiny as they looked on the box. It took 10, maybe 15, years for others to catch up.

Look behind hype cycles and often you'll find $company marketing department.

Re: The State of Go

#245

Post by watwut »

baby wrote: post #177
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…

> It's not necessarily a joy to drive Go is the most fun language I've been using. On the contrary, I don't understand how some people can enjoy Java.

The thing that makes java pleasant is large open source ecosystem around it + IDE quality (meaning mostly refactoring and code navigation, especially when compared to dynamic languages). Frameworks like spring or hibernate etc are mature enough and old enough, so there is a lot to learn just by reading.

The language itself makes it easier to figure out what large code written by somebody else was mean to do - not that everything would be readable nor anything like that, but easier then say ruby or javascript.

Re: The State of Go

#246

Post by kuschku »

twic wrote: post #209
geoka9 wrote: post #184

Earlier quoted context omitted.

I see nothing wrong with that - those _are_ fatal conditions that indicate that something is dangerously wrong in the program. And those panics do give you a helpful stack trace, complete with source code line numbers, so it's easy to find the culprit (as opposed to "bubbling up" exceptions).

These uses of panic look a lot like the canonical use of unchecked exceptions in Java: the programmer has made an error, which they could have avoided. It's a bug. 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. The canonical use of checked exceptions in Java is for unpredictable events - almost always related to in…

> 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, requiring all numbers passed into the RNG to be positive), then it should be specified in the API in other ways programmatically, so it can be statically analyzed.

Re: The State of Go

#247

Post by kibwen »

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.

> O(n^k) loops

I'm unclear where algorithmic complexity is coming into this. Can you clarify what you're trying to imply?

Re: The State of Go

#248

Post by user5994461 »

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

Try these languages in order of ascending difficulty: C, assembly, Delphi, Ada, C++

After that, you'll understand that Java is on the spectrum of "easy" programming languages.

The IDEs are very helpful by the way. You only need one SDK, which is a single download.

Re: The State of Go

#249

Post by suppressingfire »

vvanders wrote: post #230
niftich wrote: post #163

Earlier quoted context omitted.

Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageo…

If its a "new environment" doesn't imply that it can't be systems programming? I totally agree that Go is fantastic for services and networked things.

i.e., distributed systems.

Re: The State of Go

#250

Post by enneff »

Hydraulix989 wrote: post #149

Why are we getting rid of OSX 10.8 and some of ARM6? Are they _really_ that much extra work to support? I have a hard time believing so.

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.

Post reply on HN