Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Golang Is and Is Not

danmux.com

Post reply on HN
Print view View original

151–160 of 279 posts

Re: What Golang Is and Is Not

#151

Post by tptacek »

sheepmullet wrote: post #146
jksmith wrote: post #78

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success. Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far? The reason why golang appears to have such wide ad…

The grass is always greener.... > easy to hire for There are 100x as many experienced C# enterprise developers. And that is being conservative.

C#, Java, and Go serve basically the same demographic and have most of the same strengths. Both Java and C# have larger ecosystems but more intellectual baggage. People without long-standing affinities to Java or C#, but who have the systems programming problems these Java-likes solve, are likely to appreciate Go, because it's simpler to pick up and use.

I think if you're proficient in one Java-like, you're single-digit weeks from being proficient in any of them, so if you're choosing your first, choose whichever one is easiest for you to go with. For a lot of Unix people coming to Java-like from Python or Ruby, that easiest choice is going to be Go: it's fully unixy but doesn't have the heavyweight runtime.

Re: What Golang Is and Is Not

#152

Post by _ak »

sheepmullet wrote: post #146
jksmith wrote: post #78

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success. Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far? The reason why golang appears to have such wide ad…

The grass is always greener.... > easy to hire for There are 100x as many experienced C# enterprise developers. And that is being conservative.

And I teach them Go in a week, or even less. I had programmers going from absolute no Go experience to deploying working, idiomatic Go code to production in 2 days.

Re: What Golang Is and Is Not

#153

Post by _ak »

xiaoma wrote: post #116
jksmith wrote: post #78

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success. Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far? The reason why golang appears to have such wide ad…

Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.

Go has only been published in November 2009. Less than 7 years is now what I would call "nearly a decade".

Re: What Golang Is and Is Not

#154

Post by AdieuToLogic »

IshKebab wrote: post #112
codygman wrote: post #28

Earlier quoted context omitted.

Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.

It may be harder to write some things, but it definitely is easier to read Go code. Besides, while the language itself may be more verbose than it could be, the standard library is extremely pragmatic and terse. It's like the opposite of the standard C++ library. E.g. to see if a string starts with another string in C++: std::mismatch(prefix.begin(), prefix.end(), toCheck.begin()).first == prefix.end() In Go: strings…

  to see if a string starts with another string in C++
As others have pointed out, while a person could use

  std::mismatch
C++'s std::basic_string type has a compare method. So, the Go example you presented:

  strings.HasPrefix(toCheck, prefix)
Could be expressed in Standard C++ as:

  toCheck.compare (0, prefix.length (), prefix) == 0;

Re: What Golang Is and Is Not

#155

Post by 20yrs_no_equity »

sergiotapia wrote: post #3

The author is quite correct. Go is super boring, and runs fast. Two great points for it. For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit. The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of c…

Having written a lot of elixir code and now spending my days writing Go code, I think of Go as a tragedy of missed opportunity. If go did concurrency correctly, the way elixir and erlang do it, it would be the language I want to use for everything (well and the pipe operator from elixir is really special.)

But concurrency in go is a terrible hack, it's just slightly better multi-threading with all the deadlocks and mutex and hassles that come with it. Channels and goroutines are not erlang processes.

That so many people think of go as a concurrent language shows how little people understand concurrent programming.

Every engineer who thinks they are decent needs to learn at least one good concurrent language (elixir or erlang would be my suggestions.)

Re: What Golang Is and Is Not

#156

Post by twic »

bluejekyll wrote: post #32
namelezz wrote: post #20

Earlier quoted context omitted.

> This is a huge improvement over Java, and something every language should have an option for. I am not sure what improvement you are talking about. Deploying Go apps requires recompiling for the target platform. On JVM, you only need to install the JVM. There are also tools to wrap JVM apps in executable files that will automatically download and install a suitable JVM.

I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments. I'm a longtime Java engineer, it's a great language, but I do think the compile once thing isn't as big an advantage anymore. With the advent of the LLVM, it's easy to target specific machines. rustup, even makes it possible to build binaries for every target environment you have. And let's be hon…

Fair enough about having to install a JVM separately. In my experience, it isn't a huge deal, but it's certainly a nonzero-sized deal.

But the classpath and jars? Write your application, 'gradle distZip', copy zip to target and unzip, invoke the launch script Gradle generated, done.

And if you can't be bothered to unzip, there's: https://github.com/pivotal/executable-dist-plugin

Re: What Golang Is and Is Not

#157

Post by 20yrs_no_equity »

leighmcculloch wrote: post #106
sergiotapia wrote: post #3

The author is quite correct. Go is super boring, and runs fast. Two great points for it. For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit. The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of c…

+100 Go is super boring and that it's a selling point. Code is a tool, not a device for entertainment. I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex features, which makes me think as I also mature as a developer I'm going to find those things less important. However, the Go version is way easier to understand. Mind you, I have very little experience with Elixir. In the interest of being…

Having a lot of experience in Elixir and Go I will say that the advantage of Elixir is not excitement, but that you can reason about your code and expect it to work. For years. Half assed go programs will crash. Half assed elixir programs can run for decades without maintenance.

Elixir is way easier to understand than Go. If you will put one week into learning it, you'll be a lot further than you are with go.

I have a couple decades of professional experience, if you are building a serious system, you want Elixir. IF you are building a devops tool, where a single binary with no install process is what's important, you want go.

But given all the containerization and distributed programming people are doing these days using go for that kinda shows to me that most engineering is done by people who don't understand distributed systems.

Re: What Golang Is and Is Not

#158

Post by randomdata »

RodgerTheGreat wrote: post #148
randomdata wrote: post #141

Earlier quoted context omitted.

To be fair, even with a well designed interface, it is difficult to see the advantage of your example over using a simple for loop: func unique(list []int) (r []int) { for i := range list { if !includes(r, i) { r = append(r, i) } } return }

It was just the first example that came to mind to illustrate the general pattern. We could also make this particular example shorter by using your naming conventions and writing it in a more functional manner instead of mutating the list: function unique(list) { return list.reduce((r, i) => r.includes(i) ? r : r.concat(i), []); } Clearer? I dunno; probably depends on the reader's background and preferences.

I still don't see what you are gaining here. Outside of code golf, the goal should not be to try and write code as short as possible, regardless of the language you are using. But this just seems to validate Pike's assertion that a for loop is more suitable to the problem.

Perhaps an example of where map/reduce is a significant improvement to the expressiveness would be appropriate for the discussion?

Re: What Golang Is and Is Not

#159

Post by _ak »

jacques_chester wrote: post #113
bad_user wrote: post #85

As some people like to point out, I'd also like to remind that in 1968 Algol had: - user defined record types - user defined sum types - switch/case statement with support for sum types - unified syntax for value and reference types - closures with lexical scoping - parallelism support - multi-pass compilation Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go deve…

The most famous writeup, discussed here when it emerged 7 years ago, was "Go vs Brand X". http://cowlark.com/2009-11-15-go/

And where is Algol now? It's dead. Theoretical superiority on paper is worth absolutely nothing when there is no usable implementation for modern computing environments out there.

This article was written to make Go look bad and unoriginal, but it inadvertently proves that Go is Algol's legitimate successor exactly _because_ it has all these features _and_ a working implementation that is available for wide variety of architectures and operating systems.

Re: What Golang Is and Is Not

#160

Post by 20yrs_no_equity »

tux1968 wrote: post #45

The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language. [*] https://www.infoq.com/presentations/Go-Google

Google is not the only entity that operates at scale, and simply because google does it does not mean it is the correct choice. That's kinda cargo cultish.

In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill your program. When that happens you have no idea why things are broken-- nothings happening.

And this is a language without a decent debugger!

Post reply on HN