Toward Go 2 • Hacker News Board

Re: Toward Go 2

#411

Post by Keats » Thu, Jul 13, 2017, 11:50 PM UTC

weberc2 wrote: post #366

steveklabnik wrote: post #259

Earlier quoted context omitted.

It can check that they match with the columns, yeah. It also heavily relies on generic types to ensure that everything is well-formed, and to provide zero overhead.

How does the compiler know the types of the database columns? That information has to come from somewhere. Also, type checking is negligible from a performance perspective, so I the "zero overhead" is of minimal interest.

There is a macro (http://docs.diesel.rs/diesel/macro.infer_schema.html) that connects to the database and builds up structs for the table in the database it's connecting to.

Re: Toward Go 2

#412

Post by treehau5 » Thu, Jul 13, 2017, 11:53 PM UTC

43224gg252 wrote: post #321

slantedview wrote: post #162

Earlier quoted context omitted.

The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.

Then why don't you come up with a legitimate use case?

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 them, and once was because a library forced me to.

Re: Toward Go 2

#413

Post by steveklabnik » Thu, Jul 13, 2017, 11:53 PM UTC

kibwen wrote: post #372

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.

> The Result type forces you to at least actively dispose of the error. Sort of: by default, an unused value of the `Result` type produces a compiler warning. Like all warnings in Rust, this category of warnings can be promoted to a hard error for all users with a single line of code. And unlike other languages where compiler warnings are uniformly ignored, there is a strong culture in Rust of making sure that code c…

I think you're thinking of Result, whereas they're thinking of Result, that is, you only get that warning if you don't care about the Ok value of the Result. If you need the value, you also need to deal with the error in some fashion.

Re: Toward Go 2

#414

Post by munificent » Thu, Jul 13, 2017, 11:55 PM UTC

ufo wrote: post #394

willtim wrote: post #181

Earlier quoted context omitted.

> 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 problem munificent was talking about is that for more complex types you cannot write that type checking predicate you want, which would check if a value belongs to the given type and return a variant-free version of the object. For example, if you have a reference to an array of integers in the typed part of the code you need to protect against untyped parts of the code inserting non-integers inside the array. Th…

This is exactly right. It's a subtle, complex problem that isn't apparent until you start really digging into these kinds of type systems. It's really hard to define the right membrane around the untyped code and values as they flow through your program into typed regions while giving you the safety and performance you expect inside the typed code.

Re: Toward Go 2

#415

Post by querulous » Thu, Jul 13, 2017, 11:56 PM UTC

XorNot wrote: post #375

pmarreck wrote: post #351

Earlier quoted context omitted.

I think the "embrace failure" supervisor model in BEAM is a superior design for mission-critical systems (such as cell networks, where it originated) while resulting in literally a ton less boilerplate. You just code the "happy path" and done. Any errors are logged and the process instantly restarted by the supervisor, you can follow up on them if they present a problem. If you were to code just this "happy path" in…

People keep saying this and I struggle to understand how this represents good design. In any language I can always just eat the error and keep going, or eat the error and restart. That doesn't fix the error, and it doesn't imply the program will work correctly.

so the argument is that there are (broadly) two classes of errors. ones that happen all the time and ones that happen hardly ever

the erlang strategy is to make it possibly to continue from a known good state when the latter happens where chances are it won't happen again. the errors that happen all the time you will encounter early/often enough that you can work out how to handle/fix them

the result of this strategy is you pretty much never write code that handles the unexpected. it turns out that's a lot of code to not have to write

Re: Toward Go 2

#416

Post by why-el » Fri, Jul 14, 2017, 12:04 AM UTC

loup-vaillant wrote: post #402

why-el wrote: post #367

Earlier quoted context omitted.

> Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously. I think you misunderstood. Clearly he meant to ask for examples from the real world that lack generics, but shows how adding them would improve the system.

> Clearly he meant to ask for examples from the real world that lack generics, but shows how adding them would improve the system. I don't think many such examples will emerge. First, you have the empty interface escape hatch. It's cumbersome, but it works. The real reason why the repeated use of this escape hatch (instead of proper generics), is lack of compile time type safety, which is replaced by dynamic checks.…

Ok, thanks for the clarification. I wonder if there are situations in big teams in which one team that uses generics can take a look at a large Go codebase within the same company and see what they think? They must have received such feedback at Google, surely?

Re: Toward Go 2

#417

Post by valarauca1 » Fri, Jul 14, 2017, 12:06 AM UTC

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…

http://www.paulgraham.com/avg.html

Re: Toward Go 2

#418

Post by rbehrends » Fri, Jul 14, 2017, 12:06 AM UTC

vram22 wrote: post #191

pjmlp wrote: post #67

Earlier quoted context omitted.

Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.

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

The key difference between Eiffel and Java generics is that Eiffel allows for covariance by design. Obviously, this is unsafe and runtime type checks had to catch these cases. The goal was originally to resolve this through additional static constraints [1], but in the end the downsides always outweighed the benefits.

In the end, Eiffel stuck with covariance and a type system that is technically unsound, because the simplicity of the type system outweighed any hypothetical gains from making it fully sound.

Practical problems with Eiffel's generics arise mostly from the fact that, like Java, constrained genericity inherently relies on nominal subtyping, which makes it less expressive than it could be.

[1] https://www.cs.princeton.edu/courses/archive/fall98/cs441/ma...

Re: Toward Go 2

#419

Post by vram22 » Fri, Jul 14, 2017, 12:14 AM UTC

rbehrends wrote: post #410

vram22 wrote: post #403

Earlier quoted context omitted.

>Also, EiffelStudio – which seems to be what you are talking about – generated C code, not C++ and had the option to generate an intermediate representation instead that could be mixed with compiled code. I think that must be what I was referring to by my mention about melting or freezing in a nearby comment. Didn't remember the technical details. Interesting feature. Wonder if other languages have something like tha…

That's EiffelStudio's Melting Ice stuff [1]. One of Bertrand Meyer's trademarks is his penchant for coming up with funny names for such features. (Edit: Reading over it again, I realize that this may be read as criticism. To clarify, while I disagree with Meyer on some things, this isn't about disagreement. He is a teacher at heart – in fact, a very good teacher – and you can see some of his habits for keeping studen…

Interesting, thanks for all the info.

>Obviously, if you have a JIT-compiler, then something similar happens internally in that some methods will be compiled, while others will be left in IR form (and sometimes, methods will even revert to using their IR).

I was going to say (in my parent comment to which you replied) that maybe that Eiffel's Melting Ice tech is something like Java JIT tech, but wasn't sure if they were the same thing.

Re: Toward Go 2

#420

Post by seanmcdirmid » Fri, Jul 14, 2017, 12:17 AM UTC

masklinn wrote: post #252

seanmcdirmid wrote: post #123

Earlier quoted context omitted.

> That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. That isn't true inside Microsoft. Many of the people who work on C# are the same academic wanks that work on Scala or F#. C# has a different…

> That isn't true inside Microsoft. No, that was not intended as included in "the C# community". Hell, SPJ used to work at Microsoft (he may still do, but he used to). > the people who work on C# are the same academic wanks that work on Scala or F# I'm sure you mean wonks, but I liked the typo. > C# has a different user base from those languages though, so they still have to be careful what they add to the language,…

Ugh, that was bad embarrassing typo.

C# has a specific audience, and the language designers cater to them pretty well. I really really like C# as a language, and I don't mind delayed access to certain features that I already like from other languages.

You probably have a beef with some C# users not because of their choice of language, but with the field they work in (primarily enterprise) tends to breed a certain kind of attitude that other techies don't like very much.