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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

581–590 of 670 posts

Re: Toward Go 2

#581

Post by steveklabnik »

weberc2 wrote: post #579
steveklabnik wrote: post #408

Earlier quoted context omitted.

> How does the compiler know the types of the database columns? There's two variants on a single way: basically, a "schema.rs" file contains your schema. You can write it out, and (with the help of migrations) it will update it when you create a new migration, or, you can have it literally connect to the DB at compile time and introspect the schema. > Also, type checking is negligible from a performance perspective,…

This is all very neat, but I think Go could do all of this too, except that "query compile time" would happen on application init or on the first query or some such. Still, very cool and good work to the diesel team!

Sure, and you get runtime errors instead of compile time errors. That's the point.

Re: Toward Go 2

#582

Post by mathw »

rbehrends wrote: post #515
mathw wrote: post #511

Earlier quoted context omitted.

Type annotations are brilliant for documentation, and it does matter if they're checked or not, because otherwise they're just comments, and we all know comments become wrong over time. If the compiler doesn't enforce your type annotations you can't trust them. The sweet spot for me at the moment is a language which is fundamentally static but has good type inference so that you don't actually have to mention types a…

> Type annotations are brilliant for documentation, and it does matter if they're checked or not, because otherwise they're just comments, and we all know comments become wrong over time. If the compiler doesn't enforce your type annotations you can't trust them. Note that I wrote statically checked. You can also check them at runtime (basically as a form of Design by Contract), which is what Dart does at the moment.

You could, but why should you spend the cycles on that at runtime when you could've done it just once in the compile phase and errored out at a useful time instead of six weeks later when you hit the one branch you neglected to write unit tests for?

Re: Toward Go 2

#583

Post by [deleted] »

slantedview wrote: post #454
treehau5 wrote: post #412

Earlier quoted context omitted.

I think this is a fair question. We have a lot of pseudo-intellectuals here that think 90% of their job isn't writing business functions. Not having generics in Go has not hindered me at all in performing the objectives of my business. Everyone wants generics, no one knows why. When I had generics in my previous two roles where I used Java and C# respectively, I can count on two fingers the number of times I needed t…

> Everyone wants generics, no one knows why This is such a troll'ish statement, but I'll respond anyways because maybe you actually are just that uninformed. Without generics any number of libraries that utilize generic function blocks - Func [1] in C#, Callable [2] in Java, etc., and do things like return the function's type parameter as a method result, would not be possible. This is exceedingly common, at least in…

[deleted]

Re: Toward Go 2

#584

Post by neurotrace »

owaislone wrote: post #318
neurotrace wrote: post #250

Earlier quoted context omitted.

I don't think anyone has been arguing against it's ease of use nor the ease of readability. Most people seem to be against it's ergonomics and intentional lack of features.

I like Go and it's intentional lack of feature or very slow speed of adding features is my favorite feature. May be I am a pseudo programmer like most people who dislike Go would probably say.

I'm not saying it's a good language or not. I haven't written in it enough to determine that. I know enough to say that anyone who says it's not a "Real Programming Language" is full of it.

Re: Toward Go 2

#585

Post by steveklabnik »

XorNot wrote: post #541
devit wrote: post #287

Earlier quoted context omitted.

Rust is probably what you are looking for. > a functional language Has closures. Has pattern matching. Has algebraic data types (however variants can't have generic parameters not present on the data type itself, but you can use trait objects to do that). Functions that don't take &mut parameters, & parameters with types with interior mutability and don't call functions that do I/O are pure (although they may not ter…

How do you get self-contained binaries with Rust? There's a lot of talk but I've not found a definitive "produces a static library" build guide.

As my sibling commentor says, they're the default. There are some details though:

Rust uses glibc by default, which must be dynamically linked. It's usually the only thing that's dynamic about Rust binaries, but it does mean that compiling on on old CentOS box is a decent idea if you want a wide range of compatibility.

Alternatively, you can use MUSL, which works like this:

    $ rustup target add x86_64-unknown-linux-musl
    $ cargo build --target=x86_64-unknown-linux-musl
Boom, now libc is statically linked too.

The default is that all Rust code is statically linked, but since you may link C code as well, that may or may not be statically linked. It's done by packages, so there's no real default. Many of them default to static and provide the option of dynamic.

That's why there's not really a guide, that's really all there is to it.

Re: Toward Go 2

#586

Post by cyphar »

herewego- wrote: post #500
cyphar wrote: post #491

Earlier quoted context omitted.

If you have a []T and you want to apply a function to make it into []K, you need to explicitly make a loop in every case. You might not think that's that bad, but note that T and K could also be interfaces such that T is a superset of K. In that case Go, T can be used as K but []T cannot be used as []K (meaning you have to do an explicit loop for something that should be an implicit type conversion). That is a trivia…

Been using it for years now in a setting with lots of data and never had any problems.

If that's true then you might not benefit from generics directly. But you will benefit from having an ecosystem of libraries that take advantage of generics. And even if you don't use other people's libraries, not everyone in the world happens to be as lucky as you and they do need generics to make their lives easier.

But again, I still severely doubt you've never run into a problem with Go's lack of generics. I ran into it after about 3 months of working with Go. Maybe you didn't find the work-arounds problematic, but that doesn't mean that the original limitation (no generics) doesn't cause problems. You just choose to accept the work-arounds as the "right way" of doing things.

If you haven't already, I would recommend looking at Rust or another modern language that has generics to see what sort of benefits you can get out of it that you can't directly get with Go. Personally the fact that if T implements an interface I won't let you use []T as []I is pretty silly IMO. Rust lets you do that with the From trait, and you can even do it even more generically with the From trait using a generic T.

Re: Toward Go 2

#587

Post by steveklabnik »

grogenaut wrote: post #424
pmarreck wrote: post #352

Earlier quoted context omitted.

Why wouldn't it, if you're pattern-matching correctly? And in any event, it seems far easier to get into that situation in Go (which ignores errors unless you explicitly check for them) than in Erlang (which crashes on every error because restarting is cheap)

My point is... "Pattern matching correctly"... assumes no mistakes on the coder's part. Go back and re-read my comment. Or don't. Downvote me because I dare question your skill in the context of the mighty erlang.

You can't downvote people who reply to you on Hacker News, so that scenario isn't possible.

Re: Toward Go 2

#588

Post by matt_kantor »

masklinn wrote: post #245
I_am_tiberius wrote: post #135

Earlier quoted context omitted.

Thanks for that information. I had thought enums can only be used as named types. Good to know they can hold data as well. I had though of that struct as well (ok, not in that professional way with types as constants and iota:-)) but found it a bit annoying that I have to store a type myself although the type itself should already have the type information somewhere itself - consequently that information is stored re…

> I had thought enums can only be used as named types. Good to know they can hold data as well. That depends on the language, and enums being sum types also depends on the language. * Rust and Swift enums are sum types (they can hold data and every variant can hold different stuff), there is also a ton of (mostly functional) languages with sum types not called enum: Haskell, F#, OCaml, … there are also languages whic…

Minor nitpick: case classes in Scala are product types, not sum types. I think you meant "sealed traits".

Re: Toward Go 2

#589

Post by slrz »

masklinn wrote: post #83
pcwalton wrote: post #70

Earlier quoted context omitted.

The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists —it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (…

> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). And even that is not the whole story, just because you reify generics does not mean you have to monomorphise everything, Microsoft's C# compiler only monomorphises value types. Also Go may box in other contexts than interfaces depending on escape analysis (according to https://golang.org/doc/faq#stack_or_heap ).

The FAQ entry does not state that the Go compiler boxes escaping variables (it doesn't, AFAICT). How did you arrive at that conclusion?

Re: Toward Go 2

#590

Post by ufo »

willtim wrote: post #551
ufo wrote: post #535

Earlier quoted context omitted.

Dart's choice of an unsound type system doesn't actually matter for those gradual typing problems we were talking about. I think you are getting too caught up in that point. Anyway, going back to the topic, I'll try to explain why your idea doesn't work. > assume a fromVariant function What I was trying to say on my other post is that you can only create such a function for primitive types (numbers, booleans, strings…

> Dart's choice of an unsound type system doesn't actually matter for those gradual typing problems we were talking about. I think you are getting too caught up in that point. I was trying to show that "gradual typing" should be possible in any reasonable static type system, without resorting to unsoundness. I do concede that there is probably a definition of the term "gradual typing" out there that I am not strictly…

> I do concede that there is probably a definition of the term "gradual typing" out there that I am not strictly adhering to.

The basic goal of gradual typing is that you can have your program be fully untyped or fully typed or somewhere in between and it will behave in a sensibly in all cases. Adding types to a program does not change the result of the program, except that sometimes adding types may cause new type errors to show up.

> the best we can do is tag it as a function, with type Variant -> Variant

This is very limiting. With this restriction, you cannot assign an accurate static type to a function with a dynamically typed implementation, which means that you can't use dynamically typed libraries from inside statically typed code.

Similarly, you cannot use statically typed objects inside the dynamically typed code because all objects that can be touched by the dynamically typed part of the code must have all their fields typed with the Variant type.

> Although the danger of this is that you have a bomb waiting to go off inside some unsuspecting piece of typed code

Technically the bomb is inside the dynamically typed part of the code :) One of the nice things you can get with a well though out gradual typing system is a guarantee that the line number in any of the type error messages will point to the dynamically typed part of the code. We call this blame tracking.

> It sounds like you are concerned with performance and efficiency, that may indeed be an issue, but it's orthogonal to the type system

Yeah, but one of the big challenges with gradual typing today is that i we try to be flexible (letting programmers add types wherever they want) and sound (with a soud type system, blame tracking, etc) all the implementations so far have had very bad performance, often running much much slower than the untyped version of the code would (with factors like 5x or 10x slower being common).

When the performance gets this bad it effectively means that your only options are to have fully typed code or fully untyped code, because almost anything in between will run up super slow. Which kind of ruins the whole point of being able to gradually add types to your program.

> Thanks for the offer, I am definitely interested.

You can get very far by searching google scholar for "gradual typing. One good place to start out would be Siek and Taha's original paper on gradual typing for functional languages[1] and Sam Tobin-Hochstadt's PHD thesis on Typed Racket[2] (which used to be called Typed Scheme back then). For an example of the challenges of gradual typing in practice, this recent paper [3] might be interesting.

[1] https://cs.colorado.edu/~siek/pubs/pubs/2006/siek06:_gradual...

[2] http://www.ccis.northeastern.edu/racket/pubs/dissertation-to...

[3] http://www.ccs.neu.edu/racket/pubs/popl16-tfgnvf.pdf

Post reply on HN