1. 2

    Gun also supports websockets, something I’d like to explore more. It’s good to see an example of some of its features used in Elixir!

    1. 6

      Your comment made me realize I totally forgot to tag Elixir too! We mostly use Hackney right now (via Tesla) and we’ve generally been happy, but I’d be pretty excited to see a Gun adapter.

      1. 1

        Testla is AWESOME and so is Hackney.

        1. 1

          I just happened to check recent activity in the Tesla repo and saw a Gun adapter PR was recently merged! Figured I’d update this thread for anyone else still actually paying attention :)

    1. 1

      I read several paragraphs and couldn’t figure out what this article is about. Something to do with live streaming video I think?

      1. 2

        Ah yeah, there’s some jargon in there. Apple has a streaming format called HLS, and they recently announced their plan to support lower latency streaming via that format. That flew in the face of some community extension efforts and is going to be quite problematic for a lot of the major CDNs to support, so it’s a big discussion in the online video community right now.

        1. 2

          I appreciate the clarification!

      1. 15

        Some of the NewPipe features really do look great, but this feels like a lot of gushing over a GUI on top of an actual platform. A nontrivial amount of the post could be distilled down to:

        NewPipe is great because it allows you to circumvent monetization for both the creators and their platform because I don’t agree with the platform’s price point (oh also, consider using a random 3rd party to donate what you feel is fair to the creators and not said platform).

        I’m not saying we should all shed a tear for Google’s lost revenue or anything, but is that really “the best of FOSS”?

        1. 18

          Supporting creators directly almost always nets them 10x the revenue that you’d generate by pointing your eyeballs at ads, and it’s far less annoying for users, and far more personal and genuine for both parties.

          As for the platform, bandwidth isn’t cheap and that’s worth something. I hope that PeerTube continues to grow into a viable alternative.

          1. 6

            Yep, I agree! Ads are inefficient and terrible for basically everyone involved (except for exchanges/brokers), which is why I almost always welcome a way to simply pay for services, especially ones I use all the time (like YouTube).

            Edit: Just to clarify, by the way, I think you make a lot of good points about what makes NewPipe great (and it does look great). I’m not trying to be Smart Negative Guy™, more just trying to think through the monetization side of things and how that relates to “the best of FOSS.” If we value free, open delivery of video with a great featureset, shouldn’t NewPipe just front PeerTube?

            1. 8

              If we value free, open delivery of video with a great featureset, shouldn’t NewPipe just front PeerTube?

              We do value that, and for important reasons. However, this gets back to a point I made in the article:

              There are a lot of political and philosophical reasons to use & support free and open source software. Sometimes it’s hard to get people on board with FOSS by pitching them these first. NewPipe is a great model because it’s straight up better, and better for reasons that make these philosophical points obvious and poignant.

              People are already using YouTube, already follow their favorite creators there, and can use NewPipe to get a better experience using the platform and content they’re familiar with - and happen to a great introduction to why free software is important in so doing.

              Yes, the utopian ideal PeerTube represents is something to strive for and I hope that we get there (and will personally help where I can to get us there) - but it’s harder to understand why it’s important to someone who doesn’t already understand free software. PeerTube isn’t necessarily objectively better, either, there are still some streaming problems, it’s missing a lot of content creators, there’s little mobile support, etc. NewPipe, on the other hand, makes these arguments immediately self-evident and is a compelling piece of software in its own right.

            2. 4

              The point with a lot of this is that it’s the creator that gets to choose how to get money. Like yeah “you’re choosing against your own interests” but the creator is choosing the terms, and I feel like it’s not really up to us to say “actually no I want your stuff but I refuse to look at the ads”

              I’d like to support creators directly, and would like for stuff to be easier for creators to survive. Just think respecting the creators choices are important as well

            3. 6

              Do you consider ad blockers to be stealing?

              1. 4

                I, at least, pay a subscription for YouTube. If they don’t like the fact that I use an ad blocker, they can stop taking my money.

                1. 2

                  If you’re paying for YouTube, do you even need an ad-blocker for it? I was under the impression that paying removes the ads…

                  1. 3
                    1. It still blocks Google Analytics.
                    2. I still need it for the rest of the web, and I never bothered adding an exception since it still works.
                2. 3

                  I think that gets tricky, but keeping to YouTube’s case, I pay $12/mo for the service and still use a privacy blocker.

                  Ads undeniably are a privacy nightmare, which is why I personally use one. I also opt for a pay option when I can, such as blendle for news. What I do think gets less ethically ambiguous on that front is when a service does offer a paid option without ads, but the response is simply “I don’t want to pay for it.”

                  1. 6

                    YouTube does not forbid blocking ads. Blocking ads without paying is allowed by YouTube, so it can’t be stealing. At best it is diligently collecting coupon to take advantage of price discrimination.

                    1. 2

                      From the YouTube API terms:

                      You and your API Clients must not, and must not encourage, enable, or require others to:

                      1. modify, interfere with, replace, or block advertisements placed or served by YouTube or by YouTube API Services including in API Data, YouTube audiovisual content, or YouTube players;
                      1. 8

                        That term is about YouTube API Services, which is explicitly not YouTube websites. See section IV.

                        The comment was not really specific to YouTube. Collecting discount coupons is not stealing from Walmart. Usually, blocking ads is also not stealing from websites.

                1. 4

                  Agreed. I’m very up on the idea of getting more languages to run on the BEAM. I miss static types and, frankly, I wish that Rust could compile down to run on the BEAM!

                  1. 5

                    Yeah, I love Elixir to death, but sometimes I find myself wishing for a real type system. Some folks swear by Dialyzer, but it feels a bit like a cludgy piece of typing duct tape.

                    1. 12

                      The dynamically-typed nature of Erlang and Elixir and BEAM comes from a design requirement: that the systems built in Erlang can be upgraded at runtime. Strong typing gets quite a bit more complicated when you need to be able to have multiple versions of a type coexist at runtime.

                      Side note, this took me a while to absorb when beginning to write Elixir. My instinct was to use structs instead of generic maps for GenServer state, since better-defined types are better, right? But that imposes hard requirements on hot upgrades that wouldn’t have been there if I’d used untyped maps from the start; removing fields from a struct breaks upgrades. This knowledge was somewhere between “esoteric” and “esoteric to Ruby assholes who just showed up, well-known to wonks”. The Erlang Way is a lot more than “let it crash”. :)

                      1. 3

                        The dynamically-typed nature of Erlang and Elixir and BEAM comes from a design requirement: that the systems built in Erlang can be upgraded at runtime. Strong typing gets quite a bit more complicated when you need to be able to have multiple versions of a type coexist at runtime

                        Yeah, I really wish there was more type system research going into figuring out how to use them effectively in upgradable, always-on systems, where you might have heterogeneous versions across a cluster. I actually think static types could be super helpful here, but as far as I’m aware there doesn’t seem to be much work put into it.

                        1. 4

                          It’s very difficult. It’s not like nobody tried — https://homepages.inf.ed.ac.uk/wadler/papers/erlang/erlang.pdf

                          And when people talk about “I wish there was a type system” they probably don’t realise that Erlang is very different animal (that can do things other animals have no concepts for). Just bolting on types is not an option (if you want to know what happens if you do so, look at CloudHaskell — you have to have a exact binary for every node in the entire cluster, or else).

                          1. 1

                            Just bolting on types is not an option (if you want to know what happens if you do so, look at CloudHaskell — you have to have a exact binary for every node in the entire cluster, or else).

                            That’s what I mean. I see Cloud Haskell as interesting, but really not the distributed type system I want. It would be super cool to see more new ideas here (or rediscovery of old ones, if they’re around). Eg. you may need some kind of runtime verification step to ensure that a deployment is valid based on the current state of the world. Perhaps some stuff from databases and consensus would help here. Doing that efficiently could be… interesting. But that’s why research is important!

                          2. 3

                            I think protocol buffers (and similar systems like Thrift / Avro) are pretty close to the state of the art (in terms of many large and widely deployed systems using them). When you write distributed systems using those technologies, you’re really using the protobuf type system and not the C++ / Java / Python type system. [1] It works well but it’s not perfect of course.

                            I also would make a big distinction between distributed systems where you own both sides of the wire (e.g. Google’s), and distributed systems that have competing parties involved (e.g. HTTP, e-mail, IRC, DNS, etc.). The latter case is all untyped because there is a “meta problem” of agreeing on which type system to use, let alone the types :) This problem is REALLY hard, and I think it’s more of a social/technological issue than one that can be addressed by research.

                            [1] This is a tangent, but I think it’s also useful to think of many programs as using the SQL type system. ORMs are a kludge to bridge SQL’s type system with that of many other languages. When the two type systems conflict, the SQL one is right, because it controls “reality” – what’s stored on disk.

                            1. 2

                              I think protocol buffers ⟨…⟩ are pretty close to the state of the art

                              Seriously? PB, where you can’t even distinguish between (int)-1 and (uint)2 is state of the art?

                            2. 2

                              Alice ML is a typed programming language designed to enable open extensions of systems. Objects can be serialized/deserialized and retain their types and it’s possible to dynamically load new code.

                            3. 2

                              The Erlang Way is a lot more than “let it crash”. :)

                              I am so with you on this one, and I’ve got so much to learn!

                              1. 6

                                You might find ferd’s intro helpful. For historical perspective with some depth, you might like Armstrong’s thesis from 2003 that describes everything in deep detail.

                              2. 2

                                Yup, this is related to the point I was making about protobufs and static “maybe” vs. dynamic maps here. In non-trivial distributed systems, the presence of fields in message has to be be checked at RUNTIME, not compile-time (if there’s a type system at all).

                                https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey#c_povjwe

                                I think of protobufs/thrift as trying to “extend your type system over the network”. It works pretty well, but it’s also significantly different from a type system you would design when you “own the world”. Type systems inherently want a global view of your program and that conflicts with the nature of distributed systems.

                                edit: this followup comment was more precise: https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey#c_jc0hxo

                              3. 2

                                So this is really interesting. I read the paper on success typing and it seems pretty cool. It still, however, doesn’t guarantee soundness. Then on the other hand, neither does TypeScript, so it’s hard for me to make up my mind about what I want.

                              4. 4

                                That would be cool. There’s at least Rustler.

                                1. 4

                                  Static types per se — that’s easy. But think about the distributed system with different versions of VMs. Think about live upgrades.

                              1. 2

                                Going to a Vince Staples show in Oakland tonight! Otherwise, I’m unreasonably excited about doing laundry and hanging out with my dog. I’ve been traveling a lot lately with more coming up, so it’ll be nice to just…not.

                                1. 2

                                  i blinked a bit at the fact that this was all expected to be done in a week, but i guess the senior engineer who asked to use reason was aware of the scope of the project.

                                  1. 2

                                    I had the same reaction. I’m really curious about ReasonML, but the learning curve (particularly for a junior engineer) feels like it would be pretty wild.

                                    1. 2

                                      My guess is the POC was done in a week. She does mention spending at least a month working on ReasonML in both backend and frontend, so it sounds like it was an ongoing effort.