1. 30
  1.  

  2. 15

    Besides Rust and Go, Ocaml also fits those three bullets. The software 0install was ported from Python to Ocaml in the best (less biased, easiest to comprehend) refactoring stories I’ve read:

    http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ (the first two posts in the series sets up a test for the author to complete in a bunch of languages, which he then holds an interim retrospective of)

    Not that Ocaml has much buzz (from my view), except for Reason/Bucklescript, and some things from Jane Street.

    1. 6

      I share your feelings.

      When I read the white paper, I thought that Haskell, Ocaml and even (especially?) ATS would fit the same requirements.

      But as many have noted, it’s a opinionated white paper to work as a programming language marketing.

      1. 5

        They seem to be wanting something that can pull in wide net of mainstream developers. Most don’t know Haskell or ATS. The second they’ll really have trouble with. Ocaml seems like it has a bigger community but it not very mainstream. Whereas, there’s piles of developers all over the languages they considered with Rust growing in that direction faster than most new languages.

        So, I think it was right for a Javascript shop to ignore stuff like ML’s, Haskell, and ATS.

    2. 16

      Quite the bait and switch here. We’re lead to think that we’re going to get a performance comparison between node, Go and Rust. Instead we’re told that the hardest and longest to implement is best because the dependency management toolchain in better and the community was nice. No mention of performance or that the Go implementation was faster to develop and presumably easier and didn’t require community help.

      1. 6

        because the dependency management toolchain in better

        It’s a fair point on the baity feel, but I’m not terribly surprised that a company organized around dependency management gravitated to the toolchain with the best dependency management. ;)

      2. 4

        Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers.

        Haha, what a load of crap, just admit you don’t like java. We should be honest about these things.

        1. 34

          Please don’t dismiss people by telling them you know their own opinions better than they do or that they’re lying. There’s much better ways to disagree with their decision here.

          1. 8

            It’s a case study for promoting Rust…I wouldn’t judge it the same as dismissing somebody’s own blog post or whatever, say.

            1. 3

              It’s dismissing people’s experience. The medium is irrelevant.

              1. 21

                Sometimes people’s experiences are not representative of reality, and sometimes people lie about their experiences, and sometimes people rewrite their experiences without realizing it, and sometimes people have experiences so limited that their ability to usefully generalize and advise others is called into question.

                Just because it’s somebody’s claimed experience doesn’t magically make it somehow unable to be questioned.

                And so we’re on the same page…we’re not talking about somebody relating a background of trauma or something: we’re talking about a company (npm) engineering team deciding to redo the same task three times using 1 hour (Node), 2 days (Go), and a week (Rust) and then the RESF using that to shill Rust (glossing over a doubling in the complexity of the npm’s language ecosystem and stack.

                If they’d provided real performance numbers, maybe shown how the Rust version vastly outperformed the Node version, then this might be a better article. As it is, anybody with experience reading press releases (rightly) will wonder if the “experiences” are worth learning from.

                1. 3

                  What exact claim do you find insufficiently backed up? They literally just documented the (their!) process of rewriting a chunk of JS in a different language, and how it went (for them). To get back to the original “page”: The “claim” ac was attacking was an opinion, a non-falsifiable statement at worst (as I think the conclusion is).

                  1. 17

                    There are no numerical metrics or benchmarks in the article. The service in question was “projected to become a CPU-bound task”, but it’s unclear if that’s a real issue without seeing their math. Other quotes like “the legacy JavaScript implementation of this service in Node.js was in need of a rewrite in any case” hint that this might be a strictly unnecessary rewrite.

                    Have you not experienced engineers selling a rewrite or new technology because they’re bored and not because it’s necessary?

                    1. -5

                      Ugh. Nobody is selling you anything here.

                      1. 13

                        “Rust Case Study:” “Copyright © 2019 The Rust Project Developers” “https://www.rust-lang.org

                        It’s on there specifically to convince people to adopt Rust. Which is fine: they’re promoting their work and how others benefit from it on their project page. (shrugs) It doesn’t bother me as much as friendlysock since I got at least two things out of it:

                        (a) Javascript developers were able to adopt it. That’s good to know in long term since I’m for minimizing Javascript use in general. Rust apps will also be more secure and maybe predictable. The typical predictions so far were that it would win over only C and C++ types, not Javascript and Go. This is a data point against that expectation for Javascript in an unlikely place.

                        (b) The Rust apps caused less problems, possibly due to what I just said. Then again, it could be anything since we have no data. Might not even be Rust. Heck, the Go rewrite might have taught them some lesson they reused when making the Rust version. We don’t know.

                        Now, far as a scientific evaluation, there’s nothing more to go on as friendlysock says. They didn’t even give us numbers. We’d also be interested in what was easy, difficult, and so on at a language level for the work they were doing. What they told us was what everyone writes, including Rust project’s marketing pages. It objectively introduces no new information on a technical level that we can evaluate or build on.

                        1. 2

                          We’d also be interested in what was easy, difficult, and so on at a language level for the work they were doing.

                          The did mention that the Rust implementation was more difficult, though.

                          “Therewriteof the authorization service using Node.js tookabout an hour. … The Go rewritetook two days. … The rewrite of the service in Rust did take longer than both the JavaScript version and the Go version: about a week to get up to speed in the language and implement the program. Rust felt like a more difficult programming language to grapple with.”

                          1. 2

                            Almost all things on Rust mention a learning curve with borrow-checker (or language), cargo being great, and a great community. Mentioning that downside is echoing common claims more than anything extra critical at this point. It’s part of the refrain.

                            You mentioning this did bring another data point I overlooked: they felt up to speed in Rust in about a week. So, Javascript developers both found the language useful and picked it up in a week. Or at least did for that one type of service well enough to falsely think they understood it in general. See how we’re still lacking objective data? We have a nice anecdote, though, which justifies trying to train a crowd of JS developers on Rust on similar or different projects to see what happens.

                            1. 1

                              See how we’re still lacking objective data?

                              That’s not a surprise to me, since I believe that the programming language field is at least a century away from having the capability of gaining objective data on anything non-trivial. We’re like surgeons ridiculing the guy who washes his hands before operating.

                              I guess that guy is Rust.

                              1. 3

                                It’s a frequent complaint we have. We’d love to have more data to compare us to.

                        2. 6

                          Nobody is selling you anything

                          Companies don’t just publish information randomly. A white paper is a standard marketing device (https://en.wikipedia.org/wiki/White_paper#In_business-to-business_marketing).

                          In this case they’re selling:

                          1. NPM as a rigorous engineering culture (recruiting), and
                          2. JavaScript-Rust ecosystem cohesion (technology)
                          1. 3

                            Exactly, we use whitepapers in precisely this fashion. They are basically executive tl;drs and as such gloss over details.

              2. 2

                Did you really need use Sysop hat to say that?

                1. 3

                  hatters gonna hat.

                2. 0

                  Perhaps the ‘haha’ didn’t convey my tone right. I meant it as a jab/joke, the type of thing you would say to make fun of your friend…

                  ‘cmmmoooon, my friend… just admit it, you don’t like java … nenornenornenor … lets go play tag’

                  1. 0

                    Also, I didn’t say lying… I think I was more implying a level of self delusion.

                  2. 19

                    Those are valid complaints. Deploying a Java service requires deploying at minimum 2 things that must be kept in sync. A JVM and a Java jar.

                    Because they are separate they bring a number of deployment and operations issues for the life of the service. Rust being a single binary removes those issues entirely.

                    There are resolutions for all those in Java too but they all require more effort than Rust does.

                    1. 12

                      Of all the other things you have to do to run or build service - that seems like a drop in the bucket of things to care about to me.

                      How many backwards incompatible changes are the JVM’s making these days anyway?

                      1. 14

                        Quite a few, actually.

                        I am no JVM expert but in my experience as a Clojure application developer it’s quite common for new Java releases to break Clojure and/or widely-used Clojure libraries. It’s happened several times in the last year. At work, we are currently on an older Java release for this reason. Right now, the latest Java has a serious performance regression for some fairly-common Clojure use cases and folks are being advised not to upgrade.

                        1. 2

                          that does sound pretty lame.

                        2. 3

                          It’s not so much the JVM’s backward incompatibilities as the JAR’s that are dependent on the latest and greatest JVM, except that one old JAR that only works on some old ancient version.

                          So you end up running multiple JVM’s across various machines, to make various JAR’s happy. Suddenly you start day dreaming of rust or go built binaries…

                          But generally I agree, JVM nightmares aren’t that miserable compared to 5,000 external service dependencies you may have to operate just to make X work.

                        3. 3

                          Shouldn’t that be easily automated, either provision the server with a pre-installed JVM (using ansible? etc.) or use Docker and put the JVM in there as is common?

                          1. 1

                            The most future proof method is to use a Docker container.

                          2. 4

                            They’re already doing the exact same thing with Node and the JS code that it runs.

                            1. 5

                              Sure, but that’s no reason to go through the same pain a second time. I put up with many things in the Python packaging world because I already know and use Python, but I am not willing to invest time in learning an ecosystem that exhibits issues anywhere close to that.

                            2. 2

                              But deploying any service is already tracking versions of databases, the state of your app, the code + compatibility with the OS. I don’t think avoiding java solves dependency or state management.

                            3. 8

                              While I think you phrased this strongly, I’m also puzzled by the quote. The legacy application being replaced is a node app. Running a node app requires a VM and standard library just as running a JVM app does. What is the overhead that makes a JVM app unacceptable while a node app is ok? Perhaps it’s language/tooling familiarity? In my experience, all those three-letter J** acronyms can get fairly confusing.

                              As an aside, I found the following quote refreshingly honest -

                              “I wouldn’t trust myself to write a C++ HTTP application and expose it to the web”

                              1. 7

                                Maybe you haven’t read the full article? it literally says

                                Given the criteria that the programming language chosen should be:

                                ● Memory safe

                                ● Compile to a standalone and easily deployable binary

                                ● Consistently outperform JavaScript

                                of which Java doesn’t fulfill at least one.

                                1. 1

                                  @ac’s comment doesn’t indicate that he missed that part of the article. He is challenging the premise of the second bullet point. The statement about Java that he quoted was the implicit justification for that bullet point.

                                  1. 1

                                    I don’t agree, I think the bullet point was the justification for the statement about Java and not the other way around. At least logically this makes more sense. You do have a point though about the order in the document:)

                                  2. [Comment removed by author]

                                    1. 3

                                      He said at least one, and I suspect he meant “Compile to a standalone and easily deployable binary”.

                                      1. 1

                                        You’re right, I misinterpreted the “at least one” part.

                                        1. 2

                                          Sorry for the confusion, I did indeed mean it as @zmitchell interpreted it!

                                    2. 1

                                      Pretty sure graal vm java does all of those.

                                      1. 3

                                        It’s also commercially licensed by Oracle.

                                        1. 1

                                          from http://www.graalvm.org/downloads/

                                          License

                                          All open-source

                                          Free for production use

                                          1. 2

                                            The community edition. Enterprise edition:

                                            • Free for evaluation and other non-production uses
                                            • Improved performance and smaller footprint
                                            • Sandboxing capabilities for native code
                                            1. 1

                                              Twitter runs on the community edition for all production services and have impressive numbers. Search for talks by Chris Thalinger on YouTube to learn more.

                                              1. 1

                                                Yep, it’s still not “it’s free”, but “it has free variant”. Oracle is no stranger to changing the licensing, as they have recently shown with the mainline oracle JVM.

                                                Not wanting to deal with oracle stuff at all is a reasonable stance.

                                        2. 1

                                          Fair enough, though in this same vein you could argue that C++ is a safe programming language, if you avoid the “thorns”;)

                                      2. 4

                                        It’s a real issue. I stumbled across this “warp” project that makes standalone app bundles for the Buck build system and Buckaroo package manager, which are written in Java.

                                        https://github.com/dgiagio/warp

                                        If it weren’t an issue, then they wouldn’t have done this weird dance. I also took care to make a Python app bundle for Oil for related reasons.

                                        1. 2

                                          I found warp the same way you did :)

                                          but buckaroo is now written in F#

                                          1. 3

                                            We still use Warp, even though Buckaroo is now AOT-compiled F#. The reason is that we have dynamic libraries but still want users to be able to wget the tool for quick installs.

                                        2. 4

                                          It’s a legitimate concern. Having the ability to deploy a single binary easily from CI or the like can greatly reduce ops headaches (Python is a bit of a mess to deploy because it’s hard to do this).

                                        3. 2

                                          npm is a company dedicated to making the management of JavaScript dependencies predictable and effortless, and they expect other ecosystems to have similar world-class dependency management tooling available.

                                          Yeesh. And they picked rust? Sorry, rust, but having observed what happens when people use npm, I’m staying as far away from cargo as possible. I can’t handle that level of predictability. :)

                                          1. 11

                                            I’m still waiting for npm to burn through their Series A and take the Node community with them.

                                            1. 4

                                              Their series A was in 2015, so it’s safe to say they haven’t “burned through” anything by VC standards, whether or not they eventually succeed.

                                              1. 6

                                                The ultimate left-pad.

                                              2. 4

                                                I’m also curious what aspects of go mod (i.e. recent dependency management changes in go) they found unappealing.

                                                1. 7

                                                  The project described predates go mod, hence the “at the time they performed this evaluation”. The Rust services at NPM are actually into production for quite some time now.

                                                  (I admit that could be made clearer, I was not involved in writing the paper)

                                                2. 2

                                                  Could you please elaborate? Like, how could it be better, what they’re doing etc. Because I really really don’t understanding (and I’m willing to) all this hate towards npm.

                                                  1. 6

                                                    Seems like only yesterday we were discussing how worldwide productivity ground to a halt because somebody pushed a bad package to npm and nobody was capable of simply going back to a previous working version.

                                                    https://lobste.rs/s/ztev4w/misconception_about_oss_support

                                                    I mean, I suppose it’s possible for some other package manager or some other ecosystem to have problems too, but literally every story about left pad or backdoored packages stealing crypt wallets or whatever always involves npm front and center.

                                                    1. 3

                                                      I see what you mean, and yes the NPM ecosystem has problems. I don’t think they’re related to the desired features of NPM itself, though, but rather the anemic state of the Javascript standard lib, particularly in ES2015, which creates the desire to publish and use lots of packages for doing common things of trivial complexity that are included in the StdLib of most languages. For whatever faults Rust and Cargo have, they seem to have avoided the issue of having tons of tiny crates/libs, creating huge dependency chains in most significant crates/libs, due to lack of common simple methods in the StdLib.

                                                      I think that this instead calls out how much better the basics of dependency management are in these languages compared to almost all other common languages. How many other compiled languages have a standard dependency management system that supports having a lockfile that ensures that all builds of the application are using the same library code, no matter who or where they are built?

                                                      1. 1

                                                        There are complications because javascript is minimal, but there are major problems with tooling and how npm administers the repo that have nothing to do with that.

                                                        How many other compiled languages have a standard dependency management system that supports having a lockfile that ensures that all builds of the application are using the same library code, no matter who or where they are built?

                                                        Are you talking about npm? Because npm doesn’t do that.

                                                        1. 2

                                                          There may be problems with how NPM administers things, but it sounds like we’re talking about whether Cargo is good or bad. Do you know of Cargo sharing some of the same issues from an organizational/policy perspective that NPM has?

                                                          Are you talking about npm? Because npm doesn’t do that.

                                                          Well I was talking about compiled languages specifically, but AFAICT NPM does do that

                                                          1. 1

                                                            Perhaps I am wrong, but I took @tedu’s comment as a bit tongue-in-cheek. Cargo being better designed than npm, but npm potentially infecting cargo. Maybe that’s how I wanted to read it—I have no allegiance to either community, though.