skysight-inc/HackerNews huggingface dataset:
I very much want a Facebook for coding friends clone.

Lots of solutions out there but I for whatever reason I don't like any of them

Slack/Discord and similar interfaces are effectively chat. I want topics and replies. I know you can start a topic on both of those but it just feels less conducive to friends talking to me than talking on Facebook.

I could make groups on facebook. I can't put my finger on why this doesn't work. Maybe because it requires diligence. I have to remember to select the group of "programmer friends" that I want to topic to go to. Forget and my either my programmer friends get family posts or my family gets programmer posts. Also FB will spam non-programmer friends with "g posted about x over here".

A forum like discourse or phpbb doesn't have to social graph. Anyone that joins can participate in all discussion. I want to talk to friends only

Google+ and some features that seemed to kind of go in this directly but I feel like most people used it to spread news instead of discuss what they're working on or thoughts they are having. I don't need tech news. I can get that here.

I'm not even saying Facebook is the best UX for what I want. I used to enjoy a smf forum that was mostly friends and I liked that I could see the list of topics. But, I also just like glancing at my Facebook feed once a day or so and see what my friends are up to. I'd like a similar experience except for programming / tech only topics with tech only friends.

And of course it goes without saying that a coding FB should format code well and some how allow embedding live snippets in iframes

Note: I know lots of people say their FB news feed is a dumpster fire. For whatever reason I've unfollowed enough people or something that mine is fine. Unfollowed every political friend for example. Just don't want that on my newsfeed. Can get it elsewhere
At 343 meters / 1125 feet the sound is going to be about 1 second out of sync with the light, and that's going to sound terrible.

Wind direction and atmospheric pressure is going to make a small difference.
It won't help bring in revenue. Pointless to worry about that at the start
yet again - I have not experienced anywhere close the amount of outage before Github was swallowed by Micro$oft
> increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people.

Citation needed ?

I know at least 20 people being paid to work on the Rust compiler, which crank's your 10x number from 25 to 200. And this is only the people I can come up with from the top of my head.
I use Arch because of AUR. And one more thing I don't like snaps.
That analogy is close but doesn't quite match my experience because there doesn't have to be much overlap in letters in a word. I went back and reread a few of my most recent HN comments looking for an example (my condition impacts both reading and writing). There are some easy to understand mistakes like replacing "went" with "want". However I also used "because" in place of "beyond" in one comment. Those two words start with the same two letters, but they are completely different after that and are relatively distinct visually.

An algorithmic analogy I would use would be fuzzy matching. Most people's brains are set to look for exact matches (or fuzzy matching with a super high match criteria). When one part of their brain needs access to a word, the other part of their brain will supply the exact match. My brain is using fuzzy matching with the confidence level set mistakenly low. When part of my brain needs a word, the first match returned is occasionally a false positive match. The rest of my brain just accepts it and continues onto the next requested word. The match quality isn't a traditionally fuzzy matching algorithm like Levenshtein distance. It is heavily weighted to both the start of the word and the expectedness of the word in the given context. The latter makes it very difficult for me to immediately notice my own written mistakes since I am already primed to expect what I intended to write and not necessarily what I actually wrote.
Very often that's ok if you can choose when the outages occur. With most you can because outages tend to be for regular maintenance and upgrades far more often than hardware failures. A small geographically concentrated company only needs 9 fives.

Even for bigger companies that need more uptime they can at least give a shout out to everyone that it will be unavailable from X to Y, it doesn't just go down randomly with no notice whenever github decides to push a release.
Note that the Weltwoche, where the original article appeared is a right wing rag, which very heavily supported the quick reopening of the country. Including the editor in chief (who is also a vocal right wing member of parliament) arguing to lock the old people away and just get done with it.

Beda Stadler, the immunologist in question, is a highly controversial figure.

I, for one, would not trust my health on those guys.
Many reasons, including your hosting provider going down.

At that point you'd have to create and manage a cluster.

You have to update servers, etc. etc. and if you count the hours is many times more than working locally and wait a couple of hours until technicians at GitHub fix the problem for you.
Not a lawyer, but that sounds a bit wishy-washy, which corporate lawyers are really not fond of. It's part of the reason why the JSON standard was problematic for a while, because it had a clause stating that it "should be used for Good, not Evil", which is a legal nightmare.
If you ctrl+f for the word 'plot', you'll find the ones that were disrupted prior to execution. They don't spell it out, for obvious reasons, but generally some sort of surveillance is involved.
Absolutely not, but I guess that most of "internal repos" access patterns are widely less trafficked than GH. So, it's not that difficult to have a "stable enough" configuration for most organizations. Sure, for a 5-10 devs shop it's overkill, but if you have a mid-sized team and already having someone caring for internal tooling/systems, it's not that a bad idea. Unless you have the "hosted here" syndrome.
I come from a C# background, but to list out a few hurdles that I have already deal with with TypeScript/NodeJs.

1. C#'s AsyncLocal has made a few things simpler to trace SQL queries to a request.
2. We chose to use hapi.js some 2 years ago, because we found the interface superior to Express, but I did not expect the sole developer of hapi.js to decide stop working on the project [1], and left my head scratching on what I am going to do about that.
3. TypeScript's interface sometimes feels too much like just "suggestions", and every once in a while run across scenarios that are not fully supported. One that I really dislike is that Sequelize's "where" options has no type support for the model. [2]
4. Sometimes libraries does not use async correctly, and breaks stack traces.
5. Sometimes TypeScript's generic errors can be as bad as C++.

My favorite feature of TypeScript is being able to just define types/objects in-line, but I actually like to stay on the side of caution and stability on a large project with many people.

[1] https://github.com/hapijs/hapi/issues/4111
[2] (GitHub is down, or I would grab the link)
That moment when you submit a very long comment on GitHub, and realise that it is down. :(
Well, I'll agree that weird click tracking timeouts isn't the solution. I don't think flagging/voting is either, though, at least in its current form.
It's important to note that it's the website that is down. Git itself worked through all the outages I can remember. Unfortunately, at least the last time I think, the integrations didn't.
I have noticed a pattern than when I generate markdown from org-mode and have the text 'language' selected for highlighting push, this causes github to hang like crazy. I don't think I'm crazy in thinking it might be me. I push frequently to my blog and am starting to notice a correlation.

I export this into the below markdown.

#+BEGIN_SRC text -n :f "translate-shell -s fr -t en" :async :results verbatim code
I learned some French so that I can talk to
you during tennis. I hope I know enough so you
will not get bored.
#+END_SRC

When I get a page build failure it's usually my fault for creating .

This is the markdown which was pushed to my blog. The 'Page Build failure' messages take a long time to arrive to my inbox and I can see that the page build is hanging.

{{< highlight text "linenos=table, linenostart=1" >}}
I learned some French so that I can talk to
you during tennis. I hope I know enough so you
will not get bored.
{{< /highlight >}}
> But they don't understand even the basics of the existing theory, and don't want to understand it.

How much homeopathy do you need to learn before you can dare to question it's validity?
Small to medium size teams should be hyper-focused on developing their product and bringing in customers and revenue. Spending time on commoditized infrastructure is only a good idea if that saves time in the short to medium term.

But hey, with the number of outages GitHub has recently that break even point is coming closer and closer.
For anybody else irritated by watching all of the short segments stitched together by the video player at the Internet Archive, I wrote this script to concatenate the mp4 segments and re-encode as a single mp4 file.

#!/bin/sh

DIR=$1

BASE=$(basename $DIR)

echo copying from $DIR to create $BASE.mp4

# copy the files over
mkdir $BASE
cp -v $DIR/*.xml .
cp -v $DIR/*.mp4 $BASE/

echo done copying
echo convert segments to ts files

# convert all the mp4 files to intermediate transport stream format
for f in $BASE/?????.mp4; do
echo "$f -> $f.ts"
ffmpeg -i $f -c copy -bsf:v h264_mp4toannexb -f mpegts $f.ts > /dev/null 2>&1
done

# concatenate all the ts files and then re-encode them to mp4
echo concatenate ts files and re-encode as mp4
(cd $BASE;
ffmpeg -i $(echo -n "concat:"; for f in *.ts; do echo -n "$f|"; done) -c copy -bsf:a aa c_adtstoasc ../$BASE.mp4
)

# clean up
echo clean up
rm -rf $BASE
echo done
Twitter is not a dinner table though. Twitter is a public square. I think you could make a reasonable case for Facebook being dinner-table like. But Twitter has privacy settings. You can protect your tweets if you want to. If the police were breaking into protected accounts, I would agree with you. But Twitter seems about as public as it gets.
It's not that I'm against, the contrary, but in the last months I've experienced a physical server crash, a random kernel panic and a failed upgrade of GitLab: that all took 10/20 hours of work, didn't result in any data loss, but the downtime was clearly higher than what GitHub has (+ nobody on the team was on holidays at that moment), plus any maintenance like software or system upgrades has to be done outside team working hours to limit the impact.. real self-hosting is not that easy!
not familiar with circuitry. Just clarifying, you're saying that can enforce the indicator to be on long enough to be noticed?
Is this moral licensing?
Not the point of the article, so sorry about offtopic, but the workflow described in the first chapter feels a bit off. If they wanted dynamism, then writing a server is the way to go, but it seems that the easier fix to their problems as described there, would have been setting an automated CD pipeline that would build and deploy their blog every time you make a change.
I said this before many times and I'll say it again, consider self-hosting your projects on a solution like GitLab or Gitea to avoid this sort of situation. [0]

GNOME, Xfce, Redox, Wireguard, KDE and Haiku all have self-hosted on either cgit, Gitlab, Phabricator or Gitea.

[0] https://news.ycombinator.com/item?id=23676072
If it does compile, could you try reporting results for multiple Rust compiles (e.g. the current one, and the ones from 6,12,18,24 months ago) ? (If you can, maybe do the same for C, but I don't know how easy that is).
Yes for amateurs. But we have plenty of experience from military applications about how to launch a massive explosive really far. WWI artillery shells could weigh that much and travel much further, though they weren't launched straight up.
I mean, hardware nowadays is quite reliable. We have a simple server with three disks in raid1, and it basically just works. Gitlab has regular backups, so at worst we would have one day of lost work.
Seems to me like a Deja-Vu after I answered this[1] on quora yesterday.

[1] https://www.quora.com/Github-now-allows-unlimited-private-re...
there isn't an azure outage right now.
They started doing availability reports. Las months details in the blog post below with summary of the issue.

Stay tuned till next month for the current outage.

https://github.blog/2020-07-08-introducing-the-github-availa...
Post mortem for February events[1]. It was resource contention on their primary mysql cluster caused by unintended config change.

There's a total of 34 incidents in 2020 so far[2]. I wonder if all are DB woes or there are other factors at play (like move to Azure).

[1] https://github.blog/2020-03-26-february-service-disruptions-...

[2] https://www.githubstatus.com/history
I've had 2 sd-cards go corrupt (read-only, any writes were lost). Had a mariadb instance running on it as well. It will hold for for some time, but eventually, the card will give up.
Self hosting quickly becomes a mess of weird gatekeeping and bad maintenance. Almost never have I seed well maintained self hosted infrastructure. Most of the time it is installed, gatekept and then left to bitrot without any upgrades or maintenance.
That surely depends how much they use Github, and when they need the service available.

Our self-hosted build and artifact servers have not gone down without planning in many years. Planned outages are brief, for a small team it's not inconvenient to announce a 10 minute outage for an upgrade.
The phrase "science teaches us such and such" is funny in the same way Zoidberg saying "I'll have one art" is funny.
Try using UbuntuTouch for your mobile device, although you'll have to buy a new phone if yours is not supported. Using open software as much as you can will add another brick to the wall that tries fighting the monopoly. Brave for browser, DuckDuckGo for search engine, Protonmail for mail, Signal for messaging. Ditch Android, Facebook... etc. You know the drill!
Rust is much too low level for most glue/web services. Unless you have a specific high performance requirement (and Go doesn't meet this), there's no real strong case for migration here.
Are these SMT components that have to be soldered for testing? Hardware is not as trivial as software to test and replace.
I think for most possible clients it would be a solution in search of a problem. Even for Hacker News, I'm not sure how it would actually work out, so if I were HN I wouldn't be willing to invest much in it.
Yeah. I am being very cautious about their desires. I learned that the best way to discourage someone from taking a large project is to show how much work it would be. Just shutting down developers is not nice.
People seem to be afraid of treating their people like idiots; when it comes to airplanes, you cannot be ambiguous when it comes to emergency / unexpected situations.

With cars, I've had the privilege of driving cars with automatic lights for a while now, I don't have to think about it anymore. On older cars, my dad used to fiddle with the wiring a bit and install an alarm if he turned the engine off or opened the door with the lights still on. That was just the one alarm though.
I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust, this kind of workflow just doesn't work at all. The long compile times completely kill any enjoyment or flow that I normally get out of productive programming. Even worse, I found myself anxious to introduce new dependencies, because each new crate would add a few more seconds to the compile time, which immediately correlates to less coding enjoyment.

I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. I have a theory: there must be two groups of engineers. One group loves fast compile times and quickly validating hypotheses. The other group must value thinking about their code a lot more than running it, and so compile times aren't that important. My guess is that, while the second group hangs around and loves Rust, Rust has completely driven away the first group (including myself) to the degree that they don't use the language enough to even fill out the surveys.

Anyways, I know it has a wide swath of use cases, mostly in systems programming. I'm just bummed that if I ever do any of them, I won't really enjoy it. :-(

[EDIT:] Gotta go to sleep, it's far too late here. I really appreciate all the thoughtful replies. Rust's amazing community is another reason it annoys me that I can't fully get into the language as I'd like to.
Never studied any, but they generally seem legit. I'm more into Japanese marital arts, but it's really about what appeals to you. Give it a shot if that's what fancies you.
Move off Rails now GitHub, is clearly not working for you. It took you this far, now go move to something that doesn't sh*ts the bed twice every month.
Is there anything like Rails for Rust?
I can't confirm what is the motivation behind Ada++, but actual Ada2012 standard and in particular the Ada SPARK (2014) subset is in many ways objectively superior to Rust with regards to memory safety.

One major issue with Ada is that commercial grade compilers are not cheap and for the most part the language was unable to get rid of the stereotype of being an Aerospace/Defense language only.

Some discussion on the topic:

https://www.quora.com/How-secure-is-Ada-the-programming-lang...?

https://ada2012.org/comparison.html

https://www.adacore.com/about-spark
Bootstrap Paradox
Github is probably still more reliable than Bitbucket, that has weekly disruptions (small but you do get a performance impact)
I'm sure they have progressed a lot since, but last time we evaluated a self-hosted git "hub" solution at work, Gitlab couldn't handle our main repository (history starting in the 90s, but probably more imporantly loads of junk and a 10GB size on disk). We went with Stash (now Bitbucket) instead.
I haven’t used their new features but am heavily affected every time they go down. I wonder if they are making the right trade offs here.
> Your control. Your network. Your infrastructure. Your responsibility

These are all the reasons why I don't want to self-host my own git. I can live with it being down every now and then. And when it is down, I don't want it to be my job to fix it. I've got more important stuff to worry about.
It's in the preface

> The project is simple enough that I can't imagine being too limited by any language's ecosystem. And I've been itching to write something substansive [sic] in Rust...
You get to spend time fixing it rather than waiting it done :p
I was using for 10+ years Gentoo Linux because I could customize it to my needs, but recently switched to fedora Linux mostly because I don't have much time now for maintenance and in my work we use a centos on production therefore it helps with muscle memory.

With gentoo I used it with systemd IMO it solves enough problems that it's worth having.

PS I miss how gentoo allowed customizing packages with use flags and using lto + graphite for compiling system actually provided measurable better performance.

PS2 I choice fedora also because is uses bleeding edge software like Wayland by default.
That might have to do something with the massive amount of light pollution in the foreground?
TIL Hedy Lamarr's frequency-hopping patent https://patents.google.com/patent/US2292387 used a OTP instead of a PRNG.
The AUR is really nice. Also creating your own packages is super easy.

AUR can be used to install git version of software and configure them to your liking. For example, I run Emacs, rebuilt every month or so, that's directly from the most recent commits. Arch Linux makes it really easy to compile any package from source and configure how you would like (change gcc optimization level, compile in optional features, etc).

Pacman (the package manager) is also a lot faster and full featured than Debian. Everything just works.. better. And with the AUR, Arch Linux undoubtedly has more packages than any other distro. And the packages aren't ancient, either.

Another plus is that Arch Linux includes all development headers with the main package. In Debian you have install a special dev pack, which I think is pretty stupid.
Yes, this is where the user community will play a big role.
"usually"..."basically"..."probably"...that's a lot of handwaving. Your usecase is both your prerogative and your folly to embrace; that's not the point.

I poke fun at the OP because his qualifier for "works fine" is an indeterminate definition of eventually establishing some semblance of compliant 1-wire communication with a counterfeit component without even so much as batting an eye to question the accuracy of the sensor measurement being read in, let alone:

a) environmental constraints
b) electrical constraints
c) timing constraints
d) system integration considerations
e) counterfeit variance/unpredicability

No, this is not even remotely asymptotic to the implications of software unit testing. This is physical hardware which manifests real variance "vetted" by some half-baked functional "test" that completely ignores every parametric spec without discrimination. Without questioning implementation merits, your software unit tests operate on hash-replicable code...at the silicon level, such a luxury doesn't exist.
for an very old version
Yes, it’s obviously needed, especially with the introduction of .Net Core.
And seriously, comparing C# or F# with JavaScript is ridiculous. Typescript on the other hand is quite good, but its compiled JavaScript performance is much worse than .Net.
Your brain's like an Intel processor, it's guessing what you are reading. Fast but error-prone.
I still don't understand people who always mentions to Microsoft's acquisition. Until the official statement, it isn't Microsoft failure. Don't blame them.
If you think self-hosting doesn't randomly go down, you have never done self-hosting.

In the last few months we had a server that physically crashed and had to be replaced, we had a bad kernel that paniced randomly and a gitlab upgrade that failed in the middle.

Is you team equiped and ready to handle these? If not, don't self-host anything critical to your company, or your costs, downtimes and losses will be much much higher.
Every time you compile a rust project after an initial compile, cargo does use "binary" dependencies (bitcode dependencies).

It is much better at this than C++.

For example, change a trait in your Rust library, and recompile the tests, and compare that with changing a type in, say, range-v3 (or any other C++ header-only library).

In C++, recompiles take pretty much the same time as clean builds (for range-v3, exactly the same time). In Rust, they are infinitely faster (100000x faster, depending on the project, but essentially almost instant, in contrast with initial compiles).

So for development at least I'll pick Rust over C++ every day. I only do an initial compile once, but I edit and recompile a lot, and that's the bottleneck that I really care about.

(Same with C btw, add a new API to a commonly use C header and re-compile, and you end up re-compiling the world, while from Rust, you just re-compile the part of the crate where the new API was added, and since no downstream crates use it, that's pretty much it - instant change).