Live data from Hacker News

Toward Go 2

blog.golang.org

221–230 of 670 posts

Re: Toward Go 2

#221

How about fixing all the GOPATH crap?

We've worked around it like this and it works pretty well: https://github.com/getstream/vg

I'm so undecided on using GOPATH like that. Though, I may just do it.

Personally I hate Go's imports, and I think the GOPATH is a terrible, terrible idea. Yet, I quite like the vendor directory, and I expect the new `dep` tool to be the final touch.

Now my only problem is that I often forget which projects of mine are in my GOPATH, so I'm afraid to delete them -_-

Re: Toward Go 2

#222

Earlier quoted context omitted.

> As a far as I can tell, an "optional type system" is > just an unsound type system with a marketing name. It is a term with a specific meaning. The key bit separating it from both gradual typing and a static type system with a dynamic type (like Scala or C#) is that in an optionally typed language, the type system has zero runtime effect. If you were to take a source file and mechanically strip out all of the type…

> To keep the guarantees you expect inside your typed code, you have to figure out how to handle untyped data that flows into it. This would be solved in a conventional static type system by forcing the user to eliminate the variant, and forcing the user to deal with the case that it has an unexpected value. So I cannot see why even C# dynamic is necessary, except to perhaps save some thinking, but this isn't a good…

The dynamic type was added to C# to facilitate interoperability (ex. DLR), not so much to encourage lazy devs to get their bugs at runtime rather than compile time.

Re: Toward Go 2

#223

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

Conversely, I would stop using Go in my projects if it introduces generics. If Go wants to be more sophisticated, there are other sophisticated languages I can use out there like Haskell, Rust, F#, Scala, etc. The problem I have learned in my career is "sophistication" usually gets in the way of getting things done because now you have all these clever developers full of hubris creating these novel implementations th…

So you'd rather take a half-dozen, half-assed implementations of templates, macros, flaky cast-to-interface things and a bunch of incompatible weirdness rathern than a singular, reasonably effective pattern that's been proven successful over literally hundreds of programming languages?

Re: Toward Go 2

#224

Generics have never stopped me from building in Go... But without them I often do my prototyping in python, javascript, or php. Working with batch processing I'm often changing my maps to lists or hashes multiple times during discovery. Go makes me rewrite all my code each time I change the variable type.

It's weird, I see these complaints so often and I just.. don't.. get it. I'm not sure what I do differently, but I'm just so used to Go's method of non-generic that I don't run into frustration at all.

The only time I even notice it is if I have to write a method like `AcceptInt(), AcceptString(), AcceptBool()` and etc.

I enjoy generics in Rust, I'm just not sure what I'm doing differently in Go that causes me to not miss them.

Re: Toward Go 2

#225

Earlier quoted context omitted.

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

Python expats needed a place to go.

I don't understand this comment - Python does what I'd argue to be the "right" thing, which is that operations which can fail raise exceptions that unwind the stack. If you don't care to handle failure in a particularly granular or graceful way (e.g., you're a command-line process, or you're a server process with lots of independent requests), you can have one large catch statement around all of your work, or even just use the implicit one around the entire program provided by the runtime.

Meanwhile, well-written C code does this the "wrong" way; every external call has to be done like

    if (read(fd, buf, len) 
Why do you think explicit error handling is a Pythonic practice?

Re: Toward Go 2

#226
post #215

Earlier quoted context omitted.

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

If it weren't for Goroutines I would not find go very useful. I expect C++ will implement coroutines and/or fibers someday that will be very well designed and more carefully/broadly thought out.

Why wait?

Coroutines: http://www.boost.org/doc/libs/1_64_0/libs/coroutine2/doc/htm...

Fibers: http://www.boost.org/doc/libs/1_64_0/libs/fiber/doc/html/fib...

Re: Toward Go 2

#227
post #95
post #6

Earlier quoted context omitted.

Not having generics makes it hard to do proper type safe functions and libraries. My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.

Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...

The strongest typed ORM I've ever used is http://diesel.rs/

This code (okay I made the use line up because it's not on the website and I'm lazy, you do need one though):

  use some::stuff::for::the::dsl;
  
  let versions = Version::belonging_to(krate)
      .select(id)
      .order(num.desc())
      .limit(5);
  let downloads = version_downloads
      .filter(date.gt(now - 90.days()))
      .filter(version_id.eq(any(versions)))
      .order(date)
      .load::(&conn)?;
is completely, statically typed, with zero runtime overhead. Generics + type inference makes sure that everything is valid, and if you screw it up, you get a compiler error (which honestly are not very nice at the moment).

Thanks to generics, all of this checking is computed at compile time. The end resulting code is the equivalent of

  let results = handle.query("SELECT version_downloads.*
    WHERE date > (NOW() - '90 days')
      AND version_id = ANY(
        SELECT id FROM versions
          WHERE crate_id = 1
          ORDER BY num DESC
          LIMIT 5
      )
    ORDER BY date");
but you get a ton of checking at compile time. It can even, on the far end of things, connect to your database and ensure things like "the version_downloads table exists, the versions table exists, it has a crate_id column, it has a num column", etc.

You can absolutely create an ORM _without_ generics, but it cannot give you the same level of guarantees at compile time, with no overhead.

Re: Toward Go 2

#228
post #127

Earlier quoted context omitted.

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

hah. It's #1 "err", #2 "if", #3 "return", #4 "nil". :)

That must be because a lot of function calls are followed by:

  if err != nil {
      return err
  }
https://stackoverflow.com/questions/18771569/avoid-checking-...

Re: Toward Go 2

#229
post #88

Earlier quoted context omitted.

Ditto on generic methods both changing the game for Dart and being necessary. I spend most of my time in Dart, Swift and ObjC, and I've built serious applications in Erlang and Java. All of which I like for different reasons. My opinion is that Dart's type system is the optimal type system. It allows for statically typed API surface, but at the same time, I can still add some dynamic voodoo under the surface and enab…

As a far as I can tell, an "optional type system" is just an unsound type system with a marketing name. Any decent static type system would allow one to progressively increase the level of typing, the weakest form being using a Variant type to hold all other types. The advantage here is that any invariants/proofs that are captured in the system are not compromised by unsoundness.

I don't think I've seen a Variant type in any language that doesn't store some form of type information at runtime (unless you count C void pointers, which I don't), and "any decent static type system" incurs no runtime overhead in the common case.

Re: Toward Go 2

#230
post #137
post #59

Earlier quoted context omitted.

C++ doesn't have generics, it has templates, which are effectively a syntax-constrained form of macros. That's why it lends itself to abuse (or creative use, depending on your take on macros).

So C++ generates separate code for each template type and C# and Java do a typecheck at compile time and reuse the same codepath for all types at runtime?

[deleted]
Post reply on HN