skysight-inc/HackerNews huggingface dataset:
it never helps

I'm not sure how true that is and I might be able to prove it.

(1) One way it could help is: if I could get feedback about where I went astray. That's what I want to know when I'm downvoted. I don't care about a karma point, I care about learning something new.

Which makes me wonder: would it help to ask people explain why they downvoted something -- even if their username doesn't get attached to an explanation that becomes public?

(2) Here's an instance where it actually helped: [1]. Me explaining in [2] why [1] was downvoted (which was at something like -1 at the time) lead into [1] being voted again and [2] being upvoted too for clarifying the situation.

(3) This comment is aligned with HN's own request for providing feedback about what's good and bad for HN comments [3].

(4) You should be alarmed when you see a guilty word like "never" used. Particularly if you are the one using it. It's an alarm that indicates you are going to an extreme to justify a position. If what you say is evidently true, you wouldn't feel the need to try hard to qualify it. Or at least, when I made this argument in [4] people voted 20 points for it (which you dang can verify as an administrator).

(5) These arguments suggest reviewing the site guidelines and it's hard to dismiss them as useless. They could improve HN.

[1] - https://news.ycombinator.com/item?id=7285865

[2] - https://news.ycombinator.com/item?id=7288741

[3] - https://news.ycombinator.com/item?id=7605973

[4] - https://news.ycombinator.com/item?id=7565441

I fully understand if what you've discovered studying downvotes is that dealing with them differently leads into more problems than it does dealing with them with the advice of "don't post about being downvoted". I also understand if you are not willing to deal with those problems now. But saying "it never helps" sounds far fetched. You are claiming there's nothing that can be done about downvotes, ever. That's a strong claim to make, especially in a field that's only 50 years old.
Tesla Model S JSON API
I've been using Apiary to document some APIs, and it seems pretty easy to add in-line explanation in Markdown.
> IMO your data is actually worth much less than $10 because most of what advertisers are paying for is eyeballs / your attention, not your data.

The data tells them which eyeballs to target.
There's no question that Rust and Haskell have better tools than C++ for abstracting code. Go is just demonstrating that you can write great software without the aid (and cost) of generics.
Most implementations I've seen children under 18 don't get the full amount. See a lot of $15k adult $3-5k children under 18.
That map only works with keys and values both being int32, right?
>Go makes the cost of generic code explicitly visible. Generics encourage over-generalizing behavior that runs counter to writing highly performant code.

I think you may be missing some info regarding generics in Rust and Haskell. As I mentioned in the article, there is zero runtime overhead for generic programming in Rust and Haskell. Zip. Zilch. Nada. That's why their constraint-based static generics system is awesome.
> Rust, C++, Haskell, Scala will never be good at that because they're too damn complicated (although each of them make the nasty parts a little less painful!)

Why is Rust too complicated to allow you to do low-level hacking?
Hindley-Milner inferrence, operators-as-functions, and certain other features, I guess I can see arguments against (although I think they're overstated). However, I don't see any reason why generics, no null pointers, pattern matching, and certain other features would be problematic, let alone not be useful, in a language like Go. I'd be curious as to hear your justification of the claim that "a language, which throws all these features together is no longer a practical language."
"Give apps everything" and "lie to apps" is not a binary choice. There is a third option, the one iOS takes. Inform the program they don't have access to that information.

> So the phone uses more CPU and battery. It's not that big of a deal.

Battery life is very important in a phone.

> Yes, Android can tell the app that there are no photos.

It could also tell the app "You have been denied the GPS permission."

> We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?

Really? I'm not. And what if turning off GPS was accidental? I'm used to apps telling me "X won't work because GPS access has been disabled." Just breaking the experience with no way of notifying the user why their run logger stopped logging runs is not acceptable design.
I love Rust from a theoretical standpoint, it's more beautiful than Go. But Go is more practical, when it comes to getting things done with a team, it just makes more sense (maybe not for every case!)
This article presumes that everybody wants an elaborate type system. I'm not sure that is the case. I still see an elaborate type system as incidental complexity. I may be in the minority and I may not have worked in domains which benefit from such modeling. Maybe I'm stuck in a blub paradigm.

Here's my reasoning. I'm a fan of human language & domain ontologies. Word definitions are quite flexible & do not have an elaborate type system. I don't feel the need to have a provably correct logical system to have a useful conceptual tool (i.e. analogies). I enjoy ambiguity. Ambiguity can lead to paradoxes, which in turn leads to exploration & novelty.

Strongly typed systems, by default, give me the impression that the domain ontology is figured out on a highly precise level. That is never the case. You can almost always go deeper. Domain language precision is tough to model & express.

I prefer data structures to drive operations. I suppose that a schema is often useful, however I don't feel like I need the programming language to enforce the schema.

I also like to evolve the design, using tests. Tests are really examples to exercise the program's API with expected I/O.

People often equate an evolved programming language/paradigm as being better. In the case of Javascript, they point out that is was created in a few days as evidence that it's "bad". The thing about an evolved language/paradigm is it has evolved down a certain path. That often means restricting the freedom of the programmer to evolve the program down another path. I'm not picking one way to be better than another. However, I do see tradoffs to both approaches. I personally prefer a more flexible language. It can be evolved, as long as the evolution does not restrict my freedom to evolve the program.
Correct. I have to duplicate much of the code for in64 keys and values, the lack of generics hurts there.
> "It manages to be serious, not overly tendentious, and packed full of information."

Odd. I found it to be lacking in valuable information. There was no indication as to whether there had been any new manuscript discoveries (though the sidebar indicates the writings are being newly published). There was no indication as to anything particularly surprising about his views other than the era in which they occurred. "There was a guy a few centuries back who agreed with modern sexual mores, and it wasn't published because society wasn't open to it a few centuries back" doesn't strike me as a particularly valuable contribution. Obviously some people saw it as such or it wouldn't have gotten so many upvotes -- but obviously others saw it as not belonging.

> "responding to something off-topic"

It was a direct quote from the article. In fact, it was the quote from the article that I thought pushed it over the line into flagging territory.

Even so, I'm not sure why you think my response was a fast track to a flamewar. I think my response was measured and calm, clearly explaining why the comment in the original post was problematic, and furthermore adding information people might not be aware of (that Sodom wasn't following modern "not your business what consenting adults do" practice; "rape culture" was alive and well there.) I would expect people reading such a comment to come away with better understanding, and perhaps not be so quick to treat Sodom as modern/enlightened.
I mean too complicated for writing, reading, and maintaining and generally just working with from day to day. It costs too much time to do the same thing.
A Case of Uncreative Destruction
The Dark Pool Iceberg
Again, what specifically?

I ask because this has not been my experience writing several hundreds of thousands of lines of Rust code, nor has this been the experience of anyone I have helped get up to speed. Moreover, I believe there is no feature in Rust that is not necessary to achieve safety without sacrificing performance.
What's the difference between $(stuff) and `stuff`?
OpenGL 4.4 and beyond on Android
Lack of generics is part of the reason why Go is easier to learn and the Go compiler is faster than, say, Rust.

Sure, generics don't have runtime overhead in Rust and Haskell but they have other costs. You always pay for abstractions some way.
This is why more routers should have a "traffic by IP" monitoring function. It would've made troubleshooting this problem almost trivial.
36 isn't showing any progress for train tracks - they're not building any!

There's going to be light rail to South Westminster (South of 72nd), but the train tracks to Longmont are only being "researched," aren't part of this phase of construction, and are one of the reasons RTD are trying to pass an additional 0.4% sales tax.

The original concept was that the Northwest Rail project would proceed along with the other rail projects - to the point that housing developments like Steel Yards were built next to Boulder Junction in anticipation of the "coming train station." The original project plan involved running RTD and BNSF freight trains on the same shared, standard-width, diesel-powered rail line, not unlike Caltrain in the Bay. You can see that map here: http://www.rtd-fastracks.com/media/uploads/nw/2009-0715_NWR_... (stations in Red were purportedly "funded" by the 2004 tax).

That plan was scrapped for a variety of reasons: RTD couldn't come to an agreement with BNSF, they would have had to use eminent domain and pay a lot to build a rail yard, and they straight up mismanaged and ran out of money.

The new plan is that there's no plan: RTD are conducting a "Northwest Area Mobility Study" and even if an additional tax were to pass, it's unlikely we'd see a working rail line until the mid-2020s at the earliest: http://www.rtd-fastracks.com/nw_1
How exactly would a negative tax bracket work? Taken literally, this would mean that up to a certain income level, the government would pay you an amount proportional to how much you make. Presumably what it actually means is that you would be paid inversely proportional to how much you make.

At first glance it seems to me that this would have one of the same problems as the current system, which a guaranteed basic income is intended to solve - a high effective marginal tax rate at low (or no) income levels. (Unless the payment actually is positively proportional to earnings, in which case it has the obvious problem that it provides less benefit to those who need it most.)

Either way, I'm not clear on how this would be superior to a fixed guaranteed income with adjustments to the current tax rates such that the middle class end up with approximately the same after-tax total income.
Then it's not inaccurate.
I only played with this a bit, but it seemed to work well: http://900dpi.com/
You should be able to recreate that 1D scatter plot using a regular scatter plot and setting all of the y values to 0 (unless I'm missing something).
It has to apply to everyone or it doesn't work. Otherwise you would see a massive effective marginal tax level at whatever point it was cut off. (Even if ramped down, although to a lesser extent.) What could be done instead is that the entire tax structure is altered so that much of the cost of the basic income is spread over the entire middle and upper range of income tax brackets, such that the middle class end up in roughly the same situation they were before the GBI was introduced.
Obviously in extreme cases (30 lane freeways everywhere), it doesn't follow, but I was speaking of realistic changes.
> Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.

The blunt but approximately correct version is that embedded means that you're running on hardware that isn't powerful enough to run a Linux kernel.

Systems programming just means you're working below the application layer. So if you take your laptop and write a device driver, or work on filesystem or networking code, you're doing systems programming without doing embedded.
Love the site. Good job :).
> Haskell is a research language; Rust is designed to be a practical language. It makes a lot of concessions to practicality, C-like syntax and imperative control flow being high among them.

Perhaps I wasn't clear in the post you're responding to: my point was that both Rust and Haskell are fairly "simple" programming languages which seem more complicated, because they introduce a lot of features which are likely to be new to those who are using it for the first time. I wasn't really comparing them as languages per se; that's a separate discussion.

> Common in any language, including Go.

Higher-order functions are common in most languages, but not in the way that Haskell does. Most languages use first-class functions as lists of instructions (do some stuff, and perform the steps in this argument). Haskell makes them truly first-class, such that they're positively ubiquitous: an example is currying, which is everywhere in Haskell and rare in most other languages; another example is monads, which are obviously a core part of Haskell and which require first-class functions (e.g. in >>=) to do anything useful. There are other examples.

> Rust does not have these.

I know; I was speaking about Haskell.

> This is because we want memory safety without performance tradeoffs (global concurrent garbage collection).

Right; it's a perfectly understandable thing to have, but it's not something that (to my knowledge) exists in any other mainstream language. It's an example of something in Rust which is obscure to newcomers.

> Could you elaborate?

I'd have to write some code and run the compiler to get the actual error message, but I recall getting errors about using some reference outside of a context or something. In my fuzzy recollection, it would be something like where I had written `match foo { a => b; c => d}` and I would get some error message which would be fixed by writing `let foo1 = foo; match foo1 {a => b; c => d}`. Unfortunately I don't remember the specifics, but long story short: compiling Rust code produces a lot of very strange error messages to someone unfamiliar with the language. :) In this way it's not dissimilar from Haskell.

> This is because dynamically-sized types are not yet implemented, but they will be for 1.0.

Great to know! If only there were a more helpful error message than "Bare str is not a type." :)
I don't remember the version numbers, and I had gotten it wrong once before when I posted about it, but compatibility was the issue now that you mentioned it. But I guess Microsoft told people that didn't happen and I must be a liar and hence all the downvotes.
> These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen."

These languages have built-in abstraction tools (templates) that you can use to create your own abstractions. What I like about Go is the abstraction tools are primitive and allow for consistent & precise expression. The expression may not be as concise in certain cases, however, you can build in the mechanisms into your architecture.

> But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken abstraction itself too. (Anyone who has ever seen a gcc compiler error for C++ knows how this feels.)

That is why custom abstractions to your problem domain are important. A framework or a language with lots of features will get you started quickly by providing out-of-the-box tools that you can hang your program architecture on. However, I prefer to have a custom architecture & idioms which are appropriate to the current domain & evolution of the domain.
I am not following. Did you mean to reply to my comment? I made some suggestions about how someone might go about getting started in this instance. Did they make sense?
The Setup – what people use to get stuff done
As the other poster said, it was a compatibility issue from what I recall but apparently Microsoft told everyone to forget that and thus it was so.
You might want to google dereference null pointer code execution. Go regresses language design, because it allows constructs that have been proven to fail and are already fixed in other languages.

This has nothing to do with shiny features of the newest language or whether language A or B is someone's favorite. This has to do with program correctness.
Man, I'd spend days coding up RPGs with RPGMaker when I was a kid. I hope this project is successful.
This is the most motivating thing I've read all day - a 'silly' (;D) side project turning into full time work. Well done.
> In my fuzzy recollection, it would be something like where I had written `match foo { a => b; c => d}` and I would get some error message which would be fixed by writing `let foo1 = foo; match foo1 {a => b; c => d}`. Unfortunately I don't remember the specifics, but long story short: compiling Rust code produces a lot of very strange error messages to someone unfamiliar with the language.

Ah, sounds like you were using a value after it the destructor on it ran, which was fixed by moving it to a separate variable (so that the destructor ran later). This kind of error is familiar to C++ programmers, so I wouldn't say it's unique to Rust, although it's a runtime error (actually, undefined behavior) in C++ and not in Rust. A good static analysis package for C++ would emit the same error that the Rust compiler did.
I don't mean to sound like I know the best pricing scheme for ISPs but it has always seemed to me that the pricing model used for home internet makes the most sense. Once you have an infrastructure in place, the cost to send data over it is minimal, right? So, to me, paying for speed instead of an amount of data makes the most sense.
Interesting post! Many brilliant ideas I see in here. Thanks!
They should decide whether they want to bill for X amount of data transfered or X amount of bandwidth and clearly advertise the service as one or other.
programming language semantics and server availability are distinct topics. If you write a beautiful Haskell program that generates n+1 queries on a database, it will fall over. That doesn't make Haskell bad. Nine times out of ten, making a blog survive the heavy traffic of something like being on HN front page just means knowing how to cache things.
Wait. GET's can unlock my doors and honk my horn and stuff? Don't let anything spider that page of links!
The problem is your QoS won't know if the box is streaming something you want to watch right now or something being cached.

Your best solution is likely unplugging the network or powering down (I don't know if this is possible) when not in use.
YOTHEWORLD: The Simplest Charity Campaign Ever
Those have to do with the undefined nature of null pointer dereference in C. In Go, accessing a null pointer is guaranteed to produce a panic on every architecture.
Even online, emotions can be contagious
I have found this resource invaluable:

http://www.grymoire.com/Unix/Awk.html

Also, check out the sed tutorial while you are there.
Yeah that's probably right. And yes for sure I'm not only talking about things which are unique to these languages, but just things for which there might be large groups of users who are not familiar with them. Similarly, users of ML (or category theoreticians) are going to be less confused by many of Haskell's idiosyncrasies. :)
Awesome. I went to college in Denver back when the first light rail initiative tanked, and it was a nightmare to get around the city without a car. I've been back a few times since, and the transformation has been remarkable: almost everywhere I went back then is accessible by train now.

Now, if only San Francisco could follow suit and invest in greater transit -- instead of trying to increase the density of already-dense neighborhoods -- we might have a prayer of battling housing costs here. Housing density automatically happens when people can get from cheaper places to more expensive places quickly and reliably.

(Or maybe people will just leave the ridiculous bubble of the bay area, and go to places like Denver instead. Even better.)
At work, we use Google Charts to chart data, then send images of those charts to users via email, inline. We are told that this functionality will be deprecated in the API some time next year. Anyone have an idea of how to mitigate that? Emails dont support javascript so not sure how to get around this. Just for some clarity, if you happen to use Sendgrid, they do the same thing. Google chart images in an email.
I am going to throw some unsolicited critique as well, to both your critique and the site.

Bemmu,

I do agree that the aesthetic of the site did not totally give me a lot of confidence. It does look a little amateurish. Seeing the pictures of the past shipments helped up the confidence and the YouTube videos did that as well. While I only watched one video, I think you could include more branding. Throw a 3 or 4 second blurb in the beginning with just your web address and tagline, and maybe a 15 or 30 second message at the end. These videos with show up for people who do Google searches Japanese candy. That's your target market. Also include a little about the service in the video description. I think you are missing an opportunity to be able to add unobtrusive advertising.

I'd slightly disagree with icushman's take on the logo, the photography and who the service is broadcast to. I think King's "claim" on the candy logo is fleeting and probably doesn't have must effect on a customer. The "man-of-the-people candy blog" guy is exactly the sort of person I would order something like this from. I have more confidence thinking this is legit if it is a candy aficionado behind it than someone who is in it for the business aspect. Also, I think that the anime/manga vibe of the cartoon is fine. I'd think that anyone who was turned off by that wouldn't have been interested in ordering Japanese candy to begin with.

Getting back to the web site, I'd say try to highlight the testimonials from other websites more. On first pass, I missed those at the top. Highlight them more, maybe run them across the page as is the trend these days. You also ask people to subscribe before they have seen anything of what the service is.

The "Are you still active?" section implies to me there was a problem. It makes it seem as if customers are asking you questions like, "Hey, it's been a while, am I going to get a box or what" or "You had an interruption in service, did you get back up and running again?"

Finally, maybe have a section for testimonials. Maybe even have your customers send a picture of themselves enjoying the box, preferably outside in a way which shows the different parts of the world you send to. It would speak a lot to legitimacy and even community.

Either way, congrats on passing the $10K MRR threshold, you are obviously doing a lot of things right. Cheers and best of luck!
imagine if this was stuck on loop. hopefully some rate limiting is already built in.
Watch Dogs anyone?
Recruits' Ineligibility Tests the Military
I learned a lot about how a vim user thinks and works from this comment. Thank you for explaining.
Pretty sure this be a POST request.