icxa

What will end up happening is the major content creators, the ones that have massive followings will treat YouTube as the "advertisement" to the other platform they are on. "Hey guys thanks for checking out my video, here's a small preview. To view the full version, check me out at <some_other_platform>.com!" It's similar to what the big ones did with monetization (turned off all monetization, and now do in-video ads or some donation platform). Once that happens, there will be enough traffic on the new platform for enough medium size players to test the waters, then the whole thing will topple down. The only thing YT will have left is existing content, of which the only task remaining will be a race to archive what is currently on there.

Unlike a real desert, everyone can still reach you in your internet desert, and eventually it can become an internet oasis.

Then again, maybe once that happens YT will actually start to become content-creator friendly again.

(I am trying to tie the two concepts together from your reply, so I am not saying this to come off as combative but understand your objection)

- What would you define as a while? I think Go has done well with it, given that it is almost 10 years old now at this point, and in reality, was in development internally at Google years before that.

- Do you feel like an interface being frozen forever is particularly a bad thing in of itself? What if the interface does a really good job describing the thing, whatever it may be? For example, Go's io.Reader/io.Writer interfaces.

I agree sometimes an interface being frozen is bad, but for example when Go standardized the context package, it simply added "Context" to the existing functions that now take a context (e.g. in the database/sql package, you have the old, Exec, Query, QueryRow functions, and after 1.8 you have ExecContext, QueryContext, QueryRowContext, which some people may view as a reason to have method overloading, but I view as adding better clarity.

This is interesting. Go seems to have the complete opposite stance. The stdlib are some of the most useful and well written packages you can use in the Go ecosystem, and then you have the "extended" standard lib which isn't 100% in the language yet, and even further sometimes concepts from useful community packages make it into the std lib.

As to why this is the case, I think maybe this is enabled by Go's backward's compatibility focus and encouragement to upgrade early and often, and the community's focus to utilize small interfaces sometimes from the stdlib itself, like io.Reader and io.Writer, or http.Handler. Added to that w.r.t. using the latest and greatest, most Go users frequently are using the latest version of Go even in production (per the go experience surveys).

I am sure it also helps that Google pays people to develop, maintain, and improve the stdlib.

I have to disagree that they work fine with graphics, especially in low light conditions. It's downright terrible in my opinion. I have a kindle version of Calculus: Better Explained, and it's unreadable on my Paperwhite. I have to resort to the kindle app on a tablet or PC.

> Which genocides did they "enable"?

Mynamar

> It doesn't seem to have helped

yet. Also Apple's goal with the iPhone isn't global dominance.

> Hasn’t all of this stuff been obvious forever to programmers?

Yes, but it wasn't at the "oh crap elections were manipulated, democracies toppled, dissidents tracked down, and genocides enabled" level.

The fact that Apple, the world's richest company in the world, now has a mainstream marketing campaign around privacy tells you it is now officially mainstream mainstream, not just programmer mainstream.

It's ironic that we moved from the trust / authority model of factual verification to "data driven" model of verification, and now we are seeing how easy it is to even manipulate that. I suppose the only step forward, and maybe has been the only true way all along, is democratized authority and expertise.

Doesn't iCloud use Google Cloud?

There's more than a couple of fortunes to lose by automating the trucking industry as well.

I admit the comment was meant to be a bit tongue in cheek but it doesn't appear to have had that impact. My intention wasn't to be condescending or anything like that as others have taken it.

A better argument would have been to explain why ORMs are bad.

In my view: - they encourage bad data modeling practices. Eventually there will come a time where the way your ORM maps your data model to physical tables will be inefficient. Maybe you really have event based time series. The impedance mismatch becomes exacerbated.

- they are an extremely leaky abstraction. It is hard to think of a more widely used abstraction that leaks more. You have to be familiar with your ORM's SQL generation. Every single comment here has admitted that yes you eventually do have to drop down into raw sql, so this part isn't even subjective at this point. The article is about leaky abstractions, ORMs are the poster child for them. - On the other side of things, there are simpler abstractions between SQL and ORM that provide more value comparatively for the leakage, and my argument was you would be better off having simple leaky abstractions than one massive behemoth of an abstraction that leaks more than a waterfall.

- Really hammering the point home here on the leakiness, for being such a leaky abstraction, after it is all said and done, in my view they really don't provide you with all that much value, given that you have extensive experience working without them (the source of my seemingly condescending point about experience and some languages guide you to never working without them).

I can just as easily use my code generation tools to have "less code to write", and map some functions to SQL statements using my language's favorite DB drivers, use a battle tested and proven SQL migration and schema tool, and I can do this just as fast as any experienced ORM developer.

In this view, just like we have had the movement away from big massive monolithic frameworks to smaller opinionated sets of libraries stitched together with simple glue code, your ORM is the massive monolith in this case, and your simpler tools like code gen and migration tools are the smaller libraries.

This story is so common it has a name: the paradox of subsidies.

> Dropping down to a lower level of abstraction from the get go because you might need that level of control for performance reasons in the future sounds like a typical case of premature optimization to me.

On the flip side, I can make use of the code generation tools i have compiled (some myself, some others) and write code just as fast, if not faster, using raw sql and simple data structures than I did when I used ORMs.

There are infinitely many possibilities in between:

- A developer who is experienced in modeling and sql will deliver working software faster than a developer who might be experienced, but not with modeling and not familiar with a particular ORM or a particular version of that ORM. We could continue ad nauseam here.

The main point: if all things are equal, meaning you have a two developers, one comfortable and experienced in their tools of choice, the "raw sql and simple data modeler" developer and the developer very comfortable in their ORM of choice, the raw sql developer will deliver working software at the same time as the ORM developer, but will have a smaller surface area for buggy software due to the increased inadvertent complexity of using an ORM, and poorer database designs, since naturally, developers that rely on ORMs tend to have poorer or suboptimal database design (see this classic talk https://www.youtube.com/watch?v=uFLRc6y_O3s)

Again if the rebuttal to the database design point is "well you should still know SQL" then what point does the ORM serve?! To write less code? Anyone can write a code generator. If in order to be an effective ORM user I have to know the ORM and understand the SQL it generates to tweak the ORM flags or features to make it generate better SQL, then not only is it a leaky abstraction, it s a bad abstraction. I rely on my compiler to write assembly for me because I can't write assembly better than my compiler and I don't know x86_64 better than compiler developers. If I can't rely on my ORM to write good enough SQL, and I have to know the underlying things going on with the ORM, then why use the ORM? Again, "less code" by itself is not a sufficient answer.

As your database fills, the performance penalty for using the unoptimized mapped queries and the unoptimized data schema will start to increase by whole factors.

The argument against ORMs aren't that they are a leaky abstraction (although they most definitely are).

The argument is although they appear to offer you value up front, they cost you much more down the road. The moment you have a hot path query that needs optimizing, you are dropping down to your ORM's "raw sql" mode. Then you do it again. Then again. Then you are ripping out the ORM and spending cycles refactoring it out of your code and replacing it with simpler abstractions.

I always find the people who don't believe writing raw SQL is preferable to using an ORM is usually down to a lack of experience or because they have been coerced to use ORMs by their "enterprise grade" language (usually your C# developers of the world, no offense to you all but if every time you look up examples of data operations it's dealing with EntityFramework you are probably going to wind up with a lot of devs using EntityFramework). The ORMers, as I call them, don't have confidence in their own SQL ability, and they haven't experienced the aforementioned situation enough times to realize you are better off starting with SQL to begin with.

The realization is, if I could summarize it: yes all abstractions are at least somewhat leaky, so you are better to use simpler ones than complex ones (and if you need something more complex, compose it from simpler ones)

It's also trivially easy to extend this to Kinesis with a lambda.

NATS is a solution I have used in the past that supports Request/Reply semantics (I actually really enjoyed NATS). I am not sure Kinesis fits the traditional mold of a "message bus", but it certainly can be used as such, and I have used it as a message broker extensively. Kinesis with its tight integration with lambda can be trivially modified to add Request/Reply semantics with a lambda, but I will concede your point Kinesis is designed to be many ways in and one way out.

There is no explicit forbiddance of Request/Reply semantics in a message bus. Data on a message bus absolutely does not have to be one way.

Have you found any support groups or any that were affective? I have taken a cursory glance at some support groups available to me in the past, plus some internet circles, but found them not personal enough to be effective or I felt too detached from the people involved from their day to day problems. But I feel like I, as well as other ADHD folk would benefit from some sort of HN "accountability" partner or group that understands the condition but also the type of work we do.

My "coping" mechanism, annoying for some, I am sure, but I just bluntly immediately ask for feedback and try to get to the bottom of it as soon as possible. I am fortunate enough to have a manager that understands my condition and he offers me plenty of "spot" feedback which I cannot appreciate more.

> Rejection Sensitive Dysphoria is big problem for me. I over think things, the slightest misread comment can ruin my day.

I am a recent adult ADHD diagnosis recipient, and I never knew that there was words to describe this but it describes me perfectly as well, so thank you for the knowledge kind stranger.

I ditched my Ritalin for similar reasons, although I do have a hunch Adderall would help me better since the one time I took it recreationally in college, rather than "get me high" like it was the other college kids, it sort of just made me well..normal. I got my homework done that day according to schedule!

> I/O will never run as fast as the CPU.

In the era of kernal bypass and modern IO accelerators seen in some data centers today, I wonder if this is even true today?

Again I am not trying to be a contrarian, but in my experience quantity != quality. You can take this statement the other way and say too much information is bad. There is a reason there are so few Go Stack Overflow questions and answers: most of Go's documentation is excellent and easy to follow and learn and they have excellent community resources, videos and guides. From what I have seen so far, the OCaml and Reason docs are great, and their communities are extremely supportive.

I am in no way a OCaml fan, and I primarily use Go at work.

That said, the fact that OCaml is used by Bloomberg and Facebook (on multiple apps and products) alone make it not niche http://www.ocaml.org/learn/companies.html

That plus ReasonML's growing popularity, which is essentially just a syntax extension of OCaml, makes it even further not niche.

If you interpreted that statement as me specifically saying that commenter is a shill, you should probably take a rest from social media as well, and take a step back to realize the negative lens you are viewing things through.

"It's like HN doesn't understand of raising money on an existing valueless proposition!"

No seriously, I don't understand. Explain to me. I grew up in and around small businesses, I legit don't understand how this bulls* flies. It's all being propped up for god knows what reason, and ultimately your average citizen is going to have to pay for it when it all comes crashing down, like always. I don't care if a group of "visionary VCs" "see value" in it. We've replaced a sustainable industry (taxis) with Uber and Lyft, which only were able to because they were able to skirt by regulation, and now if and when they vanish because again, they have proven to be unable to actually make profit to date, we will now have a crumbled public transit mode left to rebuild. Irrational investments that negatively affect the public should be faced with this intense scrutiny.

I am honestly obviously ignorant to whatever is going on here, so I am allowing myself to be educated here.

I am well aware a public company's earnings report is public https://www.microsoft.com/en-us/Investor/earnings/FY-2019-Q3... (btw -- Tell me where in Facebook's earnings reports we should have looked to learn what they were doing with CA?)

Microsoft Dynamics is their ad tech solution for companies that wish to mine data about their customers. You want to tell me you are that naive to think they aren't dogfooding this internally to at least some extent? Windows 10 basically turns your PC into a spy machine for Microsoft. Now they have LinkedIn, which has well documented gross-levels of data collection on it's users, and GitHub which has a gold mine of data voluntarily given to it daily, and to some extent VSCode, although AFAIK, turning off the telemetry in VSCode really does turn it off (should still use Pi-hole to filter, just in case). You really think they aren't feeding that data into their DP and packing up this data and selling it off to the highest bidder, including governments, just like Facebook got caught doing? If so, I got a bridge I'd like to sell you.

I find it interesting that most threads on HN lately about Windows always seems to have quite a few comments in the form "I switched from Mac to Windows, loving it!" I know no place is immune from shilling, but it does raise a particular brow.

Conspiracies aside, and probably more interestingly, I am not convinced that "this is the new Microsoft" or that Satya Nadella is some visionary CEO because while everyone has been seemingly lulled to sleep here on "the new Microsoft" on HN lately, guess what accounted for an ever growing portion of Microsoft's business last quarter? Microsoft's data mining business! Horray! So while we are out here with our pitchforks on the Google's and Facebooks of the world collecting our data and selling it, Microsoft has quietly turned around and ramped up their version of these practices seemingly unscathed.

Remember, Microsoft is still under scrutiny for continuing to collect your data on Windows and other products even after you have opted out. From my perspective, choosing to run Windows is still choosing to run a spy machine for Microsoft.

Maybe I am wrong, but Microsoft still doesn't deserve our trust, not even in the slightest.

> I think a lot of these famous programmers have never had to work with something terrible and probably never will and that is why they make such blasé statements.

Do you think they never had to work with something terrible, or when faced with something terrible, they took the time to make it not terrible? The track record for the software these two have built speaks for itself.

Your baby's first ~3 months is basically the "4th trimester" but just outside the womb. It basically explains why things like swaddling work so well for their sleep at this age, and why shush sounds work (because it supposedly mimics how the baby hears the mother breathing inside the womb of the mother). Also counter-intuitively to a new parent, why perfect stillness didn't really matter for her sleep and actually a little movement ended up being better. Invest in a good rocking chair is probably the best advice I can give any parent! Don't cheap out here, you are going to be spending a lot of time in it!

Form filling is part of the standard, specifically, the process of applying an XFDF to a PDF, which even allows you to do things like present a remote web form and then inject the data into the PDF.

We need to stop relying on the assertions Big Tech make about themselves, and work towards regulation.

What most viewers saw during the Facebook congressional hearing was woefully out of touch, forgive me for using this phrase “old white guys” questioning Mark with many facepalm-able moments. But the house hearing, which includes 40 representatives from the Millennial generation, who grew up on tech, asked much better questions. It just got swallowed up by the news cycle because the Manafort Raid was happening at the same time as hearing about the Cambridge Analytica scandal was occuring.

All of this is still new. Banking, Finance, Real Estate, those are all well regulated at this point and arguably much more sophisticated or complex. The situation we have now with the Googles, Amazons, Microsoft, Facebooks of the world packaging up our metadata, combining it with other third party data, training AI, etc is all new, and those who are knowledgeable about it are just now making it into congress, so I am optimistic we will start to see real regulation on these shameful business practices soon.

Roger McNamee had an excellent conversation on the Sam Harris podcast recently about all of this. It was a very good conversation and one I highly recommend listening to.