> It's worse than that, the authentic name-brand listing can still ship scammy clones instead because Amazon aggregates the listing from multiple sellers and pretends they're all the same thing
It's called fraud. Some people here call it "scaling" but it's just good old fraud at scale.
> It really is striking to me that it is so popular to dislike Go on HN. A lot of people seem to have to voice their dislike for it instead of just not using the language.
It's normal. After the initial hype 3/4 years ago, developers are taking a harder look at that language and with experience its flaws have become more obvious.
Go type system definitely has problems that aren't addressed by its designers, IMHO limiting its adoption.
> A lot of people seem to have to voice their dislike for it instead of just not using the language.
One can use a language daily while still remaining critical of it. People who don't use Go don't care about Go. Only people using Go will complain about its shortcomings.
A lot of Go issues have actually been addressed in previous languages such as Ada. Ada tasks for instance are close to go-routines and they use the same "select" system to deal with concurrent messages. However, Ada tasks unlike go-routines are "objects" that can be referenced as variable, they also can scheduled by the developer.
There is not a single language out there free of criticism, Go isn't different. So it shouldn't really be striking at all.
> Go type system definitely has problems that aren't addressed by its designers
Wouldn't that break the promise of backwards compatibility that they made with major versions? They could probably do that in Go 2.
Personally, I think D is a more mature language, design wise, although it's a bit lacking in terms of libraries compared to Go and the tooling is, also lacking compared to Rust.
Like I said: Go does everything C does, but better.
I suppose you could write your own malloc in Go... if you preallocated a bunch of bytes in a huge chunk, and wrote some functions to use that up. But that sounds like a pain.
If you really really specifically need to manage your own memory, then I agree, you shouldn't use Go. But that doesn't mean that Go is not a valid replacement for C. Do you think a majority of programs that are written in C are done so because they need to manage their own memory?
> Like I said: Go does everything C does, but better.
It doesn't do everything C does, it doesn't allow manual memory management at first place.
So you can't pretend that a garbage collected language does everything a language with manual memory management does.
Manual memory management is a feature, Go does not have such a feature. Deterministic behavior in a program is fundamental when writing hardware drivers or real time programming, Go can't do that.
As already proven by many attempts to implement safe OS, a GC is not an impediment in a systems language, religion and disbelief against GC are.
Joe Duffy has putted it quite nicely regarding how many in the Windows team saw Midori, even though it was proven to be running right in front of their eyes.
RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy
A programming language capable of building the whole stack from the boot loader, usually written in Assembly, drivers, all the way up to user space applications.
The only programming language for a single platform, besides a little Assembly for hardware integration.
The traditional CS definition of systems programming languages on OS research literature.
Promises existed way before they were put in the specification and way before async/await. So no, promises could not have been advertised as part of async/await since they came before async/await.
> This code will just ignore the error. While it is expected that the runtime error would float up and terminate the program - that is what runtime errors are made for.
No, this behavior is consistent with how asynchronous programming works in JS.
> That is because browser environment catches all exceptions and displays them in console. So effectively they become handled exceptions.
No, it has nothing to do with the developer console. It has everything to do with the fact that async exceptions do not bubble up in the main execution thread. Promises work the exact same way since they existed as libraries long before they were included in the language. It's about consistency, nothing more, nothing less.
> The case of bitcoin being safe haven is probably only apply in the long term. It's quite obvious the price is heavily speculated now.
There is no "safe haven" on the long run, it has been a cycle of pump and dump schemes, no more, no less. and it will continue, Right now the exchanges are dumping their crypto and buying fiat.
An investment vehicle as volatile and unregulated as Bitcoin cannot be a safe haven. Bitcoin has lost more than 60% of its value in 4 weeks. It's rife with scams, fraud and exchanges that just steal people's money pretending they were "hacked".
13/ make sure your webpage doesn't depend on Javascript just to display an article and its title, like 99% of news websites and blogs today...
14/ avoid sticky headers,like this page has, that take 1/8 of the screen real estate on a laptop and even worse on mobile.
15/ A reader should be able to increase/decrease the size of the text without destroying your layout.
16/ Stick to simple "websafe" fonts for the body of your articles. Some fancy fonts that look good on your MAC look really bad on Windows.
17/ the most horrible thing designers do: light text on white background. Please stop. Just because it looks good on your calibrated $2000 screen doesn't mean it will on a $250 laptop with limited contrast settings.
Well it has supports for JSX and decorators which AFAIK aren't in the spec yet. It also has a syntax for class mixins without actually doing any desugaring when the code is transpiled. So it's not quite just JS + types.
Ah, I forgot about those. Nonetheless JSX and Decorators were added to the language back in 2015, so they've been sticking strictly to ECMA features for nearly 3 years now.
> Think about it--if a user receives a bunch of fake friend requests, it's a bad experience.
Except that Facebook knows who is real and who fake. Just like my mail provider knows who sends spam and who doesn't.
Facebook can display ads to fake users and still make the campaigner pay for the impression, or make a group pay for reaching more users, fakes included.
Facebook can easily filter requests from fake profiles, so no, fake users do not necessary worsen the experience for real ones.
"Facebook can easily filter requests from fake profiles"
"Except that Facebook knows who is real and who fake."
You say that so definitively. Have you worked on a product with millions of new users a week? It's an extremely hard, constantly shifting problem.
"Facebook can display ads to fake users and still make the campaigner pay for the impression"
Facebook's entire business relies on user and advertise trust. Why would they sacrifice that for some short term growth that would inevitably kill the business by eroding trust?
While I don't pretend to have been party to internal FB conversations when certain decisions were made, as an advertiser, FB has definitely done some things to significantly erode that trust over the years.
For starters, encouraging advertisers to spend money to build up an audience with the assumption they could continue reaching that audience much like email, only to throttle organic reach to zero was pretty bad.
There have been other things such as being extremely...generous...with the definitions of how some ad metrics are defined and what defaults are presented. Even as an experienced advertiser who knows to look for those things, the lengths to which some of it it is buried is astounding to the point of it being hard to trust that it wasn't intentional. And the recent lawsuits around such things shows I'm not alone in that feeling.
> You say that so definitively. Have you worked on a product with millions of new users a week? It's an extremely hard, constantly shifting problem.
Facebook has hundreds of engineers and enough data to do match patterns against. Facebook can largely identify who's who.
> Facebook's entire business relies on user and advertise trust. Why would they sacrifice that for some short term growth that would inevitably kill the business by eroding trust?
"Facebook has hundreds of engineers and enough data to do match patterns against. Facebook can largely identify who's who." I know, I used to work there. I was asking you. Pattern matching isn't black-and-white, as you alluded to in your previous comment.
"Yes, the infamous 'they trust me, dumb fucks'?"
You didn't do or say stupid things when you were 19? You don't believe in giving second chances, let alone to a teenager?
It's called fraud. Some people here call it "scaling" but it's just good old fraud at scale.