There are always the pro and con arguments about software mono culture and there are good points on both sides, and in this case there is indeed a gigantic cost to maintaining more than one implementation -- no one is debating that. Also, an across-the-board evaluation would probably find Firefox technically inferior at the moment, although I think that's more of an interesting debate and also a measurement where I feel the gap has lessened these last few years. My disclaimer would be that I'm a long-time user of both browsers, but ethically on Mozilla's side.
However, I think the following
> and to an implementation which satisfy every interests (the ones of Googles and the one of Microsoft/mozilla)
doesn't put nearly enough emphasis on exactly how different those interests are. Google's main source of income depends on user surveillance and privacy intrusions (to use some loaded wording), and while Mozilla's indirectly does too through their sources of funding the two entities have very different goals and core beliefs.
That in itself doesn't preclude sharing an implementation, but thinking that those differences won't (and don't) cause conflicts of interest that affect both the evolving of the standards and how the actual implementations work would be, I believe, a big mistake.
Just saying "ensure the respect of privacy in the chromium source code" and that they should maintain a set of patches or a "micro fork" I think ignores the level of control they will be (or rather won't be) able to exert over the Chromium code base. I don't think Opera, Brave, Microsoft, Mozilla or anyone else that decides to either be a downstream user of or active participant in Chromium will be able to keep Google from doing whatever is in their best interest with the code base. Additionally, I think keeping patch sets (that won't end up being very complicated and will slow down or put to a grinding halt independent development) won't be able to make up for the implementation differences caused by the differences in goals. Keeping patch sets can be extremely painful.
> Chromium is open source and has those two main actors: opera and Microsoft.
I really apologize for my tone, but... Please. In what regard are they main actors? Certainly not to the extent that they have any significant control over the main direction of the Chromium code base or any power to stop Google from completely controlling it.
The core beliefs and goals of the entity exerting the main control over the code base matters a lot more than your post makes it sound like. And if Chromium really were the only code base able to browse the modern web, then that would also put the standardization of the World Wide Web more or less in Googles hands.
Also, for someone asking for better "intellectual riguour", you do a pretty so-so job at showing your understanding of the arguments of the people you don't agree with.
I am a paying Spotify customer since 2010 or so and have also spent countless hours developing software for personal use integrating with Spotify. I've used e.g. their old (now deprecated) C-library and now rely on the web API. Therefore I have no qualms on calling them out on some of their hypocrisy.
Many music streaming services have no API:s, and those that do have (to the best of my knowledge) worse API:s than Spotify. I'm very grateful that they provide any means of integration. However, that doesn't get them a free pass to get on as high a horse as they try.
Now for the part where I gripe. They recently created a dedicated site shaming Apple for, in part, not exposing the same internal API:s/abilities/possibilities to Spotify as they did to their own and perhaps some other third party apps. That's pretty rich.
Where is the protocol specification or available-for-everyone library for creating a Spotify Connect endpoint? Locked behind Hardware Partner Applications, NDA:s, Evaluation Agreements, New Product Applications, Device Certifications and Distribution Agreements (yes, all of those, according to their own site). Talk about subjectiveness and forcing people to jump through a thousand hoops -- like they accuse Apple of. "and final approvals for commercial usage will always be left up to the discretion of Spotify and its partners". Three cheers for transparency and a level playing field.
Where is the web API support for folders, a feature that you clearly use yourself in the desktop application? The web API has been launched for years without folder support. This feature is completely private and unavailable to others. In the GitHub issue about it that they closed with WONTFIX the motivation was in part that folder support didn't fit well into their REST API, which is some of the weakest sauce I've had in quite some time. I used your C library and I know that you implemented folders as "begin" and "end" markers in the huge, flat playlist list. Perhaps you regret that design decision, but if that makes it an expensive API call then rate limit it accordingly. Make it subject to change as you evolve. Just don't close it off and keep it private for your own apps.
Yes, I'm annoyed. I've been a loyal customer, user, developer and fan for almost a decade. They get to expose or not expose any API they like, that's their prerogative. But what they don't get to do is gripe about the subjectivity and closed off-ness of others if they don't practise what they preach. I hate hypocrisy.
If you've read this far, I apologize for spouting bile. Time to sleep, probably.
There was a time when Spotify was the underdog—a scrappy music startup fighting the good fight trying to legitimize streaming. I remember jumping through hoops to get a prepaid European debit card and using a VPN just so I could sign up for Spotify back when they blocked US users from using it.
Spotify isn't that company anymore. It's a public company that isn't profitable and now has to answer to investors every quarter.
They are trying to build a moat around their business. It wouldn't surprise me at all if they shut down API access entirely. Their investment in podcasting is another example of an attempt to put a walled garden around content (i.e. public radio).
Spotify isn't little. Sure, it's not as big as Apple… but literally no one is. Spotify is a $25 billion company that doesn't care about you or artists. They care about finding a way to be profitable. That means putting up walls and ramping up ads.
I think what pisses me of about Spotify is how they still want to pretend like they are the small startup, full of designers with their cute hand drawn graphics, being bullied by evil corporate American shills. It's all bullshit. They are just as corporate now as anyone else.
>
I think what pisses me of about Spotify is how they still want to pretend like they are the small startup, full of designers with their cute hand drawn graphics, being bullied by evil corporate American shills. It's all bullshit. They are just as corporate now as anyone else.
Fantano actually investigated this: the record labels rejected a higher artist % of streaming revenue from Spotify in favour of the labels owning more Spotify shares. Spotify is literally (to the extent of that ownership) the record labels.
The way they’ve handled the deprecation of libspotify is appalling. As you said I’m grateful that they opened their API up to use by others, but ever since libspotify got canned developing native apps around Spotify has become more and more dicey and restricted, with the most notable feature omission being streaming. Worse, they’ve been promising a replacement for years now and it still has yet to arrive.
It’s disappointing that the only truly developer-friendly music service on the market has decided to clam up like they have.
Completely agreed. Libspotify/libcspotify was one of the most promising parts of Spotify’s API, and it was left to die in a hole, with promises of revival, but no actual intent.
Absolutely this. The Web API is oddly crippled in a number of ways which make it oddly difficult to develop many interesting apps for the platform. You can't fetch the users a logged-in user is following, for example, hampering the ability to make any kind of "Spotify native" social functionality. Very odd, there's an API developer advocate but he seems toothless within the company.
I'm waiting eagerly too, thanks for all the hard work you do!
I read somewhere in all the discussions that Carl was hesitant to go all-in on futures 0.3 (those are definitely landing in std, right?) in tokio before some additional ergonomics had landed, possibly some language feature among them but I may misremember...
Do you know the list of things and possibly their tracking issues? Futures in std, async/await, etc, something something more? Would love to be able to keep track and follow along :)
Ha, that was a superb answer, thanks! :D I'll be checking that site!
I know you may not have your fingers in this particular flower pot, so the "you" was directed at the entire Rust community. However, while we're here you still get a big personal thanks -- your Rust for Rubyists got me hooked those years back and the docs/book (1st ed and then 2nd ed with Carol) work you've done since is nothing short of amazing -- and with these latest developments I hope you find a great place to continue your work <3
You remember correctly. This is present in "A fire upon the deep" by Vinge, which is one of the best sci-fi books I have read (although I am not particularly well read). Really, that book contained several concepts (the drifting tech zones, the hive mind mechanisms, etc) that made it an amazing read. I would recommend it to anyone who appreciates sci-fi.
EDIT: I forgot to add that the book was also a Hugo Award (Best Novel) winner, which I just noticed/remembered as I took it down from my bookshelf to re-read it... =o)
When discussing the suitability of different programming languages I always point to the problem at hand and identifying the abstraction level the problem is at. What your problem requires you to care about and pay attention to gives this.
Ideally, solving your problem would be a one-liner in an already existing DSL created for your specific problem (domain). In reality, this rarely happens and you must have your pick beteeen everything from niche DSL:s to assembly, but the key really is identifying that problem abstraction level.
I work in a mainly C/JS shop whereas I privately prefer Rust/ReasonML. Rust would be a great fit at work, but Go would also work nicely for tons of things we do. Alas, the inertia of organizations.
I went through so many years without bothering to find out why I hated some pens and loved some pens, until I decided to dive into the subject a bit. The type of ink and pen affects writing joy so much. I discovered that I was a gel pen kind of person and tried a bunch of different makes, so now and then I buy a big pack of Pilot Super Gel 07, and now I always have pens around that I love writing with. I'm probably going to get one or two quality gel pens too, like Parkers or similar, because now I know what I like.
I highly recommend finding out which kind of ink and pen give you the most writing joy! A simple comparison to get you started can be found on the gel pen Wikipedia page: https://en.wikipedia.org/wiki/Gel_pen
My path went crappy pens -> Pilot ballpoint -> Pilot gel -> Pilot Metropolitan fountain pen.
Not having to exert pressure makes such a difference to me that my handwriting immediately improved when I started using fountain pens. I've even had friends comment on it. "Wait, I can read your handwriting."
Same here. My path went crappy pens -> Pilot G2 -> 0.38mm Pilot G2 mini, imported via Amazon -> fountain pens -> completely obsessed with vintage writing instruments.
Sitting in a hammock beside the river, hacking on a Pyramid app, I have four fountain pens on my person - a Kaweco Lilliput, a Pilot Stargazer, a Pilot Falcon, and a Pilot Vanishing Point.
Fountain pens make the experience much different for me, and I actively dislike using someone else's pen now.
I got so used to fountain pens that ordinary ball pens feel like writing on sand to me. Interestingly, I like my cheapo Pelikan fountain pen better than the Parkers
My favorites for note taking have been felt tip pens, after that Pilot gel pens. When i had very little money I’d still try to get some papermate felt tips, though i like staedtlers just for the better grip.
I have, and really enjoy it. My previous go-to for frontend was TypeScript, but it wore me down. I am ridiculously productive in ReasonML with proper ADTs, (exhaustive!) pattern matching, immutability and other niceties. The superb type inference is also great for prototyping, and I could go on and on. Rust for backend and ReasonML for frontend is making me very happy these days. I think the community will only keep growing. I feel like I’m an extra in the filming of Revenge Of The MLs, and it feels great.
> My previous go-to for frontend was TypeScript, but it wore me down
Yes, coming from Scala.js it feels like TypeScript constantly tells me little lies (i.e. that the runtime type of the typed type is not in fact the type in question, but something else entirely). A powerful language with plenty of interesting features, but there are better options out there if strict typing is of interest.
No choice in current project, Angular essentially requires TypeScript. Editor support for TypeScript (via VS Code) and JS interop are, however, excellent.
Sure. I would say that Rust and ReasonML are very alike and very different at the same time, and I'll explain why I feel that. ReasonML's own docs give Rust a notable mention: "Close cousin of ours! Not garbage collected, focused on speed & safety."
They both
- have powerful static type systems with good inference.
- default to immutability, with optional mutability.
- encourage functional constructs over procedural/imperative ones.
- ADTs and exhaustive pattern matching with great ergonomics which can be used for everything from rigorous error management to unambiguous program state representation.
- have escape hatches to write "I know what I'm doing and need more wiggle room"-code, but those are clearly visible for linting/auditing/testing, as opposed to languages that allow foot guns to invisibly permeate entire code bases because the language has no clearly discernible rigorous subset that one easily and naturally can keep to.
The list of features that make them alike can be made as long as your arm, and it's basically a laundry list of features that (once internalized in the developers mind) helps one build robust, correct, maintainable software. Sure, they're not carbon copies of each other but what it comes down to is enabling and encouraging the same semantic constructs.
So where are they not alike? I would say that the one constraint that the main differences result from is the fact that ReasonML's automatic memory management is a run-time solution (garbage collection) whereas Rusts is a compile-time solution (using static analysis), coupled with Rusts focus on raw performance. Everything else about the Rust language has (IMHO) been designed with the same sound underlying values as many other languages which encourage correctness. The differences that one notes when learning Rust are really mainly just the concessions that were necessary to make to achieve compile-time automatic memory management and raw performance.
Did that help? And as always, if I'm mistaken about anything, please correct me. I'm not a PLT person.
Absolutely. I've been a Rust lurker (and later user/advocate) since ~2012/2013, I think, and the visible WASM support strides being taken right now coupled with my trust in the Rust community gives me great hope for Rust on the front end.
It remains to be seen to what extent and which problems it will be suitable for, but just as Rust despite the fears of some is (again, IMHO) turning out to be ergonomic enough to write all kinds of end user apps in (although some areas are still lacking, but give it time), so too I think it might surprise people with how widely applicable it may turn out to be on the front end.
And I'm hopeful and optimistic. I feel like we're seeing some tides turn with respect to how important software correctness/robustness really is perceived to be and -- importantly -- what we're prepared to pay for it. We're still a "young" industry compared to a lot of engineering disciplines, so it's not surprising that we're still maturing with periodic waves of change. Of course, many will disagree with the direction, but for me it can't come fast enough.
Sorry, I hadn't ranted in a while, and it is Friday afternoon. =o)
I use TS myself. It helped make front end development OK for me again. But man, one really misses some things.
I recently picked it up again and struggled to remember how to properly do pattern matching and exhaustive checks, until I realized that there were more hoops to jump through than at a circus convention. A friend ultimately pointed me to https://pattern-matching-with-typescript.alabor.me/ but that made me weep.
Then I remembered how I hadn't been able to figure out how to use object spread to perform variable assignments of all members from an object returned from a function, with compiler verification that no object members had been forgotten. That may be possible now, I'm not sure. I don't think it was possible last I battled with it.
Don't get me started on the ergonomics of immutables. Again, this may have improved, and no one would be happier about that than I.
But all in all I feel that TS is not what I'd like to use for front end development. However, it's where the community and development effort is at, and I feel like I could never convince my colleagues to go with BS/PS/Reason/anything else. I haven't even been able to push them from JS to TS yet.
If someone wants to show me the error of my ways, I'd love it, since I'll probably be using TS for some time to come.
There are always the pro and con arguments about software mono culture and there are good points on both sides, and in this case there is indeed a gigantic cost to maintaining more than one implementation -- no one is debating that. Also, an across-the-board evaluation would probably find Firefox technically inferior at the moment, although I think that's more of an interesting debate and also a measurement where I feel the gap has lessened these last few years. My disclaimer would be that I'm a long-time user of both browsers, but ethically on Mozilla's side.
However, I think the following
> and to an implementation which satisfy every interests (the ones of Googles and the one of Microsoft/mozilla)
doesn't put nearly enough emphasis on exactly how different those interests are. Google's main source of income depends on user surveillance and privacy intrusions (to use some loaded wording), and while Mozilla's indirectly does too through their sources of funding the two entities have very different goals and core beliefs.
That in itself doesn't preclude sharing an implementation, but thinking that those differences won't (and don't) cause conflicts of interest that affect both the evolving of the standards and how the actual implementations work would be, I believe, a big mistake.
Just saying "ensure the respect of privacy in the chromium source code" and that they should maintain a set of patches or a "micro fork" I think ignores the level of control they will be (or rather won't be) able to exert over the Chromium code base. I don't think Opera, Brave, Microsoft, Mozilla or anyone else that decides to either be a downstream user of or active participant in Chromium will be able to keep Google from doing whatever is in their best interest with the code base. Additionally, I think keeping patch sets (that won't end up being very complicated and will slow down or put to a grinding halt independent development) won't be able to make up for the implementation differences caused by the differences in goals. Keeping patch sets can be extremely painful.
> Chromium is open source and has those two main actors: opera and Microsoft.
I really apologize for my tone, but... Please. In what regard are they main actors? Certainly not to the extent that they have any significant control over the main direction of the Chromium code base or any power to stop Google from completely controlling it.
The core beliefs and goals of the entity exerting the main control over the code base matters a lot more than your post makes it sound like. And if Chromium really were the only code base able to browse the modern web, then that would also put the standardization of the World Wide Web more or less in Googles hands.
Also, for someone asking for better "intellectual riguour", you do a pretty so-so job at showing your understanding of the arguments of the people you don't agree with.