1. 8
    1. 3

      Anything with the word “5G” so far seems to be marketing copy.

      1. 2

        The useful information is from Delivering Functionality on downward. This describes some of what it takes to sell to and collaborate with enterprises. It’s a path that might lead quite a few FOSS projects to profitability. Most just don’t know what it takes to get there or even have resources to get there. Knowing what it takes is a good start, though.

        1. 5

          So to be really honest, one goal of this article was indeed share this knowledge, what does it take to sell to big enterprises. How can you make money with open source? Well, not with the software. A great article about sales to big enterprise is https://techcrunch.com/2010/11/13/new-enterprise-customer/?guccounter=1

          Secondly, this article practices what it preaches - it tells people within large enterprises “we get it, we know how your company works, please buy from us”. So Friendlysock has a valid point. But I hope the educational part on FOSS sales was worth it.

          1. 1

            Thanks for the article. It’s a good intro to the problems. I might share it with folks. I do want to address a potential myth:

            “ How can you make money with open source? Well, not with the software.”

            When arguing about licensing, I said that to folks on Hacker News. A few countered me that you can in fact sell GPL software. Stallman even encouraged it. Two examples were interesting. One said his company licensed tens of millions a year in GPL software to enterprises. That turned out to be SUSE, which maybe outlier like Red Hat. The other built custom software for mid-sized businesses which wasn’t necessarily a competitive advantage or secret sauce: just smoothed over internal processes. With company’s permission, he always licensed the apps as GPL since there’s potential benefits but no harm. There were also dual-licensed offerings but I’m focusing on F/OSS specifically.

            They gave me a few reasons companies would buy FOSS. Primary one is someone to blame for problems. You mentioned that in your article but maybe overlooked how it carries onto selling FOSS. Some other people said licensing and support are looked at differently in many enterprise. One is a justifiable operational expense adding value with support something that’s considered a liability to minimize. I have little data on this claim past anecdotal experience of non-FOSS projects that did fit that pattern. Yet another was long-term viability with a vendor that had been around for a while and would be around for a while. That kind of fits in with support but is also risk management issue. That’s my list of reasons an enterprise might license F/OSS software that they could get for free with or without support.

            What’s your thoughts or experiences on those?

      1. 1

        Matplotlib has always been great but seaborn has higher-level abstractions that make some graphs and showing relationships much easier. Since seaborn layers on top of matplotlib, you can still leverage some of the detailed matplotlib knobs when seaborn alone can’t quite tweak the presentation just as you’d like.

        1. 7

          I recommend against anybody using seaborn, for reasons I’ve stated before here

          Edit: Looks like the developer has gone so far as to delete the issue. Even more reason to avoid IMHO.

          1. 4

            I actively considered & was urged to include Seaborn in this post. But on closer look I could not immediately provide the intended user with any advantages based on Seaborn. I tried to find a plot based on the datasets in the post where Seaborn would shine, but couldn’t find anything.

            1. 1

              Looks like the developer has gone so far as to delete the issue. Even more reason to avoid IMHO.

              I agree: assuming your description of the situation and the HN comments are all accurate, it doesn’t look good for the project’s maintainer(s).

              I would charitably assume that mwaskom mistakenly assumed your question was a misunderstanding of how seaborn/matplotlib works. And just maybe it’s the intended design. It looks as if mwaskom is particular about sweeping GH issues, so I could expect that he may have overlooked the importance of the issue that you identified. Maybe I’m bending over backwards here but – Hanlon’s razor – he may have deleted the issue because he recognizes that it makes him look rash or foolish and he’s embarrassed by the error.

              I don’t think I’d stop using seaborn over this, but I will certainly evaluate its output much more critically now that you’ve brought it up.

          1. 4

            (author here - if you have any questions or remarks please let me know!)

            1. 15

              Rust meanwhile notes that you can’t safely write a performant data structure in Rust, so they urge you not to do that.

              The interesting thing to me is the linked FAQ (https://www.rust-lang.org/en-US/faq.html#can-i-implement-linked-lists-in-rust) literally doesn’t say that.

              It says:

              1. Efficient implementations of many data structures are provided by the standard library.
              2. Most data structures can be done in safe Rust, but for comparable performance, some would be better implemented using unsafe Rust. Not that it is impossible.
              3. Goes on to provide a specific example of how to do a doubly linked list in safe Rust, and describes how to do it also with unsafe Rust for better performance.

              I wonder if this was an oversight or misunderstanding?

              1. 10

                As a follow-up, in the conclusion you say:

                I think that in practice they may not be making real life shipped code a lot more secure - also because not that much actual Rust code is shipping.

                While just one of the undoubtedly many examples which could be brought up, I hadn’t realized the Quantum CSS engine from Firefox was so short! More seriously, the achievements in Firefox are remarkable and inspiring, and is a large amount of code shipping to real users, and used every day.


                One thing I like very much about the borrow checker is it took memory access problems and turned it in to a generic resource safety problem. Using the simple primitives available I’m able to easily encode usage requirements, limitations, and state changes through borrows and Drops and have them checked at compile time. This is really powerful, and I very much appreciate it.

                For whatever it is worth, I’m a rubbish C dev – not to be trusted to write a single line – who has found Rust to be an comfortable and pleasant experience in only a few weeks of free-time practice.

                1. 2

                  Hi - I worded this incorrectly. What I meant to say was that the FAQ says performance will disappoint unless you go into unsafe mode. “For example, a doubly-linked list requires that there be two mutable references to each node, but this violates Rust’s mutable reference aliasing rules. You can solve this using Weak, but the performance will be poorer than you likely want. With unsafe code you can bypass the mutable reference aliasing rule restriction, but must manually verify that your code introduces no memory safety violations.”. I’ve updated the wording a bit. Apologies for the confusion.

                  1. 6

                    It is improved, but they don’t urge you to not do it. However, still, unsafe Rust is still safer than C.

                    1. 3

                      Oh boy, what a quote.

                      1. 4

                        It definitely is in context of bigger picture. The default in C for doing Rust’s level of safety is separation logic with tools like VCC. Hard to learn, slow to develop (2loc/day at one point), and solvers likely slower than compiler checks. Rust brought that level of safety to most apps using a simplified model and checker. Both the checker and resulting code usually perform well. The quote indicates it can’t handle some optimized, low-level, data structures. Those atypical cases will need verification with external tool or method.

                        In light of that, Rust gets safer code faster than C in most verification cases but maybe equivalent labor in some. Rust still seems objectively better than C on being safe, efficient, and productively so.

                        1. 2

                          there are languages in which linked lists are primitives or maybe even invisible. But if you are going to specify a language for writing programs that include linked lists, you should not have to use pragmas. This is a characteristic computer science trope: “we have a rigorous specification of this which cannot ever be violated unless you push the magic button”. It’s a way of acting as if you have solved a problem that you have simply hidden.

                  1. 7

                    Interesting this was written by a powerDNS person, they are a very smart and helpful group of people and the PowerDNS codebase is a good read.

                    1. 1

                      Thanks Shane! We try :-) blush

                    1. 30

                      I enjoyed the author’s previous series of articles on C++, but I found this one pretty vacuous. I think my only advice to readers of this article would be to make up your own mind about which languages to learn and use, or find some other source to help you make up your mind. You very well might wind up agreeing with the OP:

                      Programmers spend a lot of time fighting the borrow checker and other language rules in order to placate the compiler that their code really is safe.

                      But it is not true for a lot of people writing Rust, myself included. Don’t take the above as a fact that must be true. Cognitive overheads come in many shapes and sizes, and not all of them are equal for all people.

                      A better version of this article might have went out and collected evidence, such as examples of actual work done or experience reports or a real comparison of something. It would have been a lot more work, but it wouldn’t have been vacuous and might have actually helped someone answer the question posed by the OP.

                      Both Go and Rust decided to special case their map implementations.

                      Rust did not special case its “map implementation.” Rust, the language, doesn’t have a map.

                      1. 16

                        Hi burntsushi - sorry you did not like it. I spent months before this article asking Rust developers about their experiences where I concentrated on people actually shipping code. I found a lot of frustration among the production programmers, less so among the people who enjoy challenging puzzles. They mostly like the constraints and in fact find it rewarding to fit their code within them. I did not write this sentence without making sure it at least reflected the experience of a lot of people.

                        1. 20

                          I would expect an article on the experience reports of production users to have quite a bit of nuance, but your article is mostly written in a binary style without much room for nuance at all. This does not reflect my understanding of reality at all—not just with Rust but with anything. So it’s kind of hard for me to trust that your characterizations are actually useful.

                          I realize we’re probably at an impasse here and there’s nothing to be done. Personally, I think the style of article you were trying to write is incredibly hard to do so successfully. But there are some pretty glaring errors here, of which lack of nuance and actual evidence are the biggest ones. There’s a lot of certainty expressed in this article on your behalf, which makes me extremely skeptical by nature.

                          (FWIW, I like Rust. I ship Rust code in production, at both my job and in open source. And I am not a huge fan of puzzles, much to the frustration of my wife, who loves them.)

                          1. 4

                            I just wanted to say I thought your article was excellent and well reasoned. A lot of people here seem to find your points controversial but as someone who programs C++ for food, Go for fun and Rust out of interest I thought your assessment was fair.

                            Lobsters (and Hacker News) seem to be very favourable to Rust at the moment and that’s fine. Rust has a lot to offer. However my experience has been similar to yours: the Rust community can sometimes be tiresome and Rust itself can involve a lot of “wrestling with the compiler” as Jonathan Turner himself said. Rust also provides some amazing memory safety features which I think are a great contribution so there are pluses and minuses.

                            Language design is all about trade-offs and I think it’s up to us all to decide what we value in a language. The “one language fits all” evangelists seem to be ignoring that every language has strong points and weak points. There’s no one true language and there never can be since each of the hundreds of language design decisions involved in designing a language sacrifices one benefit in favour of another. It’s all about the trade-offs, and that’s why each language has its place in the world.

                            1. 10

                              I found the article unreasonable because I disagree on two facts: that you can write safe C (and C++), and that you can’t write Rust with fun. Interpreted reasonably (so for example, excluding formally verified C in seL4, etc.), it seems to me people are demonstrably incapable of writing safe C (and C++), and people are demonstrably capable of writing Rust with fun. I am curious about your opinion of these two statements.

                              1. 8

                                I think you’re making a straw man argument here: he never said you can’t have fun with Rust. By changing his statement into an absolute you’ve changed the meaning. What he said was “Rust is not a particularly fun language to use (unless you like puzzles).” That’s obviously a subjective statement of his personal experience so it’s not something you can falsify. And he did say up front “I am very biased towards C++” so it’s not like he was pretending to be impartial or express anything other than his opinion here.

                                Your other point “people are demonstrably incapable writing safe C” is similarly plagued by absolute phrasing. People have demonstrably used unsafe constructs in Rust and created memory safety bugs so if we’re living in a world of such absolute statements then you’d have to admit that the exact same statement applies to Rust.

                                A much more moderate reality is that Rust helps somewhat with one particular class of bugs - which is great. It doesn’t entirely fix the problem because unsafe access is still needed for some things. C++ from C++11 onwards also solves quite a lot (but not all) of the same memory safety issues as long as you choose to avoid the unsafe constructs, just like in Rust.

                                An alternative statement of “people can choose to write safe Rust by avoiding unsafe constructs” is probably matched these days with “people can choose to write safe C++17 by avoiding unsafe constructs”… And that’s pretty much what any decent C++ shop is doing these days.

                                1. 5

                                  somewhat with one particular class of bugs

                                  It helps with several types of bugs that often lead to crashes or code injections in C. We call the collective result of addressing them “memory safety.” The extra ability to prevent classes of temporal errors… easy-to-create, hard-to-find errors in other languages… without a GC was major development. Saying “one class” makes it seem like Rust is knocking out one type of bug instead of piles of them that regularly hit C programs written by experienced coders.

                                  An alternative statement of “people can choose to write safe Rust by avoiding unsafe constructs” is probably matched these days with “people can choose to write safe C++17 by avoiding unsafe constructs”

                                  Maybe. I’m not familiar with C++17 enough to know. I know C++ was built on top of unsafe language with Rust designed ground-up to be safe-as-possible by default. I caution people to look very carefully for ways to do C++17 unsafely before thinking it’s equivalent to what safe Rust is doing.

                          2. 13

                            I agree wholeheartedly. Not sure who the target survey group was for Rust but I’d be interested to better understand the questions posed.

                            Having written a pretty large amount of Rust that now runs in production on some pretty big systems, I don’t find I’m “fighting” the compiler. You might fight it a bit at the beginning in the sense that you’re learning a new language and a new way of thinking. This is much like learning to use Haskell. It isn’t a good or bad thing, it’s simply a different thing.

                            For context for the author - I’ve got 10 years of professional C++ experience at a large software engineering company. Unless you have a considerable amount of legacy C++ to integrate with or an esoteric platform to support, I really don’t see a reason to start a new project in C++. The number of times Rust has saved my bacon in catching a subtle cross-thread variable sharing issue or enforcing some strong requirements around the borrow checker have saved me many hours of debugging.

                            1. 0

                              I really don’t see a reason to start a new project in C++.

                              Here’s one: there’s simply not enough lines of Rust code running in production to convince me to write a big project in it right now. v1.0 was released 3 or 4 years ago; C++ in 1983 or something. I believe you when you tell me Rust solves most memory-safety issues, but there’s a lot more to a language than that. Rust has a lot to prove (and I truly hope that it will, one day).

                              1. 2

                                I got convinced when Rust in Firefox shipped. My use case is Windows GUI application, and if Firefox is okay with Rust, so is my use case. I agree I too would be uncertain if I am doing, say, embedded development.

                                1. 2

                                  That’s fair. To flip that, there’s more than enough lines of C++ running in production and plenty I’ve had to debug that convinces me to never write another line again.

                                  People have different levels of comfort for sure. I’m just done with C++.

                            1. 18

                              I suppose I know why, but I hate that D is always left out of discussions like this.

                              1. 9

                                and Ada, heck D has it easy compared to Ada :)

                                1. 5

                                  Don’t forget Nim!

                                2. 3

                                  Yeah, me too. I really love D. Its metaprogramming alone is worth it.

                                  For example, here is a compile-time parser generator:

                                  https://github.com/PhilippeSigaud/Pegged

                                  1. 4

                                    This is a good point. I had to edit out a part on that a language without major adoption is less suitable since it may not get the resources it needs to stay current on all platforms. You could have the perfect language but if somehow it failed to gain momentum, it turns into somewhat of a risk anyhow.

                                    1. 4

                                      That’s true. If I were running a software team and were picking a language, I’d pick one that appeared to have some staying power. With all that said, though, I very much believe D has that.

                                    2. 3

                                      And OCaml!

                                      1. 11

                                        In my opinion, until ocaml gets rid of it’s GIL, which they are working on, I don’t think it belongs in this category. A major selling point of Go, D, and rust is their ability to easily do concurrency.

                                        1. 6

                                          Both https://github.com/janestreet/async and https://github.com/ocsigen/lwt allow concurrent programming in OCaml. Parallelism is what you’re talking about, and I think there are plenty of domains where single process parallelism is not very important.

                                          1. 2

                                            You are right. There is Multicore OCaml, though: https://github.com/ocamllabs/ocaml-multicore

                                        2. 1

                                          I’ve always just written of D because of the problems with what parts of the compiler are and are not FOSS. Maybe it’s more straightforward now, but it’s not something I’m incredibly interested in investigating, and I suspect I’m not the only one.

                                          1. 14