Hacker News Reader

Comment by omginternets | Hacker News Reader

I get where your coming from (I think... let me know if I've missed your point), but I think the purpose of Go's type system is to offer some safety while emulating a dynamic language.

In some cases, rigid type-safety is necessary, but I have trouble taking this criticism seriously while languages like Python enjoy extreme success. If Python can be insanely useful (and acceptably safe), then why not Go?

tl;dr: Go is not -- from a practical point of view -- a static language. (Note to pedants: I'm talking about Go's use, not it's formal nature).

Better tl;dr: Think "Python's type annotations" rather than "Rust".

View on HN

Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that.

To me, it's a replacement for Java, not C++. I think that's a reasonable target.

Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

>Then it needs to stop calling itself a 'systems programming language.'

Why must a systems programming language be static and strongly typed?

I don't mean to be flippant, but to me, 'systems programming language' means 'a language that facilitates productivity for systems programmers'. By that description, Go certainly qualifies.

>Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

Point taken, but not all system's programming requires such extreme safety.

ASM isn't strongly or statically typed, so that's obviously not a requirement for a "systems programming language".

The requirement most people mean, when they say "Go isn't a systems programming language", is the ability to acurately control execution. With Go, you can't, because of GC.

Define "systems programming" (or "systems programmer").

Google's definition seems to be "building large systems". For the types of large systems Google wants to build, Go works very well.

But others define it as "building operating systems". Go is horrible for that because of garbage collection and inability to directly access the hardware.

Ah, maybe that's the misunderstanding here.

I can't comment on "building operating systems", but it seems improbable that a GC should never be used in such endeavors.

Then good that it stopped years ago:

https://golang.org/doc/

>>> The Go programming language is an open source project to make programmers more productive.

Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. <<<

Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines

But more realistically, it makes it easier. Those things still manage to be hard at some point.

"expressive"

"concise"

"novel type system"

"flexible type system"

Just a few things that need correcting. Really ... "novel type system" ...

Ok, well that's funny. You pick "novel type system" apparently because you find it especially absurd, but I find that that's the only accurate on on the list.

Go isn't expressive, nor concise, nor does it have a flexible type system. But if any of its claims are true, it's that its type system is at least a little novel.

Sure it's not the most exotic type system out there, but its interfaces are very useful and they aren't found in many other languages (not implicitly satisfied interfaces, that is).

Go's brand of duck typing isn't exactly a novel type system.

If I had to describe Go, I'd say "I like Hoare's paper" combined with "I read the first 10 pages of the book 'my first compiler'".

> But if any of its claims are true, it's that its type system is at least a little novel.

Are you saying it's novel because it picked the worst features of past type systems? ;-)

Technically, it is indeed novel, but it's novel because making these choices was pretty dumb in the first place so nobody made them...

C doesn't have generics, and is certainly a systems language. I don't think you have a strong point here. Systems != embedded.

> C doesn't have generics, and is certainly a systems language.

C doesn't have a mandatory runtime, ubiquitous dynamic dispatch or a GC, and it lets developers decide whether to stack or heap allocate.

cmrdporcupine also isn't talking about generics, they're replying to the assertion that

> Go is not -- from a practical point of view -- a static language

C programmers use void pointers for generics. :)

And so, basically, does Go.

Except there is a fairly large difference with interface{}, in that it is typed. interface{} is more like Object in java than void* from C. If you incorrectly cast an interface{} to a type it's not, it will be a runtime error.

Details: http://research.swtch.com/interfaces

> If you incorrectly cast an interface{} to a type it's not, it will be a runtime error.

Sidenote, you may or may not have meant a panic - so i just want to clarify.

Casting an interface to a type incorrectly will not cause a panic/crash, assuming you use the proper syntax.

    // Will panic
    foo := myInterface.(BadType)
    // Will not panic
    foo, ok := myInterface.(BadType)

In the latter, you simply check if `ok` is true or not. If not, the interface value does not implement the given type/interface.

Go doesn't have casts. It has conversions and type assertions. This is a type assertion.

C has generics as of C11 via '_Generic'. Google can tell you more, and here's a blogpost with examples: http://abissell.com/2014/01/16/c11s-_generic-keyword-macro-a...

Well, yes, kind of. It's not something you would really use a lot. It doesn't help you with generic types, but only with generic functions. Since it only makes sense when coupled with macros, it really only helps with functions that are written out but accessible by the same name. For example, selecting sinf() or sin(), or writing a max() function.

No chance to replace Java, when Java is all about ecosystem, tooling, maturity and talent pool. And it has generics.

I mean I am no Java expert, but e.g Android Studio is miles ahead anything the go team will be able to ship in the next few years. And I don't think they're even focusing on building such tools since they seem to be stuck on building a debugger right now.

Java doesn't actually have runtime generics. Just type erasure syntactic sugar. ArrayList<Integer> is the same type at runtime as ArrayList<Foo>.

Sure, but I'll take it if that means I can at least use some type of generics. :)

In my experience it's decent, even if not as powerful as C++ templates. Being able to specialize containers is a basic comfort for me.

This strikes me as a distinction without a difference, in the present case. How is this meaningfully different from the programmer's perspective?

You can't distinguish them at runtime from each other.

Your memory consumption is higher, because type erasure requires elementary types to be boxed. Since the boxed value is itself allocated somewhere else, there's indirection. Indirection means CPU stalls. Another consequence is data cache pollution. There are just 512 of 64 byte L1D cache lines.

Other than that, I guess nothing.

But if you're worried about that amount of memory consumption, why are you using Java? If you need that much control over memory, Java may not be the language for you.

Ditto if you're worried about the performance hit from cache misses.

Go was never a systems programming language as soon as it made the decision to be garbage collected. Don't get me wrong: in many cases I like GC but you'll never dethrone C/C++ for many use cases with a GC language. I find it interesting that many Go pundits I speak to just don't seem to get this.

I wouldn't even say Go's target market is Java. I'd say it's actually Python. Rob Pike has spoken about this [1].

I like Python. It's fun but for anything nontrivial I've become disillusioned with it because the supposed productivity gains are offset by having to write unit tests for spelling mistakes and typos. So I like Go for this purpose. It's not quite as expressive as Python but it's in a sweet spot IMHO.

[1]: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

The Oberon and LISP machine people would disagree given they wrote whole OS's and platforms in GC languages. The trick is to support manual control & unsafe where necessary. I know it can work for Go with small changes because it worked for Wirth languages that Go was based on.

Hoping latest in type hinting along with IDE support will really kick this one home: https://www.jetbrains.com/pycharm/help/type-hinting-in-pycha...

I'd love support for "check this project" that would essentially be similar to compiling a Go project.

Python is awesome for so many things: - Quick project iteration - Web development - Testing (test suite is actually pretty sweet!) - General purpose programming and scripting

Currently, not the most productive tool for large projects or complex projects, or projects where static analysis pays huge dividends (usually this fits in one of the previous two categories anyway).

Doesn't mean it has to be: but it'd be really nice to have...

I find PyCharm addresses that Python weakness nicely. I'm sticking with C++ & Python pro tem. When Rust is a little more mature I think I'll invest.

Why do you need to write unit tests for spelling mistakes and typos in Python?

It's one class of errors that doesn't typically happen with a static compiled language, people like to feel 'safe' about the dullest things but typos can be found pretty easily by running the code you just wrote in a REPL or at least structuring your application so that you can quickly get it to the same state to test live... But honestly you can just repeat the typos in your tests, or make new ones, in any case for me at least it's a class of error that comes up very rarely regardless of whether I'm using mitigations like auto-complete. And lastly I'd think if you were unit testing "properly", aiming for good coverage, which unit testing advocates will say you must do regardless of a static or dynamic language, your unit tests should catch various typos as a side-benefit. Testing things like int in -> int out or "reading this function it calls these methods on foo, here's a mock foo and we're just going to make sure all of them get called as expected and I didn't misread/mistype either the code or the test code" seems insane.

I don't think every language needs to be rigid - something like TypeScript's gradual, unsound typing can be very valuable, and I certainly think there's a place for a language where casting is easy and idiomatic. But you can do that and still enable generics, covariance and the like - as TypeScript in fact does.

What's incredibly infuriating to see a language that clearly has everything it needs to offer generics - indeed it clearly has a generics implementation already written, since the builtin types are generic - but it won't let me use them.

Reply on news.ycombinator.com