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

631–640 of 670 posts

Re: Toward Go 2

#631

Post by idobai »

di4na wrote: post #613
jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

As erlang shows, quite the contrary. If you want your code to stay up and running you should concentrate on the happy path, bulkhead and let it crash. I advice to read about Human Factors and Complex Systems engineering. You will be surprised.

> As erlang shows, quite the contrary. If you want your code to stay up and running you should concentrate on the happy path, bulkhead and let it crash.

If you want crappy software...

Re: Toward Go 2

#632

Post by vram22 »

Sean1708 wrote: post #604
vram22 wrote: post #191

Earlier quoted context omitted.

Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...

Would you mind going into a bit more depth about Eiffel's generics? It's not obvious to me from Wikipedia how they differ from normal parametric polymorphism.

Did you read this, which is linked to from my earlier link?

https://en.wikipedia.org/wiki/Generic_programming#Genericity...

I may not be able to throw more light on it than that, sorry, since I'm not an expert on these areas, just interested.

Re: Toward Go 2

#633

Post by rbehrends »

mmargerum wrote: post #623
rbehrends wrote: post #316

Earlier quoted context omitted.

Honestly, no. For starters, I don't want a functional language (at least not a purely functional one). Purely functional programming has some distinct downsides. My preferences are firmly on the multiparadigm side, and I'm perfectly happy with a reasonable imperative language (that still supports higher-order functions and closures). What I'm not happy with is language designers seemingly ignoring the state of the ar…

Sounds like Scala might be what you are looking for if multi paradigm is your thing.

Thank you, but ...

First, I'm not looking for a language. Programming languages are part of my field. I was making an observation rather than expressing a need. If there's a language that's not totally obscure or esoteric, I've probably written some serious code in it at some time.

Second, I know and use Scala (among other languages) and have done so since the 1.x versions, but the JVM dependency is too often a problem (and Scala Native is not yet mature).

Re: Toward Go 2

#634

Post by saghm »

XorNot wrote: post #532
the_duke wrote: post #148

Earlier quoted context omitted.

I have no idea why you are being downvoted. In Rust, this was handled the right way. The Result type forces you to at least actively dispose of the error. In Go, it's just way too easy to leave an error unhandled.

This seems like a no-op to me. My stack of code tools always warns me of unhandled errors (insert argument about maybe the compiler should be doing it I guess?) but I've never understood how a Result type provides any real benefit over the usual error-tuple Go uses. In both cases I have to either write a handler immediately after the call, or I'm going to fail and toss it back up to whoever called me. Errors-should-b…

> In both cases I have to either write a handler immediaitely after the call, or I'm going to fail and toss it back up to whoever called me.

The main difference as I see it is that in Rust, you can't get the success value if there's an error, so you're forced by the compiler to handle any error if there is one. With tuples, you're free to just look at one element regardless of the value of the other.

Re: Toward Go 2

#635

Post by lomnakkus »

randomdata wrote: post #625
lomnakkus wrote: post #620

Earlier quoted context omitted.

> There isn't an all encompassing 'generics'. Generics is a broad category of different ways to achieve reusable statements across varying types, in a type-safe manner. To try and draw an analogy, it is kind of like functional and imperative programming. Both achieve the function of providing a way to write programs, but the paradigms differ greatly. Each with their own pros and cons. Yes, thank you. Everybody in thi…

> Yes, thank you. Everybody in this thread already knows that. PICK ONE. They are picking one, based on the use-cases that will be given to them in the near future. I don't understand what your point is here. > Since Go is structually typed and has mutable variables, that should be a good indication of what to do and what not to do. That may be true, but the worst case scenario is that they learn nothing from the exa…

(Just to end it. I was intrigued.)

> It's almost like communication can be difficult.

We can agree about that! :)

> Where have I see that before? Hmm...

Not sure what you mean (ironically?).

Have a good night :).

Re: Toward Go 2

#636

Post by tome »

ufo wrote: post #538
willtim wrote: post #513

Earlier quoted context omitted.

I respectfully disagree. The "right membrane" around any untyped value is a Variant type. A static type system would then stop you making any assumptions without unpacking and asserting its type. If we don't want variants and just want to defer type errors until runtime, then this is possible too (GHC Haskell can do this).

GHC's Dynamic type can only contain monomorphic values, it can't handle polymorphic stuff. GHC also considers Dynamic->Dynamic and Int->Int to be incompatible types, which is not quite what one would want in a gradualy typed setting. Haskell also sidesteps the difficulties that come with mutability in a gradualyly typed setting.

> GHC's Dynamic type can only contain monomorphic values, it can't handle polymorphic stuff.

Sort of. If you wrap a polymorphic type inside a monomorphic one then it can handle it fine, for example

    data Mono = Mono (forall a b. a -> b -> a)
(But perhaps you know this)

Re: Toward Go 2

#637

Post by tome »

rbehrends wrote: post #307
willtim wrote: post #108

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. 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.

No, there's more to it. There's been some research in recent years on the actual benefits of types and the results are less straightforward than some people think. An important aspect of type annotations, for example, seems to be that they help document the API of a module, regardless of whether they're statically checked. This is especially relevant with respect to maintenance tasks. Conversely, the benefits of stat…

> There seems to be a cost associated with static types and that is that it takes longer to write code

Perhaps. As someone who has used Python and Haskell for roughly equal amounts of time in my professional career I definitely find Haskell faster to write in.

Re: Toward Go 2

#638

Post by swah »

notheguyouthink wrote: post #574
swah wrote: post #566

Earlier quoted context omitted.

I'm actually coding a LITTLE project with 7 tables and thinking if Golang was the right choice.. but I picked Golang because there is some async realtime component. My pace of dev is very slow.

What aspect is causing it to be slow for you? Note that there are definitely some areas of Go I find terrible, and SQL is one of them. Check out the SQLx library, it's far less painful than the stdlib SQL is.

Error handling, avoiding nulls, writing queries...

Re: Toward Go 2

#639

Post by tome »

geofft wrote: post #597
willtim wrote: post #271

Earlier quoted context omitted.

Of course variants would need to tag their payload, but this is what all dynamic languages need to do anyway. My point was that such dynamic behaviour can be done without resorting to an unsound "optional type system".

Isn't Dart compiled to JavaScript? As far as I can tell by playing around with DartPad, a normal int in Dart carries no runtime information indicating that it is an int (other than the fact that it is a JavaScript-level int). If you wanted to add variants to Dart, you'd either need to add this runtime information, or limit the Dart typesystem to be no more and no less than what the JavaScript typesystem already store…

Surely JavaScript itself tags ints?!

Re: Toward Go 2

#640

Post by geofft »

tome wrote: post #639
geofft wrote: post #597

Earlier quoted context omitted.

Isn't Dart compiled to JavaScript? As far as I can tell by playing around with DartPad, a normal int in Dart carries no runtime information indicating that it is an int (other than the fact that it is a JavaScript-level int). If you wanted to add variants to Dart, you'd either need to add this runtime information, or limit the Dart typesystem to be no more and no less than what the JavaScript typesystem already store…

Surely JavaScript itself tags ints?!

It tags numbers, yes, but actually it doesn't tag ints in particular - there is no integer type in javascript, just a 64-bit floating point one. (This is why asm.js code sticks |0 after every arithmetic operation involving integers: that forces rounding the number as if it were an integer, and therefore allows optimizing the expression to use integer instead of floating-point arithmetic.)

If Dart wants to distinguish ints and doubles, it needs to keep track of that on its own; if it has a JavaScript variable x and needs to know calculates x/2, it won't know whether to round it as if it were integer arithmetic, or return a floating-point value. Usually it is enough to do this at compile time (the function calculating x/2 knows whether it's halving a Dart-level double or a Dart-level int), and so there's no need to make x an object that remembers its own Dart type.

Also, even if JavaScript distinguished ints and doubles, a higher-level language is likely to want to have multiple kinds of things with an int representation: bools, enums, bitfields, Unicode scalar values, etc. Again, ideally that information is tracked at compile time and the knowledge of what to do with an int representation is inserted into the compiled code, and so no metadata needs to be stored at runtime.

Post reply on HN