I think many would rather tell it when to start instead. What's hard about telling it to stop is when you can't tell it's started because it's something more nuanced than the obvious diet plan.
The Apple Music free trial thing is shitty but Taylor seems quite out of touch with the shape of the industry here.
Taylor Swift can withhold her music from streaming services because she's a PHENOMENON who can still shift albums via iTunes (and even physically) because people want her music. Artists starting out don't have that luxury and, increasingly, their music won't get the listens if it's not on streaming services.
It strikes me as similar to the situation with people only buying games that are on Steam. Consumers love the convenience of a platform that is in many ways quite anti-creator. Tough one.
Taylor Swift can withhold her music from streaming services because she's a PHENOMENON who can still shift albums via iTunes (and even physically) because people want her music. Artists starting out don't have that luxury and, increasingly, their music won't get the listens if it's not on streaming services.
Did you read the post where she explains what is her goal for doing this? Here is the relevant part:
This is not about me. Thankfully I am on my fifth album and can support myself, my band, crew, and entire management team by playing live shows. This is about the new artist or band that has just released their first single and will not be paid for its success. This is about the young songwriter who just got his or her first cut and thought that the royalties from that would get them out of debt. This is about the producer who works tirelessly to innovate and create, just like the innovators and creators at Apple are pioneering in their field…but will not get paid for a quarter of a year’s worth of plays on his or her songs.
Do you really believe that? Or is that maybe carefully crafted language to fend off the parent's valid argument?
Plenty of creators currently put their music on Soundcloud, Bandcamp, Youtube and more, and get exposure that way without getting paid.
The choice is really up to the artist. I do agree that Apple has the ability to pay artists during the 3-month trial, but should they have to? I don't know..
btw not saying I have the answer here, but as parent said, the current landscape doesn't really line up with her argument much.
> I do agree that Apple has the ability to pay artists during the 3-month trial, but should they have to?
Unless the artist (or representative) have given them permission to use their content for free, they should absolutely have to. It's the same IP laws that Apple like to use in their own defence: you can't just use someone else's stuff without their permission and without remuneration. What do you think Apple would do to me if I started selling an OS that used Apple's graphics set?
Just because some artists put their music on free media doesn't mean that a corporation can use that music as a loss-leader to sell their service.
But is Apple planning to use the content without permission? It doesn't seem to be the case, since they're contacting artists asking them to join Apple Music. There was a guy claiming they threatened kicking him off iTunes, but they've denied it.
"Taylor seems quite out of touch with the shape of the industry here."
She is VERY in touch with its shape... And she is trying to change it. She also famously ditched Spotify and has been consistent in using her fame and leverage.
What she is doing is very important...Spotify is bankrupting artists while bleeding cash with no real business model to make the money back. She was outlasting them while the vc money ran out and it was working.... Now that Apple is in the game, the danger of them using their cash to bankrupt artists with a bad business almost indefinitely is very scary to artists. She is trying to be diplomatic while making a point.
Taylor is pulling her music because those small artists can't. She's making a statement, and because she's such a phenomenon her statement is likely to at least be heard.
I find this hopelessly naive. Yes she said that. Why is she only pulling 1989? Not her other albums? It seems the most likely true answer is "because that one is still selling strong so it is in her interests to do so."
It's also very possible that Swift doesn't have control over where the other albums appear, since they're from old deals she made before she had much leverage.
Most likely, it's a combination of all three possible explanations: some albums are from old deals she has no control over, others (1989) she wants to make more money on, and she's also disgusted with Apple's treatment of artists and taking a stand.
People don't need a single pure motivation for their actions to be legitimate.
A number of developers have been complaining (unreasonably, IMO) about the recent refund policy. Oh, and there's the 30% cut which can be seen as a bit too high.
Otherwise, I would also be genuinely curious to hear what problems developers have with Steam.
The only place I can see it getting info like this is a social network, and that means G+...
In all seriousness, could they cross-reference dates in G+ posts and photos to see that you mentioned being on your honeymoon when it was taken? Seems like something they'd do if G+ was actually a thing people used.
There's the Google Search looking for good place to stay on a honeymoon, the email or hangout message sent to the SO mentioning it, the calendar event, etc.
Even just seeing that you're on an irregular stay in Thailand (which it got from your Android) right after your marriage can be telling.
I am seeing that it uses tags and faces that I previously put on photos within iPhoto and are evidently stored with Exif. So if you used iPhoto to tag your set "honeymoon" it will pick that up.
This is a very common question, and there's two camps:
1. Learn C, then learn some C++. You won't appreciate Rust until you've felt the pain that it solves.
2. Learn Rust. Why bother going through all that trouble on your own when you can have the compiler help guide you.
and a third position:
3. Rust is still new enough that you'll find way more information with C, so you should just learn that even if Rust is better in a vacuum. Learning is easier with copious help and tutorials.
Thanks for the reply. I'm leaning towards Rust. I'm required to learn C for university next year (I do physics) so I'm going to have to go through the pain anyway. There's also the quwation of usage in physics circles.
It'll probably come down to the material I'm trying to learn each with. The Rust book looks very good, finding anything decent and modernish for C has been a nightmare.
This is a nice summary! FWIW I'm more likely 1, as I've seen many people coming from dynamic languages being frustrated about the "Rust way". Not only the ownership model, but also compiling, optimization, etc.
3 is certainly a problem, but personally I found enough materials to learn Rust even for now. However more "friendly" resources would be definitely welcome.
While I'm new to rust, and have just been dabbling in C -- as another comment mentions here: you really have to deal with the borrowing in C as well (and the compiling/optimization). If you don't deal with in C (without any real language support) -- you'll get bugs. If you're very lucky, and made a great effort in turning on warnings[1] -- you'll be aware of those bugs. Most likely you won't.
I'm in the same boat as you. I've been working through Learn C The Hard Way [1] as a way to learn some of these concepts. I've been finding it incredibly valuable/rewarding.
That said, even the author of LCTHW (Zed Shaw) recommends writing in languages other than C. He specifically mentions Go, Swift, and Rust.
Weird rant. C is not dead, especially not for really low level high performance things. But Go/Rust/Swift are more modern and easier to use for some of C and many of C++ use cases.
You already have a lot of good answers, here's some more:
C and C++ really isn't the same thing. Certainly not "modern" C++.
Unless you know of any C++ projects/frameworks/libraries you really want
to use/contribute to -- I don't think I would recommend looking to hard
at C++. It certainly isn't a dead language, and has many uses -- but at
least outside of the gaming industry, I can't think of any segment were
C++ would be the preferred language -- except when dealing with legacy
code (which of course, realistically is the biggest segment...).
Perhaps C++ paired with qt for GUI programming.
But even for games, you don't need C++ -- if you are free to start
from scratch anything will work.
> is Rust a decent place for me to learn lower-level concepts
Which lower level concepts?
C maps quite neatly to assembler -- but to appreciate that I'd recommend
learning a bit of assembler. amd64 with nasm/intel syntax is rather
pleasant[1]. It'll let you see what calling conventions/ffi, data layout
and the difference between c-strings and pascal strings are all about.
If you take a canonical hello-world from C, C++ and rust and look at the
generated assembly -- rust and c++ will be (IMNHO) closer to each other
than to C. The assembler generated by the c-compiler will be straight
forward, and quite readable -- while both C++ and rust will look a
little more convoluted. (This is also true for Nim, which compiles to C
-- but needs it's own runtime. I've not looked too hard at code
generated by go -- but given the runtime, I think that assembly would
also be much more difficult to make heads and tails of, than something
output by a C compiler).
If your goal is more to learn a low-overhead compiled language, I would
recommend rust. If your goal is to find a compiled language that is easy
to integrate with others, I think I would recommend C (for now) -- and a
bit of basic assembler.
I think after learning a bit of assembler and C -- one also gets a
better appreciation for why Pascal was so popular for a while.
With any luck, and more work -- hopefully rust will be able to sneak
into quite a few of Cs use-cases, like writing libraries for easy
consuption by python/ruby/etc. But I don't think rust is quite at a
place where it makes sense to reccomend it for that use-case to a novice
(low-level) programmer. I'd love to be wrong about that.
[1] Unfortunately, I don't really know of any good introductions to
amd64 assembly. There are a couple of great tutorials for 32bit/x86 --
but a lot of things are simpler in our amd64 world. While it might be
good to know how to write bootloaders (16bit) and 32bit code -- I'd love
for there to be a simple tutorial focused on just amd64.
I like this asm tutorial (unfortunately for 32-bit):
I may be misusing the terminology but I had in mind the sorts of things Python does for you, like memory management.
> If your goal is more to learn a low-overhead compiled language, I would recommend rust.
Now that you mention it, this is probably the main thing I want. Integration with Python would be nice though and, as mentioned in a previous comment, I have to learn C for university soon anyway.
Might add that Rust has a very new blend of concepts that are "in your face" -- and arguably a very "modern" selection of concepts. I'm not well versed in neither C, C++ or Rust (or Haskell/ML) -- but this old article by Stroustrup (creator of C++) still makes some interesting points vis-a-vis C:
Rust has great documentation that's rapidly improving, but the selection of "syntactic tools" are somewhat eclectic -- yet I think one could probably be a better C programmer by first learning Rust (just as one might be a better C programmer by first learning Pascal and/or Ada) -- precisely because Rust has gathered up what seems to me to be a very useful subset of "things" (borrow/box, strong typing, safe/unsafe etc) -- that can be useful to apply to any kind of programming.
And just as with C++, Rust will give you somewhat more complex solutions (if you look at the generated machine code) than naive C code -- but as it turns out -- the naive C code is probably incorrect, anyway!
> But I don't think rust is quite at a place where it makes sense to reccomend it for that use-case to a novice (low-level) programmer. I'd love to be wrong about that.
So a lot of this is tooling, integration and documentation.
If one might whip up something similar for rust that works cross platform, and results in code that is reasonably easy to distribute via pypi (and similar for gems for ruby etc) -- that'd be great.
So, I meant that for a novice, that wants to, say write a compiled extension/wrapper for python/ruby whatever -- a bit of C and the standard docs go a long way now.
Obviously there's a lot of work to get to the point of C (it's been ubiquitous for a while...) -- but if some parts could be made similarly accessible; interfacing with rustc, if rustc is in path/installed "properly", some magic on the host-language side etc -- that would be very good, I think.
This great! Looks like there's still a bit of a gap wrt passing arguments; like the snippet above does. After skimming the chapter on ffi as well, there appears to be the need for a bit of experimentation (for me/a novice) to get that to work (eg: passing in a string, getting it back reversed, or as a list/array of unique characters/glyps etc).
I'll have a look when I find the time - but this is a great start!
Yeah, things like "what do I do about more complex types" needs tons of more docs in general. We will get there. I'm also pretty convinced that a dedicated individual could create pretty awesome automatic binding generators for any language, especially since bindgen works pretty well for C... but we'll see how it shakes out.
Don't hesitate to email me or post in the forums if you play around with this and get stuck :)
