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

101–110 of 279 posts

Re: What Golang Is and Is Not

#101

Post by mafribe »

catnaroek wrote: post #98
snaky wrote: post #96

Earlier quoted context omitted.

There's 1ML where those languages are are unified into one language. http://www.mpi-sws.org/~rossberg/1ml/

I'm aware of it. But my previous suggestions were in part shaped by the stated goals of Go's designers: to keep the language simple and easy to learn for non-language geeks. 1ML is really cool, but its type system can be intimidating: small vs. large types, incomplete inference, type-checking as elaboration into System F-omega, etc. OTOH, plain Damas-Milner is dead simple.

Another problem with 1ML is that it's only a research prototype for now, so we can't take it "for a spin". Given the 1ML inventor's main job, this is unlikely to change any time soon, unless some kind soul takes on the 1ML project lead.

Re: What Golang Is and Is Not

#102

Post by stcredzero »

knucklesandwich wrote: post #90
stcredzero wrote: post #84

Earlier quoted context omitted.

What they lack is the ability to let programmers introduce their own parametric types and functions, presumably because we're too dumb to be anything but consumers of this functionality. Here's what my experience is with certain features in languages: They enable some programmers to do great things, while also enabling a few programmers blinded by hubris to do maddening things. Over the life of a large project, the u…

You can make this argument with nearly anything we naturally accept as a feature of a programming language. The ability to name things has a long history of abuse. The ability to define types, implement programming patterns, define new syntactic features via high order functions, use concurrency primitives. Hell, simply the idea of programming is rife with potential for abuse. This is a narrative without specifics, a…

Hell, simply the idea of programming is rife with potential for abuse.

Exactly. Everything you add has a cost/benefit for a particular context. Evidently you disagree with how the Golang team has calculated cost/benefit with regards to generics.

Because from my perspective, being able to define parametric data types and functions is a huge win for safety and terseness of code without a lot of downside.

Terseness is a good thing? Some people say terseness is bad. Is safety the only issue or always the top priority? All production code exists in a specific context. It's best to tailor to your specific context. This may well mean that you may encounter a context where you do not want to use Go.

http://anomaly.org/wade/blog/2013/07/coding_style_terse_vs_v...

Re: What Golang Is and Is Not

#103

Post by pkroll »

snaky wrote: post #58
xyproto wrote: post #30

Earlier quoted context omitted.

Go (the language) have at least two implementations: the official Go implementation and GCC (yes, Go is included in GCC, along with Fortran and Ada). The latest Go implementation (Go 1.7) has made Go a lot faster. I would argue that it closer the speed of executables generated with GCC (gcc/g++) than OpenJDK, the Oracle JVM, Mono or the .NET compiler for C#. Go (the language) can be made just as fast as C (the langua…

> The latest Go implementation (Go 1.7) has made Go a lot faster After previous implementation has made Go a lot slower.

Two different things here: previous versions of the compiler got slower as it was moved, in automated fashion, from C to Go. Code compiled with Go was not slower. The new version of Go has both improved compile time (though not quite to the speed of the first few versions of the compiler) and improved code generation, so code is faster than any previous version of Go.

Re: What Golang Is and Is Not

#104

Post by catnaroek »

stcredzero wrote: post #95
knucklesandwich wrote: post #74

Earlier quoted context omitted.

FWIW I'm not trying to strawman the argument behind not having features like this. Rob Pike said this in a talk about Go: "The key point here is our programmers are Googlers [...] They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." I'll concede there's the possibility for…

seems to be the canonical view among gophers that Go's paucity of features is about accessibility for programmers that don't understand them or find them cumbersome to work with Please keep in mind that there are differences at scale. What is "easy to work with" for 1 programmer over a month might not be so for 20 programmers over years. The argument can't be that paucity is good as a general condition, its that ther…

> The argument is that simpler is better at scale.

Parametric polymorphism is simple and well understood. And not exactly new either: it has been understood for some 40 years already.

> I could see an argument for parametric collections and parametric sorting in Go.

C++'s header is proof that there are lots of algorithms that benefit from being expressed generically, not just sorting.

> In your experience, what kind of "cost" has there been in unsafe casting to use collections?

Without type safety, there's a disincentive for decomposing things into smaller parts, because the cost of manually verifying that the parts are compatible is greater than the benefits of decoupling them. Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones?

> Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially.

At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is still incorrect.

Re: What Golang Is and Is Not

#105

Post by piotrkubisa »

iamd3vil wrote: post #60
piotrkubisa wrote: post #51

Earlier quoted context omitted.

> You end up with significantly less lines of code that's easy to understand. That is very interesting claim, but there is something more than just tooling and number of lines of codes - a paradigm. Elixir is a functional [1] but Go is imperative [2] programming language. It changes a point in discussion quite a lot, especially when you say 'code is easy to understand'. Personally I prefer Elm over JavaScript/React,…

Go has more performance if there is some number crunching work but if it comes to APIs or web applications, I don't think so. That techempower benchmark for Phoenix is seriously flawed [3]. We use Elixir in production and according to our benchmarks, the performance is very close to Go or sometimes even better. We also use Plug (which is used by Phoenix underneath) directly if it is just a small API. These benchmarks…

Thank you for sharing results of other benchmarks with the Phoenix framework. It significantly changes perspective if we speak about Phoenix performance, but still Go has very good results [1][2] (Gin) in case of throughput, latency and consistency.

You made me curious how release 1.7 affects performance of popular routing packages for Go (Gin, Echo, Httprouter).

Re: What Golang Is and Is Not

#106

Post by leighmcculloch »

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 pragmatic, the easier code is to understand, the easier it will be to maintain, and we spend much more time maintaining code than writing it fresh.

Re: What Golang Is and Is Not

#107

Post by catnaroek »

stcredzero wrote: post #102
knucklesandwich wrote: post #90

Earlier quoted context omitted.

You can make this argument with nearly anything we naturally accept as a feature of a programming language. The ability to name things has a long history of abuse. The ability to define types, implement programming patterns, define new syntactic features via high order functions, use concurrency primitives. Hell, simply the idea of programming is rife with potential for abuse. This is a narrative without specifics, a…

Hell, simply the idea of programming is rife with potential for abuse. Exactly. Everything you add has a cost/benefit for a particular context. Evidently you disagree with how the Golang team has calculated cost/benefit with regards to generics. Because from my perspective, being able to define parametric data types and functions is a huge win for safety and terseness of code without a lot of downside. Terseness is a…

> Terseness is a good thing? Some people say terseness is bad.

Clarity is good. Clarity comes from both including every relevant detail (which pulls away from terseness) and excluding irrelevant details (which pushes towards terseness). Clarity also comes from saying everything that has to be said exactly once and no more than that (which pushes towards terseness).

Unfortunately, when you program in Go, you often have to pay attention to irrelevant details, and you have to say what you want more than once.

> Is safety the only issue or always the top priority?

The benefits of typeful programming go beyond type safety. They also include: “economy of thought”, “fearless refactoring”, “less time wasted on fixing stupid mistakes”, etc.

Re: What Golang Is and Is Not

#108

Post by snaky »

codygman wrote: post #97
snaky wrote: post #62

Earlier quoted context omitted.

If Go is from typed world, then Perl too. Some magical built-in types (scalar, array, hash, typeglob, regexp, io handle) you cannot confuse, interface{} is scalar holding a reference, and built-in datatypes (arrays and hashes) are magical and you cannot construct something similar. Well, at least there's 'tie' mechanics in Perl after all that makes types extensible.

Go is more from the typed world than Python where I came from. It will tell you at compile time you are using a string rather than an int (unless you use interface{}).

The only difference is a selection of basic types. There's just no such types as string or int in Perl, Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes objects). Although strings and numbers are considered pretty much the same thing for nearly all purposes, references are strongly-typed, uncastable pointers with builtin reference-counting and destructor invocation.

Re: What Golang Is and Is Not

#109

Post by IshKebab »

knucklesandwich wrote: post #9

Accusing other languages of suffering from paralysis of choice and fragmentation and offering "go get" as an example of solving this is truly ironic: https://github.com/avelino/awesome-go#package-management

Why? `go get` is an obvious default choice for package management. You don't have to make a choice.

There would be paralysis of choice if when you install Go you were forced to choose from that list, but you aren't.

Re: What Golang Is and Is Not

#110

Post by mixmastamyk »

codygman wrote: post #24

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

> Nim is a very good language…

Is it as good at concurrent services as golang is?

Post reply on HN