polymathist

Hey everyone, author here. Let me know if you have any thoughts or questions!

Harmony Intelligence | Mid-Senior Full-Stack Software Engineer | Remote (UTC 10pm-3am crossover) | $150k-250k + benefits + equity

I'm Alex, CTO & Co-Founder. We've just raised $3M to build a defensive AI AppSec agent to protect mission-critical software from AI cyberattacks.

You'll enjoy this role if you thrive on:

- Variety: building across the stack (mainly with Python), shaping product direction, prototyping new ideas

- Moving fast: we focus on impact, no micromanagement or politics

- Meaningful impact: on AI safety x cybersecurity

- Remote working: collab hours are best suited to APAC and North America + 2 destination offsites a year to connect

Compensation is quoted for US and AU respectively; local adjustments for other countries USA: $150k USD to $250k USD + comprehensive benefits package including health, dental, and vision insurance + equity Australia: $150k AUD to $250k AUD + superannuation + equity

Apply here https://www.harmonyintelligence.com/careers Read more here https://www.harmonyintelligence.com/harmony-raises-usd-3m-to...

Thanks for sharing and I'm excited to see what comes next!

Yes, see https://news.ycombinator.com/item?id=17305563

Yes, I've already been thinking about constraining type parameters to an interface. Internally, the type-checker considers type parameters to have underlying type interface {}. A constraint on a type parameter should be as straightforward as changing it's underlying type to a specific named interface instead of an empty one. The only tricky bit I can see is thinking about how this would work with generic interfaces or whether we should allow other kinds of type constraints (e.g., union types).

Definitely something I'm thinking about. It's one of a handful of features that I have in my head but haven't created an issue for.

The Fo compiler parses and type-checks Fo source code and then generates and outputs Go code. It generates a unique concrete type for each usage of a generic type. You can look at the examples directory of the repo to see what this output looks like: https://github.com/albrow/fo/tree/master/examples/box.

Generic interfaces are pretty fundamental IMO. It's something I plan to add to the language before the v1 release.

Parameterized packages are interesting but they come with their own problems. It can get tedious if I want to use, e.g., a stack with multiple different types. They also lose some of the flexibility that comes with scoping type parameters to any function/method/data structure.

Ply looks really cool! I can certainly understand the appeal of that kind of approach in terms of simplicity, stability, and better interop.

Local types are an edge case I'll need to spend more time working on. The type-checker won't have any problems; the real question is how to generate the appropriate Go code. One solution might be to move the local type into a higher scope during code-generation. Another might be inlining the relevant generic types in the same scope as the local type. Finally, the best solution might just be to say this sort of thing isn't allowed and the compiler will return an error.

Imports aren't supported right now, but it's one of the most important things I need to work on next. It'll be pretty tricky, but I'm confident I can find a solution.

The fortunate thing about the approach I'm using with Fo is that I have complete control over the parser, type-checker, and code-generator. At the cost of having significantly more complexity, I have the flexibility to tackle these sorts of edge cases without relying solely on existing tooling.

Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.

In a non-NN world, nothing will stop Comcast or ATT&T from also offering an "email only" plan. Except in their version of the plan, it costs $0/month if you use their own hosted email service. And when the grandkids come over they can watch Netflix for free because Netflix is paying the ISP to subsidize bandwidth.

Eliminating NN will make competition even worse for smaller and medium sized ISPs because the big ISPs have disproportional leverage to extract subsidies from media companies and make all sorts of deals. In some cases, the ISPs even own the media companies (for example, Comcast owns NBC). How can you possibly expect to compete with that?

What about the way Go handles errors today makes them not "strongly typed"?

Wow! I think it's worth emphasizing that in the given example, the time taken to install all dependencies went from 8m10s to 7.5s. Seems like a huge productivity boon for any teams working with Node.

The Moto X and its successors have had this feature for a while. Your phone can be sitting on the other side of the room, completely off, and you can say a certain catch phrase to activate Google Now.

There is a small discrepancy in the article:

> Go supports the := assignment operator, which works like this ... All this does is look at the return type of bar(), and set the type of foo to that.

This is a misunderstanding of the := operator and how type inference works in Go. If you look at the language spec (https://golang.org/ref/spec#Short_variable_declarations), you can see that the := operator is nothing more than a shorthand variable declaration.

x := "foo"

is shorthand for (and functionally equivalent to)

var x = "foo"

Type inference is orthogonal to the := operator and is a little more powerful than the author implies. For example, Go is able to infer the type of literals, including inferring the type of a numeric literal based on the presence of a decimal point or the symbol for the imaginary number, i (complex and imaginary numbers have native support). It can also infer the type when you assign a variable to an element in array, slice, or map or when you receive from a channel. Of course it can also infer types for values inside of a struct, map, slice, or array and for keys in maps. The only obvious difference I see between type inference in Go and Rust or Haskell is that in Go you must always define the return types for functions, but there may be more differences I am unaware of. See this playground example for a demo of a few different ways that types can be inferred in Go: http://play.golang.org/p/8ep340vLky.

(edit: formatting)

From the article: "Functional testing of the isolated limbs showed that electrical stimulation of muscle fibers caused them to contract with a strength 80 percent of what would be seen in newborn animals. "

I've tried the Oculus DK1 but not the DK2. They are similar in terms of resolution and tracking accuracy. There are two main differences. The DiVE is a cube-shaped room with six projected walls. So you can fit multiple people into the simulation at once (only one person gets head tracking and the proper perspective). The DiVE also had a "wand" which you could use to interact with your environment. I would bet there are similar peripherals for use with an Oculus Rift, but I haven't tried them.

The most realistic virtual reality I have ever participated in was the Duke immersive Virtual Environment (DiVE). There is a program that simulates a kitchen. There are cereal boxes, silverware, etc that you can pick up and even throw across the room. When I opened the refrigerator door, I instinctively moved my body out of the way. The crazy thing is that it's not even the best tech out there. The resolution was crappy and the physics were a little bit off. But if you stopped actively paying attention to the details, even for just a moment, it was enough to make some part of your brain think it's real. VR doesn't have to much better (if at all) in order to be really immersive.

If you're at Duke or somewhere nearby I highly recommend checking it out. They have visiting hours fairly frequently. http://virtualreality.duke.edu/

If anyone is "cheating" by setting their color to the background color, you can set Game.prototype.backgroundColor to something else in the console. Also a way to see yourself if you are the one cheating ;)

I am worried that there might be a dangerous trend in conversations about go on HN recently. There seems to be a tendency toward ad hominem comments against the go authors.

The article itself is a great read. I love hearing interesting and honest commentary about the language. But I wonder if comments like "for reasons that appear to be political, does not have integer Min and integer Max functions" are appropriate. Later the author mentions "I get a similar sense of refusal-to-engage — the authors are communicative, to be sure, but in a didactic way." If the go community (or the programming community at large) truly has the sense that the go authors are unwilling to engage with the users of the language, then that's a big problem. However, are these sort of off the cuff comments the right way to start a discussion about it? At the very least, I wish that the author would provide specific evidence for these claims. I'm sure that there is some justification for them, but what the author is telling us is his inference, and I would appreciate an opportunity to read the source material and decide for myself. FWIW I have been programming in go for 2.5 years and made a few trips to the go-nuts mailing list. I don't share the author's impression, but I also haven't read every thread on the mailing list.

That's far from the worst of it, of course. I have read comments calling the go authors arrogant, ignorant, or conceited. If you insist on criticizing the go authors, I would hope that you could at least keep it professional and provide a link to some comment/literature to back up your criticism.

I welcome criticism of go, or of any topic for that matter. I just want to avoid unfair characterization and irrelevant ad hominem comments. Am I being too defensive or do other people share this concern?