Toward Go 2 • Hacker News Board

Re: Toward Go 2

#401

Post by seabee » Thu, Jul 13, 2017, 11:28 PM UTC

kevinconaway wrote: post #138

jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> asking for monotonic time His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted. > We did what we always do when there's a problem without a clear solution: we waited The original problem described the issue and the potential consequences very well and the problem didn't change bet…

Regarding the leap second bug, I suspect this is an example of perfect being the enemy of the good.

It appeared to me that the golang devs believed so strongly in the superiority of leap second smearing that waiting for everyone to adopt it was better than compromising their API or the implementation of time.Time.

Re: Toward Go 2

#402

Post by loup-vaillant » Thu, Jul 13, 2017, 11:30 PM UTC

why-el wrote: post #367

loup-vaillant wrote: post #195

> For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. […] If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones. Not implementing generics, then suggesting that it would be nice to have examples of generics being used in the wild……

> 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. This introduces elements of dynamic typing that generics could have avoided. This has a cost, which unfortunately is hard to asses.

Second, Go users tolerate the absence of generics for some reason. Maybe they don't really need it, but then they don't have a compelling use case. Maybe they do need them, but didn't realise the limitations of the language would hurt them down the line, but are they competent enough to articulate why generics would be better? They made quite the blunder when they chose Go, after all.

That said, he also wrote this:

> For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve.

Of course he doesn't: Go doesn't have generics. Go users found other ways, thus proving they didn't really need generics. And generics users don't use Go…

Re: Toward Go 2

#403

Post by vram22 » Thu, Jul 13, 2017, 11:33 PM UTC

rbehrends wrote: post #397

hota_mazi wrote: post #312

Earlier quoted context omitted.

You seem to imply that Eiffel's solution was superior to Java's but nothing could be further from the truth. The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned…

> The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned off). This was not an inherent problem of the language, but one of the implementation. I know this because…

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

Re: Toward Go 2

#404

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

hinkley wrote: post #395

steveklabnik wrote: post #227

Earlier quoted context omitted.

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:: (&con…

I keep meaning to pick up Rust, still looking for some entry point that's interesting enough to get me off my butt. How (well) does diesel deal with migrations? I've seen other ORMs fall down the stairs trying to deal with schema modification over time.

You write raw SQL files that do exactly what you want them to do: https://github.com/rust-lang-nursery/thanks/tree/master/migr... each of these has an up.sql and a down.sql

"diesel migraiton run" will run all pending migrations, there's revert/redo as well. "diesel migration generate" can generate these files and directories for you; it doesn't yet (that I know of) have helpers to write the SQL though (like Rails does for its migrations).

On deploy, it runs the migrations first https://github.com/rust-lang-nursery/thanks/blob/master/buil...

I believe there are some interesting improvements coming down the line in the future, but for now, it works pretty well.

Re: Toward Go 2

#405

Post by kccqzy » Thu, Jul 13, 2017, 11:37 PM UTC

XorNot wrote: post #383

kccqzy wrote: post #330

Earlier quoted context omitted.

It only suggests you can't easily give an example because the language is forcing a design where such things aren't needed. Sort of like linguistic relativity.

Which still proves the parent's point: it's not necessary. The question is what absolutely can't be done without them (probably nothing) so a better question is how much design/engineering/test time could be saved with them? On the latter part I'm fairly cynical these days, since I'm presently on a team where the lead embraced a Scala-DSL heavy, functional design and the net result has been a total loss of project ve…

> what absolutely can't be done without them

Of course nothing can't be done without them. With or without generics or inheritance the language is still Turing complete.

Re: Toward Go 2

#406

Post by kccqzy » Thu, Jul 13, 2017, 11:41 PM UTC

kccqzy wrote: post #327

fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

Generics in Go: https://twitter.com/snoyberg/status/882255351382462464

It really reminds me of early C macros where people use the ## operator to synthesize monomorphized versions.

Re: Toward Go 2

#407

Post by MoOmer » Thu, Jul 13, 2017, 11:46 PM UTC

Sir_Substance wrote: post #393

43224gg252 wrote: post #382

Earlier quoted context omitted.

I know that both Java and C++ have a lot more issues than Golang ever will. I've used all three languages. Java has mile long class hierarchies, massive try-catch blocks, indentation as thick as my neck, and runs in a JVM. It's so bad there are already other implementations that people would much rather use. I also really don't like the file/project naming conventions. C++ is a whole other animal. The whole system of…

>Compared to them Go is a very well thought out and elegant language. But interestingly, not one I would choose with which to embark on a project that I expected to require more than 2000 lines of code (as a ballpark scale measurement). Go seems to be an excellent glue language. It's very suitable for making a tool that does /this/ and only /this/, putting it in a docker container and running 500 of it at once, linki…

To each their own. I've been having fun watching the progress of https://github.com/cockroachdb/cockroach && https://www.cockroachlabs.com/blog/cockroachdb-beta-passes-j...

Re: Toward Go 2

#408

Post by steveklabnik » Thu, Jul 13, 2017, 11:46 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.

> 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, so I the "zero overhead" is of minimal interest.

Ah, but it's not "the type checking is fast", it's the "diesel can generate hyper-optimized outputs that don't do runtime checks". Like, as an interesting example, Diesel can (well, will be, this has been designed but not implemented yet) actually be _faster_ than a literal SQL statement. Why? The SQL literal is in a string. That means, at runtime, your DB library has to parse the string, check that it's correct, convert it to the databases' wire format, and then ship it off. Thanks to strong generics, since the statements are checked at compile time, none of those steps need to be done at runtime; the compiler can pre-compile that DSL into postgres' wire format directly.

The reason this hasn't actually been implemented yet is that it's admittedly a tiny part of the overall time, and the Diesel maintainers have more pressing work to do. I use it as an example because it's an easier one to understand than some of the other shenanigans that Diesel does internally. It couldn't remove this kind of run-time overhead without generics.

Re: Toward Go 2

#409

Post by skybrian » Thu, Jul 13, 2017, 11:48 PM UTC

wwweston wrote: post #121

crawshaw wrote: post #5

Earlier quoted context omitted.

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough. As other respondents to the GP comment show, it's not at all…

This is frustrating. Substituting an insult for politely declining (while leaving the door open) is not "low-resolution" or "apt enough", it's almost entirely inaccurate. Politeness matters.

Re: Toward Go 2

#410

Post by rbehrends » Thu, Jul 13, 2017, 11:49 PM UTC

vram22 wrote: post #403

rbehrends wrote: post #397

Earlier quoted context omitted.

> The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned off). This was not an inherent problem of the language, but one of the implementation. I know this because…

>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 students engaged sometimes carry over into his writing.)

You don't see this approach really anymore, because these days it's so cheap to just generated unoptimized native code if compilation speed is an issue.

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). This was technology from back when CPU speed was still expressed in MHz.

OCaml had and still has both a bytecode and a native code format (for similar reason), but they cannot be mixed. OCaml's bytecode still sees use for (1) the bootstrap process, which allows you to build OCaml from scratch, (2) to run OCaml code on oddball architectures that the native compiler doesn't support, (3) to run code in the timetraveling debugger, and (4) when you need compact rather than fast executables.

OCaml's bytecode interpreter makes use of the fact that OCaml is statically typed and therefore doesn't incur nearly as much of a performance penalty as bytecode interpreters for dynamically typed languages.

[1] https://www.eiffel.org/doc/eiffelstudio/Melting%20Ice%20Tech...