Of course it is obvious, it is just that almost no one online believes that the information contained within is worth enough to subscribe, and there is not a frictionless way to compensate the other the $0.03 cents worth of value I potentially got from the article.
The problem is that this is not true and everyone knows it. What you've hit on is the core problem facing digital media today. I subscribe to several online news services but the WSJ is not one of them. I wouldn't mind paying the $0.03 (or whatever) to read this article but there's no way I'm going to add another $100 per year subscription to my media diet, and particularly not given the state of the WSJ political and opinion sections. I love the finance and tech side, but, my God, the rest of the paper has become a parody of itself! I'm sure many other folks out there feel the same way about WAPO or NYT. The regional papers have it even worse, even though they perform, arguably, the most valuable service of any outlet.
This problem is so severe that I would argue that it's tearing Western civilization apart. So-called "fake news" is a problem that only exists because real news is expensive to create and needs be heavily subsidized to exist whereas fake news is cheap to make but heavily subsidized by bad actors. This is perhaps the single most important problem in media today. If you can solve the business problem behind content creation you'll be an absolute hero; but I really doubt that shaming people for reading pirated articles is going to do it.
It's not robbing someone but it is removing some potential revenue. And, so I don't come across as hypocrite, I also circumvent the vast majority of subscriptions, but I realize I am denying some miniscule revenue and over time, all added up, could be something.
So the problem is _both_ friction and circumvention in the least, as well as overcharging. Would I pay for Cable? No. Would I pay for Netflix? Why not. They offer a good product at a very reasonable price with little friction and I would not try circumvention, because there is no reason.
Dozens of studies about music have proven this theory false. In fact music “piracy” likely has increased their revenue because they spread music. Intuitively you can see why labels have gave in to free as supported YouTube models as opposed to locking them down; they wouldn’t have done this had CD sale revenue was higher, but in aggregate having people’s attention is worth more. Similarly, I can for sure let you know that I would not pay for WSJ if I couldn’t read their articles under any capacity. For me not to be able to read it just decreases their network and thus their value in other ways. And now that I’m more familiar with them I might pay one day.
YT, unless you subscribe, shows ads. News sites which let you browse unimpeded show ads --but have those ads blocked by many. So, when they try to make a quid pro quo bargain (ads for content) people often don't like complying with their end of the bargain.
Music has evolved into paid services or ad supported services. News content so far has failed with the ad supported model and unless they create some cartel (a spotify for news, let's say) they have little alternative beside the direct subscription model.
I asked that question once, apparently crews aren't armed and it's a big deal to start shooting at people at sea. There are videos of people fending off pirates (actual, sea based pirates) with water hoses.
I don't get that - it seems pretty obvious you could arm a crew and fend off some assholes with AK47s (you have the high ground, lots of corridors, time to prepare and can afford some .50's on the deck) - but then again, I'm so American I am practically a Bald Eagle.
escalation. Shipping companies don't want to have to worry about how much armament is enough. Also it blurs the lines between a cargo ship with defense against pirates to an armed ship that may have cargo.
But yeah some ships now have mercenaries.
Or, instead of that, if someone is unwilling to pay you money for something, then you should get a better business model, instead of trying to brow beat them with silly morality arguements.
Stealing: The felonious taking and removing of personal property with intent to deprive the rightful owner of it.
Copyright infringement is copyright infringement, not theft. Playing word games like “piracy” or “stealing” doesn’t strengthen your case, rather it exposes a central weakness. If what you’re claiming is so terrible, why do you have to pretend that it’s actually something else? This is an old game that was started in the 80’s by industry groups, and its sad to see it internalized by people on HN who should know better.
If you want to argue the merits or downsides of copyright infringement, do so, but don’t move the goalposts to unrelated crimes.
A person might make a language so they can learn to make a language. How could Lua exist if a person had no idea the tradeoffs in implementing various languages? You do not know the person's reasons.
You're absolutely correct, and making your own programming language implementations to generally improve as a programmer, for fun, or to get better at implementing programming languages is great. It can become a daunting task very quickly.
I was basing the person's reasoning after the original poster's reply:
> There are so many programming languages - but imho not a real easy one for beginners.
Not really a comment on the topic, but I feel like name pollution is becoming a bigger and bigger deal recently. With Dropbox's Naultilus and DragonflyBSD and Google's Dragonfly, and like a hundred other examples, things can only get more and more confusing. Imagine talking to a Mathematician about a meager function, the word has two senses(common and mathematical). Things cannot improve the way we are heading.
As a meta comment, I really like how active Stepha(e?)n is on internet forums. And the energy around Rust is pretty intense. I feel like in there, people are unwilling to try to embrace some of the nuance in the arguments that some people make against Rust.
A person should understand that no language(programming or otherwise) is perfect. Therefore there is some criticism of any language that is valid. Therefore some criticism should be taken seriously as there may be a real point to the criticism.
There are many posts like this, where there are comparisons of Rust to C. Realistically they are all a little biased towards Rust as Rust is a C++ replacement really. A more proper comparison would be Zig or D as a better C against C.
Just understand that a person defending C is not always an idiot, and maybe they have point. Consider the excessive memory use of any working Rust compiler. That will probably not be remedied anytime soon and is a legitimate complaint. The ideal of how something could be is not how something is. The reality is that C works pretty well most of the time, Rust works well most of the time. They both fail at some things.
I don't think I've seen anyone claiming that Rust is a perfect language without flaws. Heck I'd hold up all of the huge strides that have been made in errors, usability and constant feedback as a counter example of that.
You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice.
What Rust offers is another option in the native, non-GC'd language space. A space that has very few languages and even fewer yet that are shipped at scale. Rusts inclusion w/ FF means that the have to address the robustness, security, performance and usability of the language to a degree that you don't commonly see.
Having just blown 4+ hours today dealing with the linker on a mixed C/C++ project I don't really miss a lot of the baggage that comes with native development these days. Rust gives you the option of dropping down to that level while still preserving a set of sane, opinionated defaults that are pretty well thought out.
Since you made a mention of CMake, does Rust really provide an alternative for building multilanguage projects? When I went to look for examples on how this is managed, it seemed horrendous. For example, some projects manage this by writing a program to download, unzip, and build the source:
As long as all of the dependencies are in Rust, things appear nice. At the same time, unless I'm missing something, it seems like crates manages multilanguage projects poorly. Though I have some major gripes with CMake, I've managed multilanguage projects mostly well.
Is there a sane way outside of CMake to manage a multilanguage project with Rust?
Check out Bazel: http://bazel.build. I've been using it a lot to build several multi lingual projects that include Java, C++, embedded C, Javascript, CSS, and even Docker images. There are community Rust rules, that I haven't tried yet, but am planning on investigating soon: https://github.com/bazelbuild/rules_rust
Not so much with Rust in the driver's seat. Cargo, Rust's primary toolchain, only has weak support for pre/post build scripts. It's solely concerned with Rust's own dependencies and compilation. In the couple of projects where I've added Rust to a larger project, it's always been bash or node that coordinates the overall build.
You can call a compiler for C/C++ from build.rs. That tooling is currently not very advanced. As far as I know there is no crate to write compile recipes that as easily as a Makefile or CMakeLists.txt.
When I tried this in build.rs, I had to check modification times myself.
There is an opening for a ninja-type crate in Rust.
Indeed. Rust is the only new contender in the field of systems programming, where C++ has to contend with decades of negative mindshare (C++11: "I've changed! I promise!"), and D, well, never really took off (because it started off in the early Internet era as a commercial compiler?).
There is also Zig, which seems nice as a C replacement but still highly unstable, and Jai, which is also a nice C replacement but currently has no publicly available compiler yet... So for the time Rust is the only new systems programming language (And please don’t say Go/Nim is a contender, they’re good languages in their own ways but having a garbage collector disqualifies it fron that categorization)
No language that drops C compatibility while having the same manual memory management is an actual contender.
Yes having a GC is a contender, because not all GCs are implemented the same way, and C did not eliminate Assembly as well.
So if a systems language, with GC, covers 95% of use cases. We can happily use something else for those remaining 5%, while enjoying better productivity and safety.
Companies like Astrobe manage to have enough customers to keep their Oberon compiler for bare metal deployments business alive, just as one possible example.
> You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice.
Ironically, cargo is one of the areas the rust ecosystem falls down completely. Not to mention, there's no ABI...
> What Rust offers is another option in the native, non-GC'd language space.
True, and while this is great in principle for embedded development, not using a GC is overrated.
> Rust gives you the option of dropping down to that level
Well, if you're not dealing with the linker, you're not at "that level"
Very strongly disagree that Rust is a C++ replacement and D is a C replacement. If anything, it's the exact opposite, Rust is a C replacement and D is a C++ replacement. If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust. There is already a huge osdev community built around Rust, I know kernels written in Rust. Rust is the perfect language to reliably write drivers, embedded systems or system tools. I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome.
well, which language of C and C++ has the possibility of having traits, structs with function definitions, generics which work through monomorphism, variants, optional, reference-counted pointer and pointer ownership semantics ?
> If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust.
> I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome.
ATS is far closer and indeed compiles to C. Rust's type system is still less expressive than that of ATS.
If I remember correctly there were plans to implement GNU Hurd (the Half-Life 3 of kernels) in ATS, but that probably went nowhere. But there is a small osdev community messing with kernels and ATS.
Actually Rust is clearly both a C and C++ replacement, but C programmers tend to become quite fanatical and for some inexplicable reason C also has a quite decent reputation, so the Rust community is focusing their efforts on the much more controversial C++ instead of attacking the holy cow of C.
I think they've also figured out that with time C will be squeezed into smaller and smaller areas of use, as is already happening.
Writing robust code hasn't really found a space to live in the mental model of C programmers. Using C outside a kernel or existing C project today is professional negligence.
C has been in the process of being replaced for decades. I specifically mentioned kernels and legacy projects, because these are its last retreats; even embedded has lost a large chunk to C++.
Here's a silly prediction: in the next 10 years a significant number of C programmers will retire without replacement. The new generations will rather learn Go, C++ and Rust for low-level stuff and will banish C to pure legacy projects.
I disagree about replacement programmers--at the moment, practically every graduating electrical engineer and computer engineer will have a working knowledge of C. Embedded C has lost some ground to C++, but primarily in ARM and x86 architectures, since for more memory constrained AVR/PIC/etc. microcontrollers, you absolutely avoid template inheritance because vtables are untenable, there often isn't an available STL for the chip toolchain anyways, templates balloon the program space, and you are still constrained to using just stack allocation. That right there pretty much means there will always be a space where C is more pragmatic.
I see this pattern a lot on HN. Many aren't aware that there are fields alive and well that require the use of unsafe, deterministic C that can compile to programs on the order of kb.
Regardless of the person's reaction, they do make a very good point. There is a weird thing that happens when you criticize
Rust on HN or Reddit where lots of people jump in to prove that any criticism is invalid. I like Rust well enough. I like C too, I have my issues with both, but when someone does raise an objection it can be hard having people pile on them after.
A point of fact is that the two data structures are different. There was even an article on the front page today about how minor changes to data structures can dramatically impact performance.
Anyway, my main point is that there should be a space to discuss the relative merits and issues of languages without it resorting to petty fighting, which even you and the OP and the other commenter are engaging in.
Please everyone try to use the principle of charity when reading a post on this site. There is a good chance the person you are responding to has a reasonable background and isn't totally ignorant. Instead of playing on pedantry, try to understand where they are coming from and understand a one-off post on an internet forum is not the strongest argument they could make.
> There is a weird thing that happens when you criticize Rust on HN or Reddit
Can I ask where this impression came from? The original, now-downvoted comment that started this thread wasn't criticizing Rust, it was criticizing the article. If people disagree with that person's criticism of the article (which is itself not a criticism of C, and acknowledges as much), I'm afraid I don't see how that contributes to any perception that people are unjustifiably leaping to defend Rust.
Are you serious now? I mean you are very active Rust activist on both HN and Reddit and you exactly know what Rust Evangelic Strike Force is and where it came from. I've seen multiple threads on HN and Reddit where people do exactly what OP wrote. I don't know if it's denial or ignorance on your side or you are writing this with premeditation.
The "Rust Evangelism Strike Force" is a dumb meme (but I repeat myself) that gets used sarcastically, and was originally coined by people who were themselves critical of Rust. If you have links to instances of people doing exactly as OP wrote, please paste them here; I am mod of /r/rust, where we have had a "No zealotry" rule ("Stay mindful of the fact that different technologies have different goals and exhibit fundamentally different tradeoffs in pursuit of those goals.") since long before cat-v.org concocted the RESF, and I am happy to rein people in if their heads get too big. :)
As to whether my above question is serious, the answer is yes, because truth be told I see more people complaining about Rust Evangelism than I see instances of evangelism in the first place, to the extent that I wonder if that itself has become a meme by now.
> where we have had a "No zealotry" rule ("Stay mindful of the fact that different technologies have different goals and exhibit fundamentally different tradeoffs in pursuit of those goals.")
I've never wrote anywhere that you encourage that kind of behavior. There is a difference between encouraging and pretending that problem do not exist. Seems that you are just biased and what you are doing here is white washing a community you are part of.
> If you have links to instances of people doing exactly as OP wrote, please paste them here;
I would rather spend time with my family than searching whole HN and Reddit for obvious things that were mentioned here multiple times by multiple people but I've found couple of links fast (not for you, but for other readers) [1][2]. And this are only two examples that I've found fast. Those are examples of things that you surely have read and aware of.
Another example is some Animats posts in some C++/Rust debate thread on HN in which he was describing his experience and technical details while criticizing Rust and was downvoted to hell.
Here you have another person writing same thing and dbaupp acknowledging that the problem exist [3].
This comments didn't come from vacuum and denying that problem exist will only make it worse.
It's fairly clear from the context of the comment he was asking about where the impression came from in this thread. I have no doubt he was interesting because he believes it is somewhat unjustified and self perpetuating, but if this thread is any indication, there may be some truth to that.
So, to restate the question clearly and unambiguously, what prior to kibwen's question lends someone to think this is a matter of Rust evangelists taking issue, and not the somewhat common HN interaction of someone calling out someone else for, in their eyes, misinterpreting or ignoring and aspect something and then denigrating it for that lack?
Well, first let me take this out of the way: if plenty of people do what the OP was complaining about, I would welcoming he complaining about them, but not about people that didn't do it.
Now, I'm having problems understand what that Rust Evangelic Strike Force is, and what nefarious goals it could have. Do you have a pointer? (Also, is it a funny group?)
You should maybe feel bad. Maybe not. In your first month, you should have had what? 20-ish days to get around the monorepo. Look to the bug tracker. Ask your manager for projects or idea about things to work on. Sorry to say it, but you should do SOMETHING soon.
I think the idea from a corporate perspective has always been the idea of a programmer as an industrial worker. Just as dispensable, and just as replaceable. Luckily reality has not borne that out.
