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

Half a decade with Go

blog.golang.org

Post reply on HN
Print view View original

201–210 of 257 posts

Re: Half a decade with Go

#201

Post by lucozade »

raverbashing wrote: post #187
killertypo wrote: post #120

Earlier quoted context omitted.

I NEED to work Go into one of my projects, but dammit I love Python so much. it is a warm and safe and comfortable cocoon. :)

Just keep in mind Go IS NOT like python, but instead it's a better C I'd say it's a better C, not a better C++ (or Java/C#)

As a language maybe but for usage, not so much.

For me, most modern uses of C fall into 3 camps:

+ extreme portability

+ complete, low level resource control

+ foundational libraries

And Go doesn't really qualify for any of these. For the latter 2 largely because of the GC.

I think in practice, that its engineering bent i.e. no frills language and high quality tooling, will more likely see it being used in the server-side application/middleware space. I guess not surprisingly.

So it really is up against Java, Python, Ruby and C++ and is, therefore, interesting in that it isn't trying to compete on lingustic goodies.

Re: Half a decade with Go

#202

Post by enneff »

lmm wrote: post #133
enneff wrote: post #111

Earlier quoted context omitted.

> expressiveness should correlate negatively with complexity I don't see why that would be true. In my experience, the most expressive languages often produce the most impenetrable spaghetti code. Can you explain your reasoning?

Consider e.g. traverse, which is a function you simply can't write in a language without higher-kinded types. Several times I've written half a page of code only to realize "that's just traverse" or "that's just foldMap" or so on. In a less expressive language I would've had to leave that half-page as is. Surely that means the expressiveness results in more readable, less complex code?

Sounds more like boilerplate or redundancy to me than complexity. Things I would call "complex" in a software system are god objects, APIs with too many options, invisible interactions between parts that appear unrelated, and so on.

Re: Half a decade with Go

#203

Post by dons »

f2f wrote: post #99
reverius42 wrote: post #90

Earlier quoted context omitted.

I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

> more code has been written in Go than Haskell, Rust and Ocaml combined.

[Citation needed]

Re: Half a decade with Go

#204

Post by samth »

tomp wrote: post #188
zzzcpan wrote: post #58

Earlier quoted context omitted.

No need to get personal. I was talking about all the features in all the languages, not the ones in Go. And yes, we don't need more new features, we have plenty. However, none of the languages I know of address psychological issues. Does type system reduce mistakes or introduce? Certainly both, don't know which one more though. But the question itself is wrong. It's not the type system who makes mistakes, humans do.…

How does a type system introduce mistakes? Unless it's unsound, of course (as is Java's and Dart's).

Java's type system is sound. There are even machine-verified proofs of this.

Re: Half a decade with Go

#205

Post by erikstmartin »

bjz_ wrote: post #128
davecheney wrote: post #69

Earlier quoted context omitted.

Go was released as an open source project on the 10th of November 2009. Which part of that is _not_ open to you in a way that Rust is ?

Go seems to be an iteration of Rob Pike's previous languages, Limbo and Newsqueak - perhaps with a sprinkling of other ideas, but not much. Rust on the other hand has been a far more ambitious project, with very lofty goals. This has meant that the Rust team has needed to do a huge amount of experimentation and iteration, culminating in the tight set of core semantics that you see in the language today. It's not been…

Rob Pike's keynote at GopherCon 2014 does a great walkthrough of the evolution of the design of the language, where ideas were borrowed from and why: https://www.youtube.com/watch?v=VoS7DsT1rdM

Re: Half a decade with Go

#206

Post by dllthomas »

kaoD wrote: post #189
diroussel wrote: post #167

Earlier quoted context omitted.

It's called structural typing.

So, compile-time duck typing.

So, wikipedia says (http://en.wikipedia.org/wiki/Duck_typing#Structural_type_sys...):

"Duck typing is similar to but distinct from structural typing. Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time."

So it sounds like "duck typing" is defined in terms of run-time semantics. I guess you might be able to have genuine "compile-time duck typing" in a dependently typed language, which could be a good reason to preserve the distinction.

Otherwise, yes, they are certainly similar.

Re: Half a decade with Go

#207

Post by tomp »

samth wrote: post #204
tomp wrote: post #188

Earlier quoted context omitted.

How does a type system introduce mistakes? Unless it's unsound, of course (as is Java's and Dart's).

Java's type system is sound. There are even machine-verified proofs of this.

Oops, you're right. I thought you could override methods with more specific argument types, but it appears I was wrong.

Re: Half a decade with Go

#208

Post by dllthomas »

latch wrote: post #186
mike_hearn wrote: post #176

Earlier quoted context omitted.

I suspect you will come to hate this feature. Just because an class happens to have a method called close() does not mean it works the same way as another class that also has a close method. An interface is much deeper than the prototypes of its methods, and pretending you can pattern match an API to whatever names a code author happened to pick is likely to lead to pain eventually ...

The very point of an interface is to decouple the caller from all the implementation specifically because it will work differently between implementation. If you expect two classes to implement it the same way, you an abstract base, not an interface. Close is a particularly good example. One need only look at C#'s IDisposable to see that it does, in fact, work well. A mock might noop it, another class might close an…

It's not just "people who use it poorly". The point of an interface is to abstract over some details while guaranteeing others. If I am unaware of an interface, I don't know to avoid the names used in that interface, and I don't know to abide by the invariants assumed in that interface. That seems like it will bite people who've done nothing wrong. If I am providing a library, I can't possibly be aware of every interface anyone might define in code that uses it. I've no clue how frequently this will occur, in practice.

Haskell's typeclasses work around this by letting you define "how a type implements an interface" at either the definition of the interface or the definition of the type. (Or, strictly, anywhere else both are in scope - but that gets messy for a few reasons, so it's discouraged and GHC warns about "orphan instances" unless you tell it not to.)

Re: Half a decade with Go

#209

Post by ansible »

coldtea wrote: post #200
cma wrote: post #194

Earlier quoted context omitted.

Python doesn't verify the interface is met until run time.

With all the cases were Go pushes you to use interface{} that's the case in Go a lot of the time too. If it had Generics that would be another thing.

With all the cases were Go pushes you to use interface{} that's the case in Go a lot of the time too.

However, you can wrap an interface{} using container (for example), with type-specific input and output functions, getting back compile-time type-checking. Yes, it is not optimal, and yes, you're still paying the price for type assertions.

If it had Generics that would be another thing.

I would like to see a good solution for this that integrates well with the rest of the language.

Re: Half a decade with Go

#210

Post by dragonwriter »

tel wrote: post #196
icebraining wrote: post #173

Earlier quoted context omitted.

available in most modern languages Well, "modern" is an ill-defined concept. As far as I'm aware, structural typing is not really that common, is it? Besides OCaml and Scala, is there any relevant (used outside of academia) language that supports it?

Haskell's typeclass provide it.

Typeclasses aren't structural typing, they are nominative typing, as typing is controlled by explicit declaration of relations between types and typeclasses, not inferred from structural properties.
Post reply on HN