A few years ago I was a C evangelist. C++ was and more so now is a fine language with a lot of features I want. But Rust has that simplicity in a systems language that I crave that lets me do my own thing. That elegence.
It's my favourite language by far. Keep it up!
Simplicity? Modula-3 was simple, fast, and safe. PreScheme was less type-checked but powerful and simple. You can learn how to use them in a day coming from an imperative or functional language. Rust looks like it gives users extra power/safety with quite a bit of a learning curve (most say weeks to months) due to extra complexity. Definitely not simple, though.
It's definitely simpler than most other systems languages in what it gives you access too. Go, D, C++, C# are all far more complicated than Rust is. I would argue Modula-3 is not as simple because it contains a garbage collector - thus making the connection between written and compiled code less simple. Don't know much about pre scheme
Linq, ick. It's a performance nightmare. No one knows what it is actually doing in the background so firstly, everyone writes horrible O-cubed performance with it, and then it is a series of random poking around to try fixing it.
Depends if you're using it with ORMs or not. It's equally as useful with data in memory. Definitely slower for some things though (yes, it's always slower in one sense... But its also easier to make parallel, so it can even out in the end)
In Rust, you'd generally use functions that return iterators or Tokio's streams for Linq-style tasks. Check out the "Complex Queries" example on http://diesel.rs for an example of what a Linq-like library looks like in Rust.
I suppose it's the difference between the computational model presented by the language verses the computational model presented by the computer. A combination of how many components require some runtime environment to exist and how many disparate language features there are.
Not an intuitive definition of simple for sure, but this is in the context of a system's programming language.
In terms of just plain simple, I'd say scheme or just lambda calculus even takes the cake.
So the fact that that is a scheduler and a garbage collector in go means that by your definition even the simplest go program has a large complexity cost?
Go, at least, is far simpler as a language than Rust, and the implementation (compiler) is less complex overall, especially if you count LLVM on Rust's side. I suppose that Go programs exhibit more complex behavior at runtime due to the GC and green threads and stuff, but it's a huge stretch to call Go more complicated overall.
On the other hand, I'd argue that Rust makes up for the complexity with performance, power (ability to express more complex programs in less code), and safety (not just memory safety, which Go also mostly guarantees, but the ability to leverage the type checker to verify code correctness in general). C++, on the other hand, is more complex (due to all the legacy drift), yet equal in performance, less safe, and less powerful in most respects (there are some things C++ can do that Rust can't, but more things for which the opposite applies).
Consider how interfaces work and how you would have to implement them. Rust may have a more complicated type system and I suppose enums are more complicated in Rust, but the things I value as simple are more simple in Rust than Go.
What about interfaces? The basic idea of fat pointers with vtables works the same as Rust's trait objects. If you mean the ability to dynamically cast from one interface type to another, which Rust doesn't support - that does require a global list of implemented interfaces per type, but without generics that's not too hard to implement. (In Rust, it would be drastically more complex, verging on impossible to pull off with a good UX, due to various language features including wildcard impls, type-parameterized traits, and a Turing-complete type system.)
When ever you would need to box a trait object in Rust Go automatically performs a heap allocation that is garbaged collected at some point.
A bit more is explained here https://research.swtch.com/interfaces
Basically there are some property of Go interfaces that make them far more dynamic than traits and implementations in Rust.
> (In Rust, it would be drastically more complex, verging on impossible to pull off with a good UX, due to various language features including wildcard impls, type-parameterized traits, and a Turing-complete type system.)
Swift can downcast, and it has generic extensions and generic protocols. I highly suspect it has a Turing-complete type system as well.
Supporting this requires heroic effort in the compiler, but it can be done.
> I suppose that Go programs exhibit more complex behavior at runtime due to the GC and green threads and stuff
Given the GP's note about the connection between written and compiled code and how a GC affects that, I think this is exactly what is being referred to. I.e. a GC makes everything much simpler up until it doesn't, and then it makes it much more complicated. That point may never be reached in many programs, but it may be hard in some cases to tell whether it's something you have to worry about at all.
How is Rust simpler? In terms of cognitive complexity on the part of the user, Modula-3 is much simpler; it is easier for a programmer to learn to write new Modula-3 code and correctly read Modula-3 code than it is for Rust code.
In terms of implementation complexity, Modula-3 is also much simpler, despite the existence of a GC. A Modula-3 spec would be a great deal smaller than an equivalently detailed Rust spec. Many people have independently implemented Modula-3, whereas an independent implementation of Rust is effectively impossible, due to all of the unspecified implementation-defined behaviors. If you told me I had 1 year to implement either language from scratch, I would much rather choose Modula-3.
What are these implementations? The one I immediately found by searching (https://github.com/thepowersgang/mrustc) is accompanied by an explicit nongoal to correctly implement the language. It also doesn't seem particularly independent from rustc, given the similarities in implementation strategy and the fact that some parts look like rustc code converted to C++.
Mrustc is one; my understanding is that it isn't yet, because its purpose in life is to make bootstrapping/ddc stuff easier. Once that works, I thought it intended to add the stuff that's missing.
I suggest you email the team that did the C formal semantics about doing one for Rust. They did it in K Framework (Maude-based) with a front end, KCC, designed to be usable like GCC. Their other work includes functional and logic languages. A team that did an executable semantics for all of those seems ideal for a formalized compiler for Rust given it's like several styles combined. Their rewriting based tools could probably handle at least a subset. Then you get DDC for free plus a way to equivalence check reference compiler for certain features.
I'm talking about the mean distance in expectations between a program and the compiled output. I don't think Modula-3 is much more complicated or even moderately more complicated. I think it's all pedantry of personal definitions at this point. What makes a language "simple" or even "the most simple" aren't even questions that are possible to answer objectively.
"I'm talking about the mean distance in expectations between a program and the compiled output."
Then you should be talking about Rust, C++, Java and other complex languages if that's your concern. Wirth-style languages use simple constructs that map straightforward to assembly. He actually designs the language in conjunction with the compiler so the simplicity is maintained. If it's hard to compile, he just takes it out of the language. Modula-3 adds select complexity to a Wirth-style language to give it exceptions, multithreading, and a standard library. Most of them are similarly straight-forward in implementation. It's why it compiles lightening-fast.
Modula-3, like many Wirth-inspired languages, can be described in a few pages with developers understanding those pages. You can be writing useful code in a day, using most of its features in a week, and probably master it in months to a year. The GC doesn't make it any less simple as that's one component that lets you ignore the complexity of memory management. The component itself can also be simple.
Rust being simpler than other programming languages you cite actually means those languages are enormously complex. That is, given how much more complex Rust was to Wirth-style languages, Smalltalk, Scheme, and so on. It has extra stuff. Hence, the extra complexity. The compiler is also harder to write to make all that work.
Given the work being done in .NET Native and the planned features for C# 7.2, the language is starting to look like the spiritual descendent from Modula-3.
Oh yeah, I forgot to ask "Have you or the others considered rewriting your compiler in Modula-3? I hear you get safety, acceptable speed, and 5x iteration speed of Rust."
Looking at Modula-3 wikipedia page, no thanks. (If it's case-sensitive, I don't want to switch to uppercase everytime I use the language keywords. If it's not case-sensitive, don't even get me started.) I had enough of that for a lifetime through FORTRAN, COBOL, SQL, BASIC, ASSEMBLY, etc.
Do you have anything to say about it's feature set instead of just syntactic preference? As in, it's tradeoff in balancing complexity by what set of features?
Looking at it very briefly, its feature set is probably small enough to keep the language simple yet useful.
To be clear, I'm not a Rust guy, or even C++, Go, D.
On top of that, I'm a 2PL advocate (two programming languages). I think a combination of a readable high-level language like Python or Scheme, and a fast systems language like C, can carry out feats that no single programming language can as far as I know. (I don't consider keeping two or three programming language in your head while doing productive work a big deal, especially when learning multiple language is considered a beneficial thing).
If I remember correctly, the only reason why Modula-3 is memory-safe is because it requires a GC. That right there is a no-go for a "C++ killer" system language.
Most C++ apps can be written in a GC'd language. It has UNSAFE/SYSTEM for when you want to take chances managing your own memory. A language like Ada or Rust would be better at unsafe stuff.
Yes, a lot of C++ code out there can be rewritten with GC. But for a language to replace C++, it has to cover the full spectrum, and that includes GC-less operation for low-level components. Providing primitives to manually allocate memory on unmanaged heap is not sufficient - the language must allow running without GC at all.
It does. It just isn't safe. The extra primitives for safer handling of pointers are main advantage of C++, D, Rust, etc. A worthwhile re-incarnagion of Modula-3 should have something similar.
So the standard library doesn't rely on GC semantics anywhere?
As I recall, that's the main problem with D: the standard library basically requires GC. Your code might not require it, but the library is always there. On top of that, it's just too easy to accidentally involve GC by using reference types.
Actually, I dont know. Good question. I tried to quickly get the info but all I found was about I/O. It's done UNSAFE to use platform-specific ways of reducing overhead. Probably no GC semantics there. Anyone curious who can get some Modula-3 source for stdlib might just look to see if UNSAFE is at the top of the routines. Also, if that turns off the GC, Id reason that just putting it in front of a stdlib function that was GC'd might make it work without it unless they screwed up memory management in the code itself.
I've only dabbled briefly in it and read various articles about the new features, but that hasn't been my very limited experience. The syntax and namespace constructs etc all look quite arcane to me, and then there's the borrow checker. Not sure I'd call it simple and intuitive (at least yet, for me).
Having written quite a bit of Rust, I agree with you that Rust is far from simple and not always as intuitive as say...Python or Ruby for example.
However, I do appreciate the syntax which IMO is in that sweet spot between conciseness and expressiveness. Finally, the borrow checker is quite the experience. Whenever I banged my head trying to get some snippet to pass BCK, there was always an OH moment where I realized something was terribly wrong with my design.
PS: Yes, there's still a few weird BCK false-positives. Hopefully we'll soon have non-lexical lifetimes[1] that should fix most issues.
I shouldn't joke like that - learning Rust was a 4-6 month long low point my my lifelong professional self-esteem. I think I'm coming out of it now, and am only continuing to use it Because Stockholm Syndrome.
"No technology can ever be too arcane or complicated for the black t-shirt crowd." - Linus Torvalds
I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which is considerable), but also just how well they package the information up into a form that the rest of us who are not involved day to day can digest, like has been done here.
Another example is the "This Week in Rust" newsletter which takes progress that would've taken you hours to read about yourself, and puts it into a succinct format that you can get through in minutes [1].
The Rust 2017 roadmap which targeted forward movement on all the language's weakest features was admirable in itself, but even moreso is how much progress has already been made. In particular, I'm really excited about incremental compilation, which is showing as much as 5x speedups in early results [2].
I was also very happy to hear that the Rust team acknowledges that regardless of how performant they are, futures are not a particularly ergonomic or maintainable way to write code, and are considering what new constructs might look like over the longer term:
> Over the rest of this year, we expect all of the above libraries to significantly mature; for a middleware ecosystem to sprout up; for the selection of supported protocols and services to grow; and, quite possibly, to tie all this all together with an async/await notation that works natively with Rust’s futures.
I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension, or as high level as a DB-backed HTTP application. It seems to have an almost perfect compromise between performance, safety, productivity, and ecosystem.
Rust is like a fresh breath of air, and the community around the language is a great example how an OpenSource project can work without being hostile to newcomers. Kudos to the Rust team!
I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension or as high level as a DB-backed HTTP application.
Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc.
> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc.
Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost.
I saw someone use the analogy of a credit card on here before: purchases are very easy to make, but have to be repaid in full, and without perfect discipline you'll be paying interest on top. Now consider most development teams (who are generally strapped for resources) like middle-class earners who don't make quite enough to pay back that balance every month. It starts to accumulate, and the owed interest compounds.
Compilers can do a lot to ensure high productivity and a good user experience: (1) be fast, (2) have great error messages, and (3) be easy to use (no makefiles or heavy build systems). Rust's compiler has learnt from the mistakes of its predecessors in other languages, and does all these for you.
Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost.
If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win.
It's also a win for people who come home from work and want to get features done on their side projects rather than write perfect code.
It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts.
If your language doesn't have a REPL, your language is less productive. Deal with it.
That said, the engineering tradeoffs are often a win. I love Rust; borrow checking is frankly incredible. But it's important to keep perspective.
If your language doesn't have a REPL, your language is less productive. Deal with it.
Oh hardly.
As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least. I've honestly never understood the obsession with it.
Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn out a UT to prove my code does what I think it does is incredibly important.
But a REPL is a nice-to-have. Nothing more. Treating its absence as some fundamental black mark on a language is completely absurd.
I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle.
In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one.
Think about it like this: On your list of languages, which of them would you say is most productive? It depends on the context, certainly: libraries, familiarity, etc. But let's assume the languages had identical ecosystems, and that you were competent in all of them. Which of them would take the smallest amount of time to write your feature?
That'd probably be Python, Haskell, or even Perl. It seems very difficult to argue that Rust would top them. And the reasons why this is might be true are worth examining.
Here's another aspect. Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? How about 20? 2?
It becomes very difficult to argue that your programming language is the lingua franca of the future. (And that's probably true for every language, not just Rust.)
Think about it like this: On your list of languages, which of them would you say is most productive?
Define productive.
Are you measuring raw lines of code generated?
Or are we measuring amount of production-ready code?
My bet: with an experienced, diligent developer it's a wash. My gut says what you lose in a slow code-execute cycle of static, compiled languages you gain in lower defect rates from compile-time checks. Conversely, what you gain in a dynamic language, you lose in errors caught at run-time.
At that point I'd select for languages that are simpler with fewer surprising semantics (crossing Perl and Javascript off the list), with more built-in run-time and/or compiler safety (knocking things like C off the list). I generally also prefer compile-time safety over run-time safety, as I'd rather find problems on my workstation than in the field because I missed testing a codepath.
> with fewer surprising semantics (crossing Perl and Javascript off the list)
Actually, I think Perl has fairly few surprising semantics after you learn the major ones. The real problem is that the major one (or specifically the major one, context) is somewhat hidden in normal C-like usage until it jumps out at you and confuses you. Once you understand what it is, it's not all that surprising (but there are a few annoyances with it that still persist and cause problems). You can write Perl that looks almost exactly like C 95% of the time, but that 5% where it matters makes people that do this very confused. There are, of course, other parts of the language that are poorly chosen, but I maintain there are actually far less of them than many people seem to think.
As for JavaScript, I still can't get over all the different ways to check for equality and null or undefined. I understand a good portion of that is because I never have to use JS enough to become truly proficient, and some if it is just poor design.
> Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else?
Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." They were speaking from their own experience, based on their own balancing of the trade offs as a user. Presumably a REPL doesn't rate very highly for them.
However, the reasons we don't have a REPL are mainly two: the compiler isn't architected for it and code doesn't compile fast. The solutions are:
* Re-architect the compiler to support incremental code input. This is pretty similar to what we need to support IDEs (which we're working on), so possibly this will solve the problem.
* Get a reimplementation of the backend which is a JIT interpreter instead of LLVM, which takes up most of our compiletime. Work is underway on a project called miri, though it isn't officially supported right now.
* Make the typechecking part of the compiler faster. This is underway through a project called chalk.
In other words, a REPL is not impossible, it just isn't a top priority right now. There are other lacking tools that we're working on - IDE integration and auto-formatting for example - maybe after those are done it will be the top of the docket.
Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community."
Respectfully, the community has become increasingly vocal, and it's getting hard to separate the enthusiasm from realism. It's embedded in every HN thread. That's a good problem to have, but it can be a bit repellant to people who aren't Rust converts.
Thanks for the breakdown and future roadmap. I hope the compile times can be kept to a minimum in order to avoid C++'s fate.
The community is in every thread because the people here were HN users before they were Rust users. Look at how old my account is; I haven't quite been shilling Rust since December 2011. :P
I'm no compiler writer, but presumably rust has some form of internal IR it compiles to before it gets turned into LLVM IR. Why not just write an interpreter for that layer and be done with it? The point of a REPL to me is to be responsive, not to run code amazingly quickly.
> It's not about the REPL itself but the capability of implementing one.
That definition excludes any bare-metal language, and use cases where you want to take advantage of cheap low-level memory protection features such as No-Execute bits. For me, a more interesting benchmark would be how well Rust fares in implementing the runtime of a higher-level language.
Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"?
Some projects are written as explorational prototypes or MVPs. I don't think anyone is saying Rust is much good for those.
But (numerous) other projects are written as "the first real Quality implementation of [well-known problem], using a decade's experience with other implementations." Much of the common software we use—{server daemons (HTTP, SSH, DNS...), parsers and encoding libraries (for XML or JSON; JPEG or PNG; MP4 or MKV...), databases, load-balancers, distributed queues, ...}—fits this paradigm.
If you're writing Nginx, or Redis, or djbdns, you aren't "adding features" out of some agile user-story kanban; you're carefully implementing a small, curated set of well-known, well-understood features, with much research done to ensure that you arrive at the best and least fraught implementation, the one that will make people prefer your software for its quality and reliability and set-and-forget nature.
Rust is for that kind of software. (Which makes sense, given that Mozilla's Servo rendering engine also has the goal of being that kind of software.)
"Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"?"
In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle. So, it doesn't really matter to them so much as quickly getting out working features. In other cases, esp long-lasting endeavors, then this is a good point to consider.
> In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle.
Or grow so quickly that replacing most the legacy code from a year or two ago is not a significant hurdle at their new size.
In this vein, I wonder if there's actually a third path that might be better than both. Using a low-level but fairly expressive and strongly typed language but very loosely, such that it allows you to iterate fact but with less performance, and you can come back later and replace chunks as needed, but with the same language. I don't have any real experience with that, and I could see it going either way for a number of reasons, but it seems like we have more languages that might fit that criteria now (or at least they are more popular now) than we have previously.
> (Which makes sense, given that Mozilla's Servo rendering engine also has the goal of being that kind of software.)
Web browsers are not that kind of software. The web is evolving much faster than any of the other things you mentioned. New features get proposed every year, and you just have to deal with it and implement them, even if they complicate the implementation of the browser. Even if you cut that off, you still have to deal with the horrific mess that is the cumulative total of past web-related decisions.
A rendering engine is not, itself, a web browser. (You might be thinking of a higher-level component, like Chromium's Embedded Framework? Not the same thing as a rendering engine.)
There's certainly a layer of a rendering engine—the part that translates a CSSOM into rendering pragmas—that changes a lot over time. But rendering the resulting pragmas itself doesn't change much, and features requiring new pragmas come about remarkably slowly.
I definitely know the difference between a browser and a browser engine; I worked on both WebKit and Servo. There's much more to a browser engine than rendering alone, and rendering isn't even the most complicated part of a browser engine. Outside of rendering and JS there's a steady stream of new DOM APIs, and that's the part that is similar to the "agile user-story kanban".
Yes? It sounds like you're agreeing with me, and disagreeing with your own GP comment. Or maybe I misunderstood the point of your GP comment—it sounded like you were trying to use some sort of metonymy to equate Firefox/browsers in general with Servo, as an implicit counterargument to my GGP post in the sense of "it'd be bad to write a browser in Rust for [reasons you gave]; a rendering engine is part of a browser; a rendering engine thus has the same lifecycle as the browser itself; and thus, a rendering engine is not actually a good example of a good use-case for Rust, despite Mozilla's ambitions. QED."
Clearly, though, you know what a rendering engine is, so I'm not sure what your argument in the GP post was. Was it just a tangential statement (i.e. "rendering engines are well and good, but it'd be silly to write the browser itself in Rust, for [reasons]"), rather than a rebuttal...?
BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to).
I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an existing codebase, but I can't envision a workflow where a REPL provides significant productivity gains for an experienced, professional software developer that aren't realized in other ways (e.g. writing unit tests).
I could probably have countered it, too, in the same language during the challenge back when I used it. I found the incremental, per-function compilation feature reduced compilation time of most changes to a fraction of a second. Most of time in programming is spent thinking, tweaking, debugging, dealing with 3rd-party libs, etc. I don't think a difference in the source-to-execution part of under 1 second is going to make a big deal.
It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.
That's not even the beginnings of a useful reply. :)
Give me a highlight of your normal day-to-day with the language. What, exactly, does the REPL offer you that provides significant productivity gains that can't be had any other way?
Because clearly I've missed it.
And it should be pretty easy for you to describe if it's that common and/or obvious.
At one point I wrote Clojure for my day job. I think having a REPL is actually more useful for untyped languages, especially Clojure, where most data "types" are maps/lists. By exploring in the REPL, you can get a good feel for what kinds of data a function works with.
In a statically typed language, a REPL can still be useful, but the gains from it are less than you'd get with an untyped language. It's easy to see what kinds of data a function works with by just looking at the types. There are exceptions of course, like when the type is very complicated, it can be helpful to see some examples of actual values of the type. And I suppose that's why languages like Haskell and OCaml have REPLs.
You're demanding the impossible here and elsewhere in the thread. Asking for the impossible is maybe ok, demanding it not so much.
No one can demonstrate productivity gains because productivity can't be measured. Lines of code can, and those are often a bad thing. Some of our most productive efforts make programs smaller.
No one can demonstrate productivity gains because productivity can't be measured.
So then the OP shouldn't have made the claim. It ain't my job to prove it. :)
That said, I fundamentally disagree with the idea that one can't measure developer productivity. I agree that there are many potential measures, all of which have the potential to be flawed or distorted. But the idea that the productivity of a developer can't be measured at all is something I've never heard anyone seriously claim.
Come now, it was you who moved those goalposts and you moved them half a field or more. OP claimed REPLs "have benefits". Your response was (paraphrased) "demonstrable measurement of productivity improvement or GTFO". That sort of ante-upping just isn't that nice for good conversation, and certainly not when you're demanding a standard none of us can meet about anything.
Not sure I buy that. I think you need to go further up the thread chain to see the OP on this[1], which, to be fair to your interpretation, wasn't written by dwaltrip:
> If your language doesn't have a REPL, your language is less productive. Deal with it.
That seems exactly like the kind of claim that everyone should view with a healthy dose of skepticism, and I think zzalpha's initial response[2] hit that right on the nose.
Eh, here Fowler just falls into to the trap of the Perfect Solution fallacy.
I repeat: there are no perfect measures of productivity. But there are imperfect measures that have some utility. The idea that we cannot measure at all because we cannot measure perfectly is simply untrue.
In this case we could, for example, take 1000 individuals with similar years of programming experience and given them two languages and a non-trivial problem to solve and see how long they take to come to a working and correct solution.
Is that perfect? No. But it's still something that's measurable. Do that with a reasonably large sample and you can probably start making inferences.
Our industry suffers from a horrible lack of concrete, scientific studies to back common wisdom. We would all benefit from ignoring Fowler, here, and getting down to the nuts and bolts of finding solutions to that problem. Until we do, while we'll have lots of fun having pointless debates on HN that cannot be resolved because we have no real data, the industry simply won't move forward.
One example: REPLs can occasionally be a great way to implement helper methods or other well isolated functionality. I understand you might argue unit tests are better for this, but I would very strongly disagree they are better in every situation.
Unit tests provide some additional benefits, but are a heavier approach with a slower, clunkier feedback loop. There are times when those additional benefits are not worth the added cost. Unit tests are also additional code that must be maintained.
The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable.
I guess it's one of those things that's imho hard to appreciate if you never experienced it.
The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is more than nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable.
That's called a remote debugger, and it's hardly unique to languages supporting a REPL.
The usefulness of a REPL depends a lot on the language/interpreter/vm. In Erlang and Elixir the REPL is imo more than a nice to have. Being able to connect to a production node and peeking around what is happening can be very valuable.
I guess it's one of those things that's imho hard to appreciate if you never experienced it.
> I've honestly never understood the obsession with it.
The true key to understanding REPLs is their role in consuming third-party libraries. While languages both with and without REPLs will have well-used packages in their package ecosystems that are well-documented; languages with REPLs will also manage to have well-used, poorly-documented packages: packages whose "documentation" consists only of the de-facto ability to reflect on the API in a REPL, doing the moral equivalent of exploring a filesystem using cd(1) and cat(1), until you figure out what functions—and what arguments—combine to produce an acceptable result for your use-case.
That may sound like a bad thing, but it's not! Those packages are packages that wouldn't exist otherwise; they're marginal packages, packages which people wouldn't have had time to write if they were required to also document them properly enough to make use of them without a REPL. They're needs being satisfied, that would otherwise—given the stricter requirement of useful API documentation—be going un-met.
If you look at e.g. Ruby's gem ecosystem, there are tons of packages that have more than a million downloads, and either no docs or awful docs. How? Because Ruby is extremely amenable to exploring APIs through a REPL. You take a module or class, ask it what its children are, what its class methods are, what its instance methods are. Find a class with instance methods that sound right, attempt to instantiate it. Figure out you can't do that, look around the class methods for something that sounds like a factory method. What arguments does said factory-function take? Well, feed it some at random and see what error you get. Etc.
True, though "good IDE support" in the sense you're talking about (i.e. being able to discover an API through the IDE) mostly relies on strong typing in the language. (Non-inferred) type declarations are their own form of documentation, with a similar effect on likelihood of a "marginal" ecosystem package getting written.
For (most) languages lacking a REPL, it's very similar. Instead of a REPL you write compiled unit tests and/or test programs to poke around at the API.
For languages with a reasonably sophisticated IDE, use the IDE itself to jump straight to the class/function declarations to understand the surface area of the API, and jump to the decompiled code for the implementation of those functions if you're the type to want to understand the machinery.
Other languages (like Haskell) may not have the IDE support but attempt to solve the problem with auto-generated docs so you can at least see the surface area of the API and can start prodding it.
> What's your experience level with other languages?
~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days.
Admittedly, I've never used an IDE; I write all my C in vim.
> ...you write compiled unit tests and/or test programs to poke around at the API.
That assumes you can get your tests to compile; or that the compilation errors are at-all helpful when they don't. If you've got a library that
1. ships as a binary blob + header files, and
2. most of its functions take handles to structs that are declared opaquely in the SDK headers; and yet
3. nothing you do with the badly-documented "create handle" parts of the API is giving you a struct that the "consume handle" parts of API will do anything with but crash...
...then you'll really wish that you had a REPL; or rather, a language runtime that enforced some level of introspect-ability on everything, so that a REPL could show you what's in the struct and whether your calls so far have failed to touch some obviously-necessary-to-fill-in part of it.
Without such support, you will have to rely on reading the decompilation results of both ends of the API to figure out what's really going on.
Yes. I write roughly equal amounts of C (microcontroller firmware) and Python (overall system control, running on embedded Linux).
I absolutely wish I had a REPL for C. When implementing with a new library in Python, I'll usually use iPython to explore it, and if I need to run a decent amount of data through, I'll use a Jupyter notebook. I'd put the difficulty of grokking a C library somewhere between 10x and 100x harder.
I use gdb as a C REPL. You attach it to a binary that has the functions you need, then you can use them with the `p` (or `print`) command. Loops and new function definitions are not possible, but sometimes it's still good enough.
That is how I once developed a B+ Tree library for low level disk blocks back in 1996, it was quite helpful tracking down how the nodes were being used.
Thanks. It won't since all my C work is embedded and mainly systems programming rather than algorithms. But I'll keep it in mind for the next time I have to translate my Python explorations over to C for production.
or rather, a language runtime that enforced some level of introspect-ability on everything
And now we get to the real meat of it.
It's not a REPL you want.
It's reflection.
It just so happens that the latter is frequently paired with the former.
And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compiler, debugger, and IDE can do a much better job.
Reflection isn't orthogonal to a REPL; it's synergistic with a REPL. When you have a static language, yes, REPLs don't add much; reflection by itself is all you need and an IDE will suit you fine.
But when you are working in a language with runtime code generation—one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an IDE cannot†.
A REPL in a dynamic language (that takes advantage of its dynamicity) can be used to "explore" down CORBA/DBUS object trees; or fluently walk REST or SOAP endpoints without needing pre-baked WSDL descriptors to guide you to them. Heck, an Erlang REPL can hot-upgrade remote nodes. :)
† Or, at least, not a traditional IDE. You would need an IDE connected to a "live session" of your project—essentially a hybrid IDE-REPL. (Examples: Light Table; Emacs' CIDER extension for Clojure.)
Note that with strong typing this is less of an issue -- with Rust you can just go to http://docs.rs/<nameofcrate> and navigate the structured docs. They may lack explanatory text, but you can click around them and search and it's overall much nicer than fiddling around in a REPL.
(Still, doesn't fit all use cases of a REPL for this. REPLs are especially nice for when you want to fit together highly generic APIs)
True; but also, "strong typing" on its own isn't a panacea for guidance; unless you're writing Coq or Agda, the API functions you're calling are still going to have preconditions that are not encoded in the type signature, so you're still (partially) reliant on having either good docs or a REPL [or clumsy REPL-equivalent, like exploratory unit tests] to inform you of those preconditions.
And if you are writing Coq or Agda—well, you certainly don't need a REPL at that point. The code writes itself. ;)
As a Python dev with 12 years of experience, I still use the REPL every day.
When I wonder how something works or if I need my memory to be refreshed, I just fire up jupyter console and test quickly the code. I don't open the doc or search on the net. I have the live result immediatly.
When I want to debug my web server, I drop a REPL in the server and play with the code. It's more efficient that just debugging, because I can actually modify the code live and see what happens.
When I need to understand a format and how to manipulate / tranform data, I use the REPL (or jupyter notebook) because it's the most natural way to do it.
I don't know how much Python you have done, but you have been missing one of the greatest tool of the ecosystem.
It's like saying you don't see that much the benefits of an IDE for refactoring in Java. "yeah it's cool but how much do you use it hu ?".
> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts.
So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto all of them, and (2) this is very much my personal opinion.
---
I'd still defend the position though. Every language has merits, but especially for a lot of the older ones, there are so many accumulated problems that it's worth considering newer languages just because they're learned so much for the mistakes of their predecessors. For example, I've been doing Ruby for quite a few years now:
* Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability. It buys you a little early productivity, but any honest person with a huge Ruby codebase can tell you that it's a liability.
* The only way to get truly good performance is to write a C extension. The language's whole implementation and performance-sensitive libraries are all C. Contrast this to modern languages where it's an embarrassment if your compiler is _not_ written in the language itself (Rust, Go, Swift, etc.).
* Core build infrastructure (Bundler) and environment management (rbenv) is maintained separately from the language. It works fine, but the reason it's not more core is not because it's better that way, but because the language's original designers didn't realize they'd be necessary, so they had to be developed separately. This has the effect of making the whole toolchain complex and hard for beginners to understand because none of it is integrated.
* The interpreter starts out faster than a compiler, but it breaks down fast. Codebases in the 100,000s of lines or more will take on the order of 10-100 seconds to start up, and the only way to get back to a fast edit-compile-debug loop is through tricks like Zeus. After you resort to that, unreliable runs and weird loading problems become a part of common life.
These aren't small problems. Also, I'm picking on Ruby here, but you could drill into a lot of existing languages and find flaws that are roughly on this level (JS/Python/C++/Erlang are easy, but even fan favorites like Haskell and Scala have pretty serious ones). Newer languages have their problems too, but rarely anything on this sort of existential scale.
We should stop pretending that all languages are equal with their own share of upsides and downsides. Given decades of language building, it would be disappointing if lessons hadn't been learned. Luckily this isn't the case.
In terms of what we write new projects in given a few years, there are other good contenders, but like I said above, I think that Rust has nailed a performance/safety/productivity/ecosystem compromise that's quite a bit above and beyond most of anything else.
But do you think the Go community agrees with this, just to name one of the popular newer languages? It's nice that Rust is doing well, and more power to the community. But there is an entire world of programming language communities out there that might not agree with the assessment that Rust is the future for them.
Anyway, I was around for this kind of talk when Java was new and shiny, and there were people in the Java community claiming that Java was the future for programming, and any languages in the future would target the JVM or be phased out. That didn't happen, even though Java did well for itself.
What's really telling is that Java didn't replace C/C++, despite all the hype back then. Those two languages remain widely used.
Depending on who you ask Java did replace everything. Consider the Tiobe Index [1]. Java Beats out everything, including C and C+++ when added together. All three are growing, but not nearly as fast as everything else is growing to the point it looks likes they are shrinking.
There is an absolutely enormous amount of Java out there.
If you mean Java replaced C/C++ as the most widely used language, at least according to one index, then that's one thing. So if someday Rust became as popular, great for Rust. But that's not the same thing as claiming that Rust will be the One True Programming language in use that will cause all the other language communities to die out and convert to Rust.
That's what is being claimed above, and what some in the Java community were claiming in the 90s. Also, probably some in the Javascript community these days.
But it's never happened. If there was the One True Language to rule them all, then Lisp, C++ or Haskell would have done it by now.
The point with Java is that even though it was targeting the C/C++ crowd specifically, and it became widely popular, did not cause C/C++ to die.
I wasn't claiming it and I even qualified my statement. I am not sure what more I could to make it clear that no languages have actually been replaced, while retaining a nuanced message that many people see replacements depending on their perspective. Then I even cited source to back it up with some some numbers.
If you want to argue with some several post up, please go several posts up. If you want to argue against me, than please do so on the merits of what I said.
Java and its counterpart .NET did indeed replace C and C++ in 80% of enterprise applications.
The remaining 20% are stuff like device drivers or high performance libraries that are easier to write in C or C++, or legacy MFC applications.
Also if you look at operating systems like Android, Google makes it very explicit that you need a very good reason to down into the NDK dungeons, to the point that the set of allowed libraries only cover the use cases of 3D graphics and bringing native libraries into Android.
Likewise when Android Things was still called Brillo, the plan was to re-write the Android Framework in C++, instead they ended up bringing ART into Brillo.
Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability.
Citation needed. Just because static typing is has been more fashionable for the past 10 years, doesn't mean it's a closed case. Before that people were extolling the virtues of dynamic languages.
Some people deciding they prefer static typing doesn't constitute some kind of consensus or fact.
Yes, I can't prove it. There's no quantitative way of doing so.
I've worked with very big duck typed codebases for quite a few years now (and largely statically typed in C# before that) and the above is my opinion. Duck typing is convenient early on, but it makes understanding code (especially where it gets complicated or you didn't write it) quite difficult, and any kind of refactoring downright scary. After a point you (1) start getting hugely defensive with tests because without close to 100% coverage you just can't know if anything works, and (2) stop making big changes and instead accept that small incremental deployments towards a greater end is the only safe way towards making progress.
I suspect that how much you agree with this statement is strongly correlated to the size of your codebase. I'd be surprised to meet people with codebases on the order of 100k lines or greater that don't largely share this sentiment.
I don't understand how (1) isn't a positive in your eyes. (2) is true for pretty much every large statically typed codebase I've worked on.
I'll admit, my commercial experience has all been in statically typed languages. But there are a lot of complex, well written pieces of software written using dynamic types. Maybe you don't meet their proponents, but they do exist.
FWIW, I quite like static typing, but I consider it a feature, not a religion.
Patrick Logan on Lobste.rs comes to mind. He talks a lot about using Smalltalk for robust applications. Here's one paper he shared where Smalltalk team killed the others in productivity. Unfortunately, I didn't get defect rates on all the teams where Ada or C++ were usually winning in those kinds of comparisons.
He said they mostly just test everything at the interfaces. However, it's simplicity also allowed for powerful tools in code generation, refactoring especially, and so on.
> I don't understand how (1) isn't a positive in your eyes.
I like testing as much as the next person and consider it very important, but your tests should be testing business logic rather than whether your syntax is correct. The problem with dynamic languages is that while you're certainly doing the former, you're also doing way too much of the latter. Until you hit runtime, you have no idea whether you misreferenced a variable or invoked a method that doesn't exist, so you end up writing an exaggerated number of tests that are repetitive, slow things down, and end up requiring considerable maintenance.
> (2) is true for pretty much every large statically typed codebase I've worked on.
Yes, incremental deployment is always a good idea, but it's a matter of degree.
Take for example a case where I need to rename a method that's widespread throughout the codebase. In a static language, I wouldn't give this a second thought. If there's a problem my compiler will catch it, and that's the end of the story.
In a dynamic one, this is a dangerous operation: the old method name may still be getting invoked dynamically in a non-obvious way, or another branch may have been merged _after_ I branched but _before_ I deployed that still has an invocation of the old name. Hopefully you have tests on these paths that will reveal the problem, but you might not, and to hedge against that possibility, you have to roll the change out to production carefully and slowly (because even there, it might be some time before some unwitting user inadvertently triggers the bad flow).
"If your language doesn't have a REPL, your language is less productive."
I think what you really want here is fast compiles and iterations. You can do that without a REPL if using a language that compiles ultra-fast. Industrial BASIC's I used a long time ago compiled in a split second with me seeing the results immediately. Wirth-style languages tend to be able to do that. I hear Go compiles really fast. The wait doesn't really matter at that speed. Highly-optimized, slower compiles and tests can run overnight in background on dedicated machine, too.
> If your language doesn't have a REPL, your language is less productive
Am I the only one who sees this as pure BS? Some people like REPL's, and that's cool. But not everyone. I find it utterly annoying that in any REPL I've ever used I first have to import (or similar) the libraries I want access to in that repl environment. You end up generally writing a file to do the imports for you, or cutting and pasting.
With all that effort I almost always find it easier to just write a test-case, even in languages with a REPL. At that point I have a repeatable and testable piece of code that can be run, with almost zero error due to the REPL environment not being setup properly.
> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts.
Please point to a single place where anyone has ever said this. We have never positioned Rust as an end-all be-all language: it's a language that deliberately makes compromises in order to excel at a niche.
Rust's compiler is not fast. At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. This might change once rustc eventually gets proper incremental compilation (not the codegen-only thing that's currently in beta). Hopefully. Rust doesn't use header files, so in theory it should be possible to leapfrog C++ (at least until C++ gets modules standardized), but for now that's just theory.
Right now, I don't do much serious work in Rust, almost solely because of compilation speed.
Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast.
If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).
I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem.
Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman?
I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.
> such as making cached precompiled libraries very easy to use.
This is already true today; that is, this cost is only paid the first time you compile. It's still not fast enough for people.
On my machine, a fresh build of rustc takes an hour, and small changes take 20 minutes, and even that makes it a giant pain. It's an ergonomic thing, IMO.
I should have been more clear; I mean a solution for many devs to pull precompiled caches, and share those for the same version of libraries... this would also benefit CI, as all CI runs to be based off this.
Turbo Pascal was more a kind of simplified Ada than a pure Pascal, which made me look down on C when checking down the laundry list of language features of Turbo Pascal 6.0 versus ANSI C89 in 1993.
Also by 1999 no one was doing anything serious in Turbo Pascal with the last version being targeted at Windows 3.1.
Delphi 1.0 was released for Windows 95, and it did at least have some kind of GC for COM based classes.
Also Delphi 10 might not have every Rust feature, but it surely has it own set of complex language features.
Or if you prefer Ada, C#, D are also possible sources of information regarding performance of compilation toolchains, with relatively complex languages.
Is it as fast as javac?
Maybe on a line of code basis, but I imagine java is much simpler to to implement incremental compilation with.
Since sources map pretty much 1 to 1 with classes, you mostly only need to recompile the class that changed.
Unfortunately, it's not quite that easy since java inlines constants, plus you have to account for package protected, inherited methods, etc. that you don't have to implicitly import. But really, it's the constants that make incremental compilation slower...
Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini.
I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times it's worse.
To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.
Maven takes a long long time to start up, but once it's ready, javac is pretty quick.
Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air).
I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath<T> and AsRef<T>, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)
So better try again with straight javac, Ant and Maven.
Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse?
The Android Gradle plugin being slow as molasses is a typical discussion theme at Google IO since it was introduced. Being partially written in Groovy also doesn't help.
`cargo check` is pretty darn fast, and that's pretty much all you need while developing. I'd say it's generally 50% faster than a standard compile (not benchmarking, just a gut feeling).
On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time during development or after updating dependencies.
For me, the compile times are fine, and the end product generally doesn't need as much debugging as an interpreted language that requires no compilation at all, or has minimal validation, prior to running.
But that's how languages do it. CPAN was my first experience with it. At development time, I need weird libraries.i hope they're ready by release time. Package managers are awesome, but sometimes, fuck them.
Higher level languages get away with it because they are platforms in their own right, rust is meant to be a systems level language. I expect a systems level language to work with the system, not against it.
Of course I don't, but I don't think it's an important aspect in any case.
I think the user experience is more important than the developer experience. Using shared libraries that are likely already in memory provides a better user experience because it's faster, more stable, more secure and uses less memory.
The cargo approach will end up with windows/node level bloat where every app bundles half an OS.
I think I understand your opinion, but I'm asserting development time is wierd. Sometimes I need the bleeding edge. Sometimes I'm debugging the bleeding edge. If you're willing to stuff nightlys in artifactory, I'm willing to roll with the package manager. Realistically People aren't willing to own that process, so I grab a sane ish version, and go on with my life.
True, but there's not a simple, unified way to maintain packages across all major platforms that does not involve having your own package manager like Cargo.
Well, there is benefit to the platform, I think you've just misinterpreted it's use.
Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. All those other languages also have packages provided in many distros, but the developtment tool listed that downloads and installs relevant packages is also used when appropriate. For the regular, non-developer user that needs a module to support some program, that may be never. For the developer working in those languages that needs the newest version of the package, regardless of the back-patching policy of their distro, that may be often.
> Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby.
As I said, rust is meant to be a systems language, it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
It's meant to useful as a systems language, so was designed with certain constraints in mind. It is whatever people want to make of it. There have been plenty of instances I've seen on HN alone of people mentioning use that isn't specifically tailored for a systems language.
> it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
Those are entirely orthogonal issues. Cargo works with the system just as well as tar and make. They're just binaries. You could just as easily say that traditional source tarballs shouldn't be provided because people might download the source and use their compiler to build instead of using the distro package. This is a non-issue. The only people that will even have the choice are those that chose to install the compiler (whether it be a C compiler or Rust), and even then the vast majority that actually do so will probably end up having a good reason for doing so.
Cargo is part of the build tool chain. Just because it can be used to distribute a package, and even while it probably will be used to distribute a package, that doesn't mean it's purpose is to do so, or that it's inappropriate that it exists. Any feature can be abused. You should not judge it by the abuse, but by its intended and common use.
Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager".
Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well.
If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious.
After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well.
I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.
Yeah, I agree with this. This confused me when I first started using the language. I do think there could be some better options for caching or downloading precompiled packages, but I also think this has partly helped with the development effort in Rust as well. That being said, a system wide cached package repo could work, but it also has issues (looking at you Maven) so it would be interesting to figure out how to get it "right" when dealing with source packages.
Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)
Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager.
> If you're pre-building something and pushing a package for say dpkg or rpm
The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities.
> Should an OS want to bless crates, cargo does have an override for crates.io
That's a recipe for dll hell if I've ever heard one.
> The problem is multi copies of the same dependencies everywhere
most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue.
If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you believe it's doing it wrong, but every package manager for every OS out there does things differently, Rust can not fix this.
> That's a recipe for dll hell if I've ever heard one.
The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there, with the cargo manifest used to generate the various package managers dependency graphs as necessary. This would probably look a lot like, or actually be an integration with, FPM.
> but every package manager for every OS out there does things differently, Rust can not fix this.
Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app.
> I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there
Basically, but more to the point, when a bug or security issue is fixed I don't want to rely on individual programs updating their dependencies. Let's say 10 years from now the rust version of gstreamer is widely used and a security issue is discovered, I want to be able to "apt-get upgrade" and know that it's patched. This is how things work now with the c version, but this can't be done with cargo, every app using the library has to update it's dependencies and many (particularly any corporate ones) will never update. Rust might be a boon for security but cargo could undermine the effort.
Aside from that, static linking creates a tonne of bloat, memory and disk. There is a reason windows apps are often so bloated compared to their linux counterparts.
> The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I don't think that's good enough, if rust wants to be a systems language then it has to work with the system, not be a layer on top of it like java/.net/node. It can do this technically, but culturally it's looking more like node and less like c.
While I understand your point, there is a difference between something installed through cargo for use in building software (in the manner rust does, where it's generally statically compiled), and something installed through the package manager for use in running the system.
If I'm installed zlib for general system use, I want a package manager. If I'm installing a Rust compression library to be compiled into the program I'm working on, I want that to be managed by my build chain (especially since the version I'm using in my build may not necessarily match what I have installed on my system to run).
As another example, if someone makes a cook general purpose library using Rust, eventually it should be packaged up and shipped in the normal distro package format by the distro if it's useful. I wouldn't expect cargo to be the normal way to distribute software. It's the Rust equivalent of the old tar -zxvf package-1.2.3.tar.gz && cd package-1.2.3 && ./configure && make && make install. You can do it, but if you have a distro package, use that first.
> Next, I'll introduce you to a tool called Cargo, which will help you write real-world Rust programs.
From the getting started chapter of the rust book (which I believe you wrote?). That implies that rust can't be used without cargo right there. And I'm not seeing any libraries published as ubuntu packages.
After this conversation I thought I should expriment more with rust and it's linking options and quickly ran into an error of some sort (quite possibly a system one) trying to buils hello world with dynamic linking:
> That implies that rust can't be used without cargo right there.
rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year.
Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. It's like the difference between Make and pbuild or a similar tool; see the parent comment about "./configure && make" vs a system package.
> And I'm not seeing any libraries published as ubuntu packages.
Debian has an entire tool, https://crates.io/crates/debcargo, which automatically re-packages a Cargo package into a .deb. Currently, they only package the Rust compiler itself and Cargo, but this work was done specifically so that programs in Rust could be included in the distro, but packaged the way distros like. They've mostly been working on that stuff; I assume by the time Buster's cut-off date happens, there'll be some stuff; I'd like to see ripgrep, personally.
I haven't used -C prefer-dynamic in a while; usually SO questions get answered relatively quickly though.
> Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software.
The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installation section of ripgrep (http://blog.burntsushi.net/ripgrep/#installation) "cargo install ripgrep" is an installation option.
And because static compilation is also a distribution mechanism (just not for the end user) the binaries are 10 times larger than grep, not to mention a giant GPL trap for commercial users.
Please don't misrepresent my writing. `cargo install` is NOT the primary distribution mechanism for ripgrep. The installation section starts with instructions that use standard system package managers, and only then suggests installing it using cargo if you're a Rust programmer. Why did you leave that out?
You might also consider looking at the actual README of the project[1], which lists several more installation options, including using brew, chocolatey, pacman, emerge, dnf, yum and nix. There is clearly an effort to suggest that users install ripgrep using their standard system package manager.
Some of the points you've made in this thread are valid concerns, but please don't misrepresent other peoples' hard work while you're doing it. It's extremely rude.
Sorry, I didn't mean to imply that cargo was the primary distribution method, merely that it was one and that cargo has gone well beyond being a build tool. Rereading the comment I can see how you interpreted it that way. I could have been any app built, ripgrep was just the only one that came to mind.
We have resisted adding features to Cargo that would make it better for end-user distribution, and the RFC for "cargo install" made it explicit that it's a non-goal. It's for distributing stuff for Rust developers, like additional Cargo commands, not for general end-users.
What's the policy of crates then? It's clearly being used here as a way of distributing end-user software. If node is anything to go by then this will only increase.
javac itself doesn't do any incremental compilation and will happily compile over your .class each time (though you can tell it not to; see http://stackoverflow.com/q/8271282)
Build tools like Maven and Gradle, as well as IDEs' internal build tools, will be smart and compile only the changed files.
I was partly relying on the context offered by the article and my parent comment to imply that sure, Rust's compiler isn't the fastest in class, but the team has identified speed as a major outstanding problem and is working very actively to address it.
Compilers are pretty hard. Languages like C and Go are able to short circuit the problem by having a simplistic type system, but the Rust team's main option here is hard work, and so far they seem to be more than willing to engage in it.
> At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse.
Citation needed on that one. How can you even make that kind of comparison fairly?
It's one of those things that's happened to so many people with so many C++ compilers on projects of any significant size that almost everyone says it. Happened to me with several where I moved from a Pascal-like language to find the compile time terribly slow even when I barely used the language. A lot of it is do to how the language's syntax, semantics, and esp templating are designed. Plenty of languages with even more flexibility compile faster than C++ due to better design.
Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust).
For all I know, that might be true, but it's one of those "citation needed" type things.
Maybe I misread as I quickly moved through the thread. It does look ambiguous now. All I'll claim is horrible compile times on C++. I'm not sure where Rust is at now.
It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD.
On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5 minutes.
Lack of incremental compilation and cargo not being able to deal with binaries dependencies has putted me off, after all if I want slow builds I can have them already in C++ when I go template meta-programming craziness, which are not that slow when using the experimental work Microsoft is doing with C++ modules.
Also since our use of C++ is constrained to libraries used from Java/.NET/Android/iOS, the build times are usually relatively fast.
Hard to sell Rust to anyone on the team, if that means their workflow would become slower, in spite of the safety improvements over C++.
If my github api-fu is correct that's what, 40kloc for the rust side of things? Doesn't seem unreasonable times (vs C++) for a full rebuild on that machine - which I'd generally want to do for anything but the most trivial C++ toolchain bump too (in fact, I'm usually forced to) making a comparison against incremental builds very apples-to-oranges IMO. What's your C++ LOC/full rebuild like?
I'm used to ~100kloc of C++ taking half an hour per config+platform on a 4-6 core, 16GB+, SSD machine. Less hygenic than your codebase sounds like, but with some beefy PCHs. Toolchain updates are usually a full day affair in this context, although that's not entirely from just the compiler bump.
Of course, incremental vs full rebuilds are no contest. Rust is at least working on incremental builds now that they have MIR AFAIK. And binary cargo support would be really nice as well. As would be compiling in general.
Cite a source? This isn't my experience at all, Rust is still way faster at compilation than C++ on average. The advantage that C++ currently has is ccache which helps avoid needless rebuilds (which pairs well with C++'s smaller compilation units relative to Rust); building this behavior into the compiler is part of what the incremental compilation initiative is addressing.
> Compile times with Rust are Not Great. This is easily my single biggest gripe about Rust right now. The build for A Snake’s Tale takes 15+ seconds, which makes iterating rather tedious. The current incremental compiler work also doesn’t seem to make the build for A Snake’s Tale’s codebase any faster.
That compile time is Not Great, but 15 seconds for 7700 lines of code isn't even close to "far worse than C++". :P If incremental compilation is showing no benefits whatsoever, then I'm guessing that time is largely attributable to linking (and I tend to doubt that 7700 lines of code is counting the basic third-party libraries that are required to create a crossplatform GUI app (but I'd love to be surprised!), which will contribute to linkage time... LLD please!).
For a full rebuild, that's a reasonable C++ build time for a project of this size. But full rebuilds are not representative, if the project is composed of many independent compilation units. The compilation unit in Rust is the crate, which is an exe or a library, so currently the best strategy is lots of little crates, which is not so ergonomic (heh) with Cargo.
Actually, the compiler isn't the bottleneck - most of the time is LLVM codegen. So 'cargo check' is fast - the miri MIR interpreter likewise.
I fully agree with you, but I still start projects in Ruby.
Why?
Because returns from startups are exponential and the interest rate is higher than the interest rate on the technical debt.
It's why compiled is a great choice for an established corporation with a well defined need and a large user base, while interpreted is better for most other business contexts, especially with tools like Numpy.
Yeah, but I've been doing this stuff for a while now. I used to do it in C and then in Nim (unlike Go until about a year or two ago, Nim could always compile shared objects, so using it through the ruby FFI was pretty straight forward. I've also done some stuff in Cython and just communicated through the database to my Rails app.
I'm still not sure what the best way of doing things is. I tend to think that Rust is going to be the programming language of tomorrows operating system, but I'm not sure if it is going to get the wide library support of something like Cython, since the scientific community isn't as fractured as the software community. Tools like graph-tool / scipy / etc are hard to live without.
The comment I'm replying to really doesn't deserve to be in the grey. Rust is a great language, but like any language it has plenty of tradeoffs and room for improvement. Right now it has no REPL at all; in a few years it might, but who knows. And even if it does, it's unlikely to be able to fully replicate the experience of a LISP REPL, if only because the language is thoroughly statically typed - which of course has lots of benefits as well. Tradeoffs!
Yeah, I feel like they have done an incredible job with that aspect of Rust.
Like, they _are_ making a lot of progress, but because of the amount of time spent on developing/informing the community and other non-implementation pieces it feels like a rocket ship rather than "just" a well executed project.
In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.
> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.
I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting.
Here are a few that I think about personally and which are probably a little more unusual to see:
* Batteries not included: the standard library's been pretty stripped down in favor of moving things out into external crates. The justification is that packages included in the standard library tend to ossify and become liabilities as they outlive their usefulness [1]. I buy the argument, but am a little worried that it's going to result in a fractured ecosystem where even extremely common functions like HTTP don't have "one true path" so we get a dozen different packages that try to handle it.
* Tunnel vision focus on Tokio: to my eye the community seems a little obsessed with Tokio and zero-cost futures. It's really nice how performant it is, but I'm not crazy about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`). I think that for most cases where performance is not an absolute mission critical necessity, a light runtime that manages asynchronous operations for you (say like Go's) is probably the way to go because it unlocks far better productivity. I'm cautiously optimistic about the possible inclusion of something like an `await/async` construct.
Rust used to have a light runtime that managed asynchronous operations using green threads. It was eventually discarded because it caused an unavoidable performance hit even when not using it (because the low-level runtime and I/O methods all needed virtual dispatch) and it wasn't providing any clear benefit over just using OS threads.
I think we all agree that future chaining isn't great surface API in the long-term, but we have a pretty good idea of how to desugar async/await to the futures we have. That's why we're build the runtime around them; because they're fast and they will (someday) have a relatively convenient API.
>about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`)
How is that more boilerplate than any other way to have concurrency?
Oh, it is, it just makes them a lot easier to use. The compiler does method restructuring magic behind the scenes to build the necessary state machines. Everything gets a lot easier to understand.
The big problem with Go-like concurrency is that it does not cross the ABI boundary well, because we're still effectively stuck with C for ABIs. So if you want to use that one language for everything, that is fine. But if you want to invoke an API written in other language, then "and_then" type futures make more sense, because they can be easily mapped to a C ABI.
To give one specific example, WinRT uses futures, and there you can write async code that flows from C++ through C# to JavaScript and back, with mapping to a common ABI type done transparently at the interop layers
(https://docs.microsoft.com/en-us/uwp/api/windows.foundation....).
If and when we standardize on a higher-level ABI that includes fibers or something similar, then the other approach might make more sense. Of course, the problem is that there isn't a single consensus design to standardize on...
The futures underpinning of Tokio actually doesn't have much to do with futures. The task system is really what is special about it (though, currently futures are the main way it is exposed) however, there is a lot of potential other routes that can be explorered. If you want green threads, you could build them on top of the task system and it would interopt with futures.
Tokio feels like something that needs its own funding and dedicated team... it feels like its development has been slower than what you would expect of a critical (to me) tool for elegantly handling async connections, which is particularly important for web servers.
Hello! Rust core and community team member here. If you (or anyone else) are serious about trying to fund development of Tokio, please send us an email at community-team@rust-lang.org and we would happily connect you to people working on the project.
I'm curious what gives you that impression. What do you think is missing or should be tackled sooner than later? There has been a lot of evolution, however it has all been done in backwards compatible ways so there has not yet been a need to bump the version. It's also spread out across a number of crates.
Yet again allow me to shill for this year's Rust Community Survey, which closes June 12 and is open even to people who've never used Rust: https://blog.rust-lang.org/2017/05/03/survey.html (Yes, I know it's linked from the OP, but who reads that anyway?)
I thought that was strange survey at first, as there were very few questions related to programming and coding with Rust but plenty of questions around engaging with the community (inclusiveness/comfort level, conference attendance, etc). But then I realized it was a "Rust Community Survey".
Is there another survey more suited to use Rust as a language ala "State of Clojure"? I don't use Clojure anymore but I still love reading these every year to keep up to date with the progress it's making.
Edit: Oh nevermind, it seems the questions change if you select 'Yes' or 'No' at the beginning for "still using Rust". I didn't totally stop using Rust I just spent time learning it, experimenting on some projects, but I don't have a day-to-day need for it - not sure if either possible answer applied to me.
You might like to know that I've had great success with full stack web development using Rust. My website (https://mmstick.tk) is hosted with the Rocket (https://rocket.rs/overview/) web framework and operates as a fully static binary with 100% Rust code. I've even got HTTPS and Brotli compression.
You need a web browser that supports Brotli compression -- the standard compression algorithm for HTTPS. Safari does not support it, but everyone else does. Even Edge. http://caniuse.com/#feat=brotli
All vendors do not support Brotli compression with the HTTP protocol. Brotli is only supported when accessing a site through HTTPS. Moreover, as Brotli compresses and decompresses faster than Gzip, whilst simultaneously producing smaller file sizes, there is no point in using anything other than Brotli for HTTPS website. Hence, it's the standard compression algorithm for HTTPS. All web vendors support Brotli w/ HTTPS, except Apple's WebKit. Simple.
> Hence, it's the standard compression algorithm for HTTPS.
I think you're mistaken "de-facto standard" for "standard". They are not the same thing, and whether brotli actually is a de-facto standard is debatable, but it's not the standard.
It's perfectly acceptable to do whatever you want with your own web stack and application. You wouldn't be getting much pushback if you simply justified it as "It's what I want to do", but you are providing evidence that is factually incorrect, where no evidence is really required.
Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.
> You wouldn't be getting much pushback if you simply justified it as "It's what I want to do"
Actually, if you look at the top level comments that I've made, that's exactly what I said. What I'm getting in response to that is that I'm basically 'breaking the web' because I don't want to comply with sniffing request headers and offering gzip to Apple WebKit users. If I don't care about supporting your web browser, then I don't care about supporting your web browser. You can't make me.
> Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.
That kind of security isn't a concern to me. Not having compression at all would take a larger toll on my bandwidth, and increase latency of page delivery. Bandwidth isn't free.
Your site is returning brotli-encoded data even when the browser doesn't support it. At least, I assume that's what it's doing, because the return value is complete garbage and it contains a "Content-Encoding: br" header.
Naturally. Since moving to HTTPS, I have dropped support for gzip, and I will not be re-adding it. There is no benefit in continuing to retain legacy gzip support. Brotli can compress and decode faster than gzip, and it produces smaller file sizes. That Safari still doesn't support Brotli isn't my problem. It's Apple's problem. I'm not going to be yet another site that condones stagnant progress when everyone else has already supported it for more than a year. More sites should drop gzip support to force Apple to add support for Brotli in Safari.
If I were focused so unapologetically on purity over pragmatism at the expense of playing nice with the wider web ecosystem, I would perhaps think twice before holding my site up as a positive example of the state of web development with Rust. You may end up doing more harm than good in the PR department. :)
I see it as more of an Apple problem. Everyone else's web browser works fine, but Apple's doesn't. The main reason why companies like Apple still don't support Brotli even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. If more sites dropped support for legacy software, Apple would be forced to implement Brotli support and then everyone could benefit.
GNOME's, Xfce's, suckless', and many other web browsers are based on Webkit (WebKit2GTK+ or other ports) as well, and as far as I know none of them yet support brotli.
wget and curl both also fail to decompress your site's contents.
This is because I don't have a HTTP website! The website is HTTPS-exclusive. If your tool does not support HTTPS, it will certainly not work on my website.
> wget and curl both also fail to decompress your site's contents.
And it's not just Safari. I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Safari sends the Accept-Encoding header with a value of "gzip, deflate". If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.
I don't use Apple products, nor am I user of Safari. It's not in my interest to request for Brotli support in products that I do not use.
> I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec.
Again, I do not support HTTP! The website is HTTPS-exclusive. HTTP is basically a legacy protocol at this point. Every website should be encrypted.
> If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.
> It's not in my interest to request for Brotli support in products that I do not use.
You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really don't care about software you don't use, then why are you so dead set against serving up uncompressed content to that software?
> Again, I do not support HTTP!
You completely missed the point. I know your site doesn't support HTTP. But HTTPS is generally understood to be part of the umbrella of "HTTP". It is in fact literally the same protocol (well, for HTTP/1.1; HTTP/2 is a brand new protocol and irrelevant for this discussion), just wrapped in SSL.
> I may do just that then.
Just so we're clear, your site currently does not work, and will continue to not work, with tools like `curl` or `wget`, or nearly all other non-browser tools people have written.
> You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really don't care about software you don't use, then why are you so dead set against serving up uncompressed content to that software?
I'm not sure where you think the contradiction is. That I do not support web browsers that don't support Brotli should already tell you that I don't care if they support Brotli or not! If there is no support, there is no support! Doesn't effect me.
> You completely missed the point. I know your site doesn't support HTTP. But HTTPS is generally understood to be part of the umbrella of "HTTP". It is in fact literally the same protocol (well, for HTTP/1.1; HTTP/2 is a brand new protocol and irrelevant for this discussion), just wrapped in SSL.
Basically completely irrelevant to what's being discussed here. I do not support non-SSL HTTP connections. That is all!
> Just so we're clear, your site currently does not work, and will continue to not work, with tools like `curl` or `wget`, or nearly all other non-browser tools people have written.
Naturally. I would prefer to not have anyone using these tools on my server.
> That I do not support web browsers that don't support Brotli should already tell you that I don't care if they support Brotli or not! If there is no support, there is no support! Doesn't effect me.
You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed responses. You had to modify it to add always-on Brotli encoding.
> I do not support non-SSL HTTP connections.
Why do you keep repeating this? That's completely irrelevant to the discussion at hand. Nothing about this discussion has anything to do with whether or not the HTTP protocol is wrapped in SSL.
> Naturally. I would prefer to not have anyone using these tools on my server.
So, you want a web site that completely breaks HTTP such that only works with a handful of browsers and doesn't work with the probably tens or hundreds of thousands of pieces of other software that speaks HTTP.
> You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed files. You had to modify it to add always-on Brotli encoding.
I did not have to go out of my way to 'break support for these browsers'. All I did was replace the gzip-compression code in my page cacher with brotli-compression code. In other words, I went from always-on Gzip encoding to always-on Brotli encoding! I have never supported serving uncompressed files! The web browsers I care about (Firefox, Chrome) support Brotli, and that's all I care about! There is no purposeful breaking of web browsers. That's just persecution complex talk.
> Why do you keep repeating this? That's completely irrelevant to the discussion at hand. Nothing about this discussion has anything to do with whether or not the HTTP protocol is wrapped in SSL.
You're the one that keeps bringing up that the only difference between HTTP and HTTPS is that HTTPS is HTTPS with SSL. I am merely responding to your comment that your comment about them doesn't matter! What does matter is that my website only supports the HTTPS protocol, not HTTP. The web server only listens on port 443 with TLS enabled.
> So, you want a web site that completely breaks HTTP such that only works with a handful of browsers and doesn't work with the probably tens or hundreds of thousands of pieces of other software that speaks HTTP.
This is nothing more than pure trolling. All major web browsers support Brotli over HTTPS. Apple's WebKit is the only man out, and they are, at best, a minority on the web. Firefox supports it, Chrome supports it, and Edge supports it. Even if Edge didn't support it, the fact that Firefox and Chrome support it is more than enough for me. Other browsers are just bonuses.
Furthermore, yet again, I do not have a HTTP server, so there is no HTTP here to break! HTTPS is implemented to spec, HSTS headers and all! My website is meant to be viewed by people, not machines. In addition, as the web is moving to being HTTPS-exclusive, it's about time that you start getting used to it. You're wasting your time.
Always-on gzip encoding is also technically broken, it's just far more likely to be supported out of the box by other HTTP clients.
> What does matter is that my website only supports the HTTPS protocol
No, that has literally no bearing on this discussion about your use of Brotli encoding. You're weirdly fixated with this, but it's completely irrelevant.
> This is nothing more than pure trolling.
Do you normally go out of your way to insult people who are trying to have a discussion with you? Because that's what calling someone a troll is.
> All major web browsers support Brotli over HTTPS
Why doesn't Safari count in your eyes as a major browser? Or perhaps more interestingly, why doesn't iOS Safari count? Are you really ok with your site not working for 100% of iOS users?
> In addition, as the web is moving to being HTTPS-exclusive, it's about time that you start getting used to it. You're wasting your time.
Why do I have to keep repeating this? HTTPS has literally nothing to do with this discussion. You keep bringing it up over and over again as if it's somehow meaningful, but all it tells me is that you literally have no idea what you're talking about.
> No, that has literally no bearing on this discussion about your use of Brotli encoding. You're weirdly fixated with this, but it's completely irrelevant.
> > Important note: Brotli availability is restricted to HTTPS connections.
You Cannot Use Brotli Without HTTPS. Chrome does not support this, and Firefox does not support this. The same goes for Edge. One of the major reasons for me moving my website to HTTPS is so that I could use Brotli compression. Otherwise, Firefox and Chrome will merely get a content encoding error page because br is an unknown encoding format when using HTTP! HTTPS is required, and Google engineers are telling you this themselves. You're wrong, and Google engineers are right. End of story.
> Why doesn't Safari count in your eyes as a major browser? Or perhaps more interestingly, why doesn't iOS Safari count? Are you really ok with your site not working for 100% of iOS users?
I do not care if iOS users using Safari are unable to access my website. In the same way that iOS app developers do not care that Android users cannot use their apps, I do not care if iOS users using Safari are unable to access my personal blog. My target audience is not iOS users. My target audience consists of Linux users using either Chrome or Firefox.
So basically, you have tunnel vision and are just here to bicker and argue senselessly about things you don't understand or are unwilling to accept. I'm not sure why you're so upset that I have decided to not support your access to my personal blog. No matter how many times I explain things to you, you never seem to get it through your head. This is my website, not yours. I will not support gzip, and I will not support uncompressed content, nor will I support tools that only work with HTTP.
I already explained this in another comment almost an hour ago (https://news.ycombinator.com/item?id=14346188). Brotli works perfectly fine over HTTP. The only difference between HTTP and HTTPS here is Chrome does not include "br" in the Accept-Encoding header for HTTP. But it will still handle a Content-Encoding of "br" just fine over HTTP.
> One of the major reasons for me moving my website to HTTPS is so that I could use Brotli compression.
Why do you care so much about this particular compression format?
> Otherwise, Firefox and Chrome will merely get a content encoding error page because br is an unknown encoding format when using HTTP!
You clearly did not test this, because Chrome interprets Brotli responses just fine over HTTP. I wager Firefox does too, but I'm not about to install Firefox just to test.
> You're wrong, and Google engineers are right. End of story.
Google engineers are right, but you are not right. You don't understand what the Google engineers are saying. The link you provided specifically has to do with the Accept-Encoding header and not Brotli support as a whole.
> My target audience consists of Linux users using either Chrome or Firefox.
I still don't understand why you're intentionally breaking the open web. It makes no sense.
> No matter how many times I explain things to you, you never seem to get it through your head.
You should try actually listening. You keep explaining things that are factually wrong or completely irrelevant. You seem to not actually understand HTTP, HTTPS, Content-Encodings, or even the idea of the open web in general. And you're going out of your way to break 99% of tools out there for no discernible reason. Why do you love Brotli so much that you're willing to break HTTP just to use it?
Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works. I am not the only person who can provide proof that it will not work. It clearly states it on the Google URLs that I sent you that it does not work without HTTPS, along with some reasons as to why that decision was made. You are, instead, trying to argue in face of reality. That is foolish.
> You clearly did not test this, because Chrome interprets Brotli responses just fine over HTTP. I wager Firefox does too, but I'm not about to install Firefox just to test.
> Google engineers are right, but you are not right. You don't understand what the Google engineers are saying. The link you provided specifically has to do with the Accept-Encoding header and not Brotli support as a whole.
You don't seem to understand what you think you understand. Accept-Encoding means that it will not publicly state that it supports Brotli. I wonder why that is..... because Brotli is disabled for HTTP connections. End of story again! Stop beating the dead horse! You are wrong.
> I still don't understand why you're intentionally breaking the open web. It makes no sense.
I don't understand why you think I am. If anything, you are merely trolling and wasting your time.
> You should try actually listening
I've listened and listened, but you aren't speaking anything worth listening to. You yourself refuse to listen to my point of view and explanations, so why should I bother listening to your BS?
> You keep explaining things that are factually wrong or completely irrelevant.
I have done nothing of the sort. You, however, are stating that Brotli works over HTTP. This is factually incorrect. It is not allowed.
> Brotli is HTTPS only
>
> If you visit a site over HTTP your browser will not accept the br encoding. The reasoning for this is documented at the end of the chromium issue.
> 'm not sure if there is a technical reason behind this, but all the browsers I tested with require HTTPS in order to enable Brotli support. I have written a small post about more reasons to switch to HTTPS as well.
You are basically calling Google and each of these authors that I've linked as liars as we all have tested Brotli over HTTP and HTTPS and can concur precisely what Google and Mozilla engineers stated: Brotli is only supported with HTTPS!
> And you're going out of your way to break 99% of tools out there for no discernible reason.
First you said it was 40%, and now you are saying it's 99%? Both statistics are bogus given that around 80% of users are using either Chrome or Firefox, and versions that support Brotli!
And going out of my way? I already explained to you how I did not go out of my way. I am not targeting anyone. It was only a few lines of code to change my content cache from being Gzip-backed to Brotli-backed. You just have a persecution complex. I actually had to go out of m...
> Brotli does not work over HTTP. Period. It doesn't work, and you have yet to prove that it works.
I really do not appreciate you continually calling me a liar (since I've told you in no uncertain terms that I personally have tested this behavior), especially since all you're doing is an appeal to authority ("Google engineers!") based on a misunderstanding of the issue at hand. You keep claiming you have "evidence", but all your "evidence" proves is that you need to work on your reading comprehension skills, because those pages do not say what you think they say.
> You are basically calling Google and each of these authors that I've linked as liars
Let me try this again:
YOU DO NOT UNDERSTAND THIS ISSUE. YOU DO NOT UNDERSTAND HOW CONTENT ENCODINGS WORK OR WHAT EFFECT HTTPS HAS ON BROTLI. I AM NOT CALLING THEM LIARS, I AM CALLING YOU INCREDIBLY IGNORANT.
I am done with this conversation. I am not going to respond to any more of your comments. You don't understand basically any part of what's going on here, but you think you do and you won't even acknowledge the possibility that you are wrong. You're also misinterpreting nearly everything I say, because you're not actually reading my damn comments, you're just skimming them looking for things you can argue against. Case in point, your sentence that starts with "First you said it was 40%"; I was talking about tools that speak HTTP, which was extremely clearly from context, and you're completely misinterpreting that as browsers, and what's more you're even putting words in my mouth (literally nowhere did I say 40%).
That is a serious breach of HN's civility rule and the sort of thing we ban people for. When someone is provocatively repeating wrong statements (or appears to be) and is getting increasingly rude, the way to deal with that is not to lose your own cool, it's to realize that there's no win in this and just leave it.
A.k.a. don't feed the trolls, it takes two to tango, two wrongs don't make a right, and sundry other things our mothers told us.
I've deleted the offending line. But I admit to being a little surprised that "ignorant fool" is considered a serious breach. That honestly seems fairly tame to me. I was looking for a phrase that meant that not only are they ignorant, but they're either unwilling or unable to recognize this. But I suppose I can believe that other people may read more into the phrase that I intended.
The bulk of the responsibility for this ludicrous flamewar is yours. You became increasingly uncivil and spatty in this thread, and proliferated reams of tit-for-tat filler.
This is the sort of argument that gets a few combatants hot and bothered and clogs up the site with tedium for everyone else. We ban accounts that do this, so please make sure it doesn't happen again. HN threads are for good conversation, and there's no worse conversation than this kind of bickering.
I also don't depend on my blog for food. But I do care and if this were a customer project or something commercial you'd be dead in the water. That's a friendly way of saying that your opinion on what is 'standard' really doesn't count for much with me. You've polluted this thread with I don't know how many comments essentially shouting down each and every patient and restrained effort to teach you something but you won't take a hint.
Maybe you can explain to me why I am supposed to cater to other's whims as if my personal blog was a commercial project. It's not. Nobody is trying to teach me things here. They are simply demanding that I do what I have already clearly expressed that I am not going to do. This is my personal blog, not yours. I get to set the rules, not you. Perhaps you can take a hint and not demand others to do things for you even after they've expressed that they don't want to? If anyone is polluting the thread, it's your kind. Snarky, combative, argumentative, and ignorant. If you want to be an asshole, you'll get what you ask for from me.
You are, in fact, right. But I advise you to read about HTTPS here, so you can more clearly understand the points others are making: https://en.wikipedia.org/wiki/HTTPS.
> even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari.
That says it all really. Unfortunately it also seems to be a common attitude in the rust community.
Something doesn't become legacy just because a newer option has been available for a year.
> Unfortunately it also seems to be a common attitude in the rust community.
Eh, maybe in some segments, but I don't think that's the majority culture. See https://github.com/rust-lang/rfcs/pull/1985 for something extremely relevant to the discussion here, heh.
I'm not saying you should support gzip. I'm saying you're sending Brotli-encoded data even when the browser doesn't support it, which results in the browser showing what looks like effectively random bytes. You need to respect the Accept-Encoding header.
That would require that I cache both a gzip and brotli variant of each page and content that is requested. I see no reason to support gzip just because a single company has refused to implement support for Brotli. Firefox, Chrome and Edge all support Brotli. Safari is the one man out. Apple needs more complaints about the lack of Brotli in Safari. Using Safari? Don't. You have Firefox and Chrome on all of your platforms.
Also, you don't seem to understand. I'm not telling you to support gzip. If the browser doesn't support Brotli, then just send back uncompressed content.
And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.
It's not user-hostile at all. It is quite simple. I don't want to implement gzip support, and I definitely don't want uncompressed content. You can't demand me to implement what I don't want to implement for my website. You are not my target audience (gzip users, IE users, Safari users).
> And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.
My website does not support HTTP. HTTP is basically a legacy protocol at this point. My website is HTTPS-exclusive. It does not listen on port 80. That Brotli doesn't work through HTTP is not surprising, given that HTTPS support is a base requirement for Brotli support.
From your last paragraph I question whether you really understand anything you're being told here.
Yes, I said HTTP instead of HTTPS, but that wasn't meant to signify that I was using unsecured HTTP, since HTTPS is supported virtually everywhere and generally understood to be a part of HTTP. More specifically, if I actually try and access http://mmstick.tk, I just get redirected to https://mmstick.tk anyway, without having a content body, so it's not even possible to get Brotli-encoded data out of your server over HTTP. And if I run `curl https://mmstick.tk` then I get garbage, which was the whole point of that sentence and what you still haven't even addressed.
Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP.
I'm not sure where your confusion is. It doesn't matter that HTTPS is an encrypted form of HTTP. I do not support HTTP, which means that I do not support HTTP without encryption! End of story.
Attempting to access the site via HTTP will merely redirect you to the HTTPS service. Nothing is being hosted on the HTTP service. When you reach the HTTPS service, your browser will receive a HSTS header that will cause your web browser to automatically direct to the HTTPS server and not touch HTTP at all for future requests, ever. Nor can your connection be downgraded to HTTP.
> Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP.
Tell that to Google, Mozilla, and Microsoft. You cannot use Brotli compression over HTTP. Only when you are using the HTTPS protocol can you use Brotli. And in general, if you support HTTPS and are using an update browser, you more than likely already have support for Brotli today.
This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Brotli-encoded response over unsecured HTTP.
My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.
> This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Brotli-encoded response over unsecured HTTP.
I highly doubt that you actually tried this in practice. You are merely assuming that it works. For Google to overturn their decision would fly against all reasoning for the decision in the first place.
> My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.
You seem to not have any experience with Brotli support and why the decision was made to only support it over HTTPS. One such comment that outlies the reasoning is from a Google employee themselves ( https://bugs.chromium.org/p/chromium/issues/detail?id=452335... ).
Hence, all vendors have followed suit and are not implementing brotli for HTTP. SSL prevents all the middle man infrastructure in place from employing such tactics that would break websites serving content with the br content encoding. There still exists much infrastructure in place that snoops HTTP traffic and, when it is detected that the content encoding is an unknown format (brotli), it will compress the stream with gzip and change the content encoding to gzip, thus breaking the website.
In addition, yet again, Google engineers clearly state that Brotli support is only available over HTTPS connections!
One of the big reasons for my decision in pursuing HTTPS support on my personal blog was so that I could, in fact, use Brotli. I already had the code in place, but enabling Brotli on my web server would merely give errors about the content encoding being unknown, and as you will notice, br is missing from the list of available accepted encodings by the browser! Yet it is there when connecting via HTTPS! That's because Brotli is completely and utterly disallowed over HTTP! Google engineers stated it themselves. You can't have it both ways.
> I highly doubt that you actually tried this in practice.
I told you explicitly that I tested it. Now you're calling me a liar. I am not "merely assuming that it works", I actually tested it to the point of controlling the exact bytes that the server sent to the client using a hand-constructed HTTP response and then pointing Chrome at that server.
> For Google to overturn their decision …
I just looked into the specific behavior here. Here's what I found:
* If you point Chrome at localhost, it includes "br" in the Accept-Encoding header.
* If you point Chrome at some other domain using HTTP, it does not include "br" in the Accept-Encoding header.
* Either way, if the server actually returns a Content-Encoding of "br", Chrome will respect it.
So basically, Chrome always supports Brotli-encoded responses. However, it only requests Brotli over HTTPS and doesn't request it over HTTP, and the only reason for this distinction is to avoid middleware servers from mucking with Brotli-encoded pages that they don't understand.
No, No, and No. Google engineers have repeatedly declared that Brotli requires HTTPS, because they do not allow it's use of HTTP. You cannot use Brotli over HTTP. You are merely assuming that you can. I am stating that you are lying because you can't have it both ways -- either Google engineers are lying about what their software does, or you are lying about what their software does. It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS. I should know as that's one of the main reasons why I moved to implement HTTPS. It's right there in my latest article on my website before I posted it here. Brotli does not work without HTTPS. Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story. You're not very bright to continue arguing against this.
mmstick, what part of "I have actually tested this" do you not understand? I am not assuming anything. Please stop skimming my comments looking for things you can try to argue against and actually read the damn things.
> It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS.
Again, you don't understand what you're actually reading. There are two parts to Brotli support. The first is whether the browser will declare that it supports Brotli. This is the Accept-Encoding header. The second is whether the browser will actually correctly interpret a response encoded as Brotli. HTTPS only affects the first part. Chrome only declares to the server that it can accept Brotli when sending an HTTPS request and not when sending an HTTP request. But if the server ignores the Accept-Encoding header and hands back a Brotli response anyway (like your server is doing), Chrome will handle that exactly the same way over HTTP as it does over HTTPS. Because it's just a content encoding, and there is literally no reason to make the code that handles content encodings care about HTTP vs HTTPS.
> Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story.
Please try testing this, because I promise you this is wrong. Switch to HTTP and if the server returns a Brotli-encoded response (with the Content-Encoding header set correctly) Chrome will still decode it. The only thing HTTPS controls is the contents of the Accept-Encoding header and not the actual behavior of the response decoder. I have tested this multiple times against Chrome 58.0.3029.110, using both localhost and a remote server. You clearly have not, and in light of this your final sentence is particularly ironic.
Eridius is right in that it currently does work over insecure HTTP in Chrome, as confirmed in this open bug: https://bugs.chromium.org/p/chromium/issues/detail?id=579606 -- in which one Chromium dev comments "Decoding brotli even if it isn't requested is both bug and feature. It allows developers to test brotli without setting up https serving." Seems like they concluded that it is indeed a bug, however.
Reality and specifications often diverge...
(I do think not supporting gzip is absolutely bizarre, but that's another issue.)
> That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable.
You wouldn't host a page if you didn't want to share its content, doesn't failing to do so make it atleast partially your problem?
You are ignoring the list of encodings the client gives you, you are paying attention to some and not all. If we all did the web wouldn't work.
Maybe they have good reasons, you aren't them and you don't know their situation. But you have chosen to not share with people with tech older than one year...
Step back, and try to take an objective look at this. Do you know what percentage of web browsers actually in use will work? Do you know what percentage of people visiting your page see only gibberish?
Finally, Why are so many of your comments in the gray and everyone else's not in the gray? Why do so many of your technical peers disagree with you?
It supports HTTPS perfectly fine. I am even on the HSTS preload list. You can't get on this list unless you have a HTTPS website that meets standard requirements. https://hstspreload.org/?domain=mmstick.tk
You repeatedly posted uncivilly in these comments. That's a bannable offense on HN, so please don't do it again, regardless of how wrong you think others are.
What a mess! Came to this thread to read about Rust and its progress and this has devolved into a useless discussion about some person's website, who seems to consider that he/she is doing all the right things and the rest of the technical community is stupid.
Completely lost track of what thread I was reading.
That's why your friendly janitorial staff detach these and mark them off topic so they fall to the bottom. That way you only see them when there's nothing else to read.
One of these years we might implement a "More" link at the bottom of threads so you have to go to a second page to see them at all.
I get a message that says, "Your web browser does not support Brotli, and therefore is not supported. Report this as a bug to your web browser vendor."
I am using Firefox 53.02 on Linux, and my browser is sending this request header:
Accept-Encoding: gzip, deflate, br
As far as I know Firefox fully supports brotli compression. Any idea what is wrong?
The success stories are Mozilla's Servo, Dropbox's client and back end, and parts of Gnome. That's good. It's interesting that all the success stories involve mixing Rust and C/C++ code. Are there any pure Rust successes yet?
I was under the impression that Mozilla Servo is entirely written in Rust (GitHub appears to not be able to run linguist on the repo at the moment, the language detection isn't showing up).
We use some C/++ components (the JS engine is purely C++, and we bind to various C/++ libraries for things like graphics. We don't have the resources to rewrite everything).
The OP seems to be mostly referring to the integration with Dropbox's Windows client, which AFAIK is actually Rust+Python. Rust+Go is what Dropbox uses for their storage backend.
I personally love that Rust is getting used to complement so many other languages (e.g. Rust's first known production use was as part of a Ruby gem). Easy integration is something to be celebrated, because it means you don't need to rewrite the whole world to get benefits.
I'm really excited by the new edition of the rust book mentioned in the post, from a brief look it seems that it covers all the areas I felt most needed improvement (for example what does a "move" mean?, a concept completely omitted from the first edition).
Also, I want to plug just how fun Rust is to write once you begin to learn how it works. It's totally awesome to write fast code that doesn't segfault, especially when it comes to things where tooling in other languages is lacking, such as doing parallel data processing. Speaking of which, I'll shamelessly plug some recent results from a Buddhabrot[0] renderer I wrote[1] in Rust:
In one sense, IO, and in another sense, both; that is, what you do there is use futures-cpupool, which is a threadpool with a futures interface. So it still all composes just fine.
Congratulations to the Rust team for the great work!
The impact of Rust on the programming safety community has grown so big that even hardcore Ada developers are getting really nervous about Rust's powerful competition.
Although Nim and Lisp are still more productive than Rust for my use cases -- Rust really needs a convenient edit-compile-debug cycle, and also an easy bootstrap from source mechanism -- I am watching Rust's development with pleasure.
I am pretty convinced that within the next ten years Rust will not only cause a serious decline of C++ but also eat a big portion from Ada's lunch in safety critical applications.
311 comments
[ 3.0 ms ] story [ 218 ms ] threadhttps://en.m.wikipedia.org/wiki/Modula-3
https://en.m.wikipedia.org/wiki/PreScheme
Still, I now prefer doing such things in Rust.
On the other hand, I'd argue that Rust makes up for the complexity with performance, power (ability to express more complex programs in less code), and safety (not just memory safety, which Go also mostly guarantees, but the ability to leverage the type checker to verify code correctness in general). C++, on the other hand, is more complex (due to all the legacy drift), yet equal in performance, less safe, and less powerful in most respects (there are some things C++ can do that Rust can't, but more things for which the opposite applies).
Swift can downcast, and it has generic extensions and generic protocols. I highly suspect it has a Turing-complete type system as well.
Supporting this requires heroic effort in the compiler, but it can be done.
Given the GP's note about the connection between written and compiled code and how a GC affects that, I think this is exactly what is being referred to. I.e. a GC makes everything much simpler up until it doesn't, and then it makes it much more complicated. That point may never be reached in many programs, but it may be hard in some cases to tell whether it's something you have to worry about at all.
I would say that's true in general, but in Go there's a lot more room to ask the GC to get out of your way if you need that than most.
Also your complaint can be applied to C as well.
Given how optimizing compilers work, and the amount of UB being exploited, the language stoping being simple long time ago.
In terms of implementation complexity, Modula-3 is also much simpler, despite the existence of a GC. A Modula-3 spec would be a great deal smaller than an equivalently detailed Rust spec. Many people have independently implemented Modula-3, whereas an independent implementation of Rust is effectively impossible, due to all of the unspecified implementation-defined behaviors. If you told me I had 1 year to implement either language from scratch, I would much rather choose Modula-3.
There's another that's not public.
Note: this refers to "Diverse Double Compilation", which is a mitigation tactic against Reflections-on-Trusting-Trust attacks.
https://github.com/kframework/c-semantics
http://www.kframework.org/index.php/Main_Page
Then you should be talking about Rust, C++, Java and other complex languages if that's your concern. Wirth-style languages use simple constructs that map straightforward to assembly. He actually designs the language in conjunction with the compiler so the simplicity is maintained. If it's hard to compile, he just takes it out of the language. Modula-3 adds select complexity to a Wirth-style language to give it exceptions, multithreading, and a standard library. Most of them are similarly straight-forward in implementation. It's why it compiles lightening-fast.
Rust being simpler than other programming languages you cite actually means those languages are enormously complex. That is, given how much more complex Rust was to Wirth-style languages, Smalltalk, Scheme, and so on. It has extra stuff. Hence, the extra complexity. The compiler is also harder to write to make all that work.
PreScheme sounds like an interesting idea.
To be clear, I'm not a Rust guy, or even C++, Go, D.
On top of that, I'm a 2PL advocate (two programming languages). I think a combination of a readable high-level language like Python or Scheme, and a fast systems language like C, can carry out feats that no single programming language can as far as I know. (I don't consider keeping two or three programming language in your head while doing productive work a big deal, especially when learning multiple language is considered a beneficial thing).
As I recall, that's the main problem with D: the standard library basically requires GC. Your code might not require it, but the library is always there. On top of that, it's just too easy to accidentally involve GC by using reference types.
However, I do appreciate the syntax which IMO is in that sweet spot between conciseness and expressiveness. Finally, the borrow checker is quite the experience. Whenever I banged my head trying to get some snippet to pass BCK, there was always an OH moment where I realized something was terribly wrong with my design.
PS: Yes, there's still a few weird BCK false-positives. Hopefully we'll soon have non-lexical lifetimes[1] that should fix most issues.
[1]: https://github.com/rust-lang/rust-roadmap/issues/16
"No technology can ever be too arcane or complicated for the black t-shirt crowd." - Linus Torvalds
Another example is the "This Week in Rust" newsletter which takes progress that would've taken you hours to read about yourself, and puts it into a succinct format that you can get through in minutes [1].
The Rust 2017 roadmap which targeted forward movement on all the language's weakest features was admirable in itself, but even moreso is how much progress has already been made. In particular, I'm really excited about incremental compilation, which is showing as much as 5x speedups in early results [2].
I was also very happy to hear that the Rust team acknowledges that regardless of how performant they are, futures are not a particularly ergonomic or maintainable way to write code, and are considering what new constructs might look like over the longer term:
> Over the rest of this year, we expect all of the above libraries to significantly mature; for a middleware ecosystem to sprout up; for the selection of supported protocols and services to grow; and, quite possibly, to tie all this all together with an async/await notation that works natively with Rust’s futures.
I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension, or as high level as a DB-backed HTTP application. It seems to have an almost perfect compromise between performance, safety, productivity, and ecosystem.
[1] https://this-week-in-rust.org/
[2] https://blog.rust-lang.org/2017/05/15/rust-at-two-years.html...
Rust is like a fresh breath of air, and the community around the language is a great example how an OpenSource project can work without being hostile to newcomers. Kudos to the Rust team!
Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc.
Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost.
I saw someone use the analogy of a credit card on here before: purchases are very easy to make, but have to be repaid in full, and without perfect discipline you'll be paying interest on top. Now consider most development teams (who are generally strapped for resources) like middle-class earners who don't make quite enough to pay back that balance every month. It starts to accumulate, and the owed interest compounds.
Compilers can do a lot to ensure high productivity and a good user experience: (1) be fast, (2) have great error messages, and (3) be easy to use (no makefiles or heavy build systems). Rust's compiler has learnt from the mistakes of its predecessors in other languages, and does all these for you.
https://root.cern.ch/
If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win.
It's also a win for people who come home from work and want to get features done on their side projects rather than write perfect code.
It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts.
If your language doesn't have a REPL, your language is less productive. Deal with it.
That said, the engineering tradeoffs are often a win. I love Rust; borrow checking is frankly incredible. But it's important to keep perspective.
Oh hardly.
As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least. I've honestly never understood the obsession with it.
Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn out a UT to prove my code does what I think it does is incredibly important.
But a REPL is a nice-to-have. Nothing more. Treating its absence as some fundamental black mark on a language is completely absurd.
In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one.
Think about it like this: On your list of languages, which of them would you say is most productive? It depends on the context, certainly: libraries, familiarity, etc. But let's assume the languages had identical ecosystems, and that you were competent in all of them. Which of them would take the smallest amount of time to write your feature?
That'd probably be Python, Haskell, or even Perl. It seems very difficult to argue that Rust would top them. And the reasons why this is might be true are worth examining.
Here's another aspect. Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? How about 20? 2?
It becomes very difficult to argue that your programming language is the lingua franca of the future. (And that's probably true for every language, not just Rust.)
Define productive.
Are you measuring raw lines of code generated?
Or are we measuring amount of production-ready code?
My bet: with an experienced, diligent developer it's a wash. My gut says what you lose in a slow code-execute cycle of static, compiled languages you gain in lower defect rates from compile-time checks. Conversely, what you gain in a dynamic language, you lose in errors caught at run-time.
At that point I'd select for languages that are simpler with fewer surprising semantics (crossing Perl and Javascript off the list), with more built-in run-time and/or compiler safety (knocking things like C off the list). I generally also prefer compile-time safety over run-time safety, as I'd rather find problems on my workstation than in the field because I missed testing a codepath.
Actually, I think Perl has fairly few surprising semantics after you learn the major ones. The real problem is that the major one (or specifically the major one, context) is somewhat hidden in normal C-like usage until it jumps out at you and confuses you. Once you understand what it is, it's not all that surprising (but there are a few annoyances with it that still persist and cause problems). You can write Perl that looks almost exactly like C 95% of the time, but that 5% where it matters makes people that do this very confused. There are, of course, other parts of the language that are poorly chosen, but I maintain there are actually far less of them than many people seem to think.
As for JavaScript, I still can't get over all the different ways to check for equality and null or undefined. I understand a good portion of that is because I never have to use JS enough to become truly proficient, and some if it is just poor design.
Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." They were speaking from their own experience, based on their own balancing of the trade offs as a user. Presumably a REPL doesn't rate very highly for them.
However, the reasons we don't have a REPL are mainly two: the compiler isn't architected for it and code doesn't compile fast. The solutions are:
* Re-architect the compiler to support incremental code input. This is pretty similar to what we need to support IDEs (which we're working on), so possibly this will solve the problem.
* Get a reimplementation of the backend which is a JIT interpreter instead of LLVM, which takes up most of our compiletime. Work is underway on a project called miri, though it isn't officially supported right now.
* Make the typechecking part of the compiler faster. This is underway through a project called chalk.
In other words, a REPL is not impossible, it just isn't a top priority right now. There are other lacking tools that we're working on - IDE integration and auto-formatting for example - maybe after those are done it will be the top of the docket.
Respectfully, the community has become increasingly vocal, and it's getting hard to separate the enthusiasm from realism. It's embedded in every HN thread. That's a good problem to have, but it can be a bit repellant to people who aren't Rust converts.
Thanks for the breakdown and future roadmap. I hope the compile times can be kept to a minimum in order to avoid C++'s fate.
It's a relatively recent addition though.
That definition excludes any bare-metal language, and use cases where you want to take advantage of cheap low-level memory protection features such as No-Execute bits. For me, a more interesting benchmark would be how well Rust fares in implementing the runtime of a higher-level language.
Some projects are written as explorational prototypes or MVPs. I don't think anyone is saying Rust is much good for those.
But (numerous) other projects are written as "the first real Quality implementation of [well-known problem], using a decade's experience with other implementations." Much of the common software we use—{server daemons (HTTP, SSH, DNS...), parsers and encoding libraries (for XML or JSON; JPEG or PNG; MP4 or MKV...), databases, load-balancers, distributed queues, ...}—fits this paradigm.
If you're writing Nginx, or Redis, or djbdns, you aren't "adding features" out of some agile user-story kanban; you're carefully implementing a small, curated set of well-known, well-understood features, with much research done to ensure that you arrive at the best and least fraught implementation, the one that will make people prefer your software for its quality and reliability and set-and-forget nature.
Rust is for that kind of software. (Which makes sense, given that Mozilla's Servo rendering engine also has the goal of being that kind of software.)
In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle. So, it doesn't really matter to them so much as quickly getting out working features. In other cases, esp long-lasting endeavors, then this is a good point to consider.
Or grow so quickly that replacing most the legacy code from a year or two ago is not a significant hurdle at their new size.
In this vein, I wonder if there's actually a third path that might be better than both. Using a low-level but fairly expressive and strongly typed language but very loosely, such that it allows you to iterate fact but with less performance, and you can come back later and replace chunks as needed, but with the same language. I don't have any real experience with that, and I could see it going either way for a number of reasons, but it seems like we have more languages that might fit that criteria now (or at least they are more popular now) than we have previously.
Web browsers are not that kind of software. The web is evolving much faster than any of the other things you mentioned. New features get proposed every year, and you just have to deal with it and implement them, even if they complicate the implementation of the browser. Even if you cut that off, you still have to deal with the horrific mess that is the cumulative total of past web-related decisions.
There's certainly a layer of a rendering engine—the part that translates a CSSOM into rendering pragmas—that changes a lot over time. But rendering the resulting pragmas itself doesn't change much, and features requiring new pragmas come about remarkably slowly.
Clearly, though, you know what a rendering engine is, so I'm not sure what your argument in the GP post was. Was it just a tangential statement (i.e. "rendering engines are well and good, but it'd be silly to write the browser itself in Rust, for [reasons]"), rather than a rebuttal...?
Your post came off as implying REPLs don't have serious benefits for anyone, which felt a bit presumptuous to me.
BTW, I actually stand by your interpretation. I challenge anyone to demonstrate significant productivity gains (as measured by number of lines of tested, production code written) that can be attributed to the availability of a REPL (which was the claim of the poster I was replying to).
I honestly don't buy it. I believe it's a very nice tool for learning a new language, and maybe for exploring an existing codebase, but I can't envision a workflow where a REPL provides significant productivity gains for an experienced, professional software developer that aren't realized in other ways (e.g. writing unit tests).
It's high-speed iteration of code one is exploring that makes both REPL's and incremental compilation superior for productivity to full compilation.
That's not even the beginnings of a useful reply. :)
Give me a highlight of your normal day-to-day with the language. What, exactly, does the REPL offer you that provides significant productivity gains that can't be had any other way?
Because clearly I've missed it.
And it should be pretty easy for you to describe if it's that common and/or obvious.
In a statically typed language, a REPL can still be useful, but the gains from it are less than you'd get with an untyped language. It's easy to see what kinds of data a function works with by just looking at the types. There are exceptions of course, like when the type is very complicated, it can be helpful to see some examples of actual values of the type. And I suppose that's why languages like Haskell and OCaml have REPLs.
No one can demonstrate productivity gains because productivity can't be measured. Lines of code can, and those are often a bad thing. Some of our most productive efforts make programs smaller.
So then the OP shouldn't have made the claim. It ain't my job to prove it. :)
That said, I fundamentally disagree with the idea that one can't measure developer productivity. I agree that there are many potential measures, all of which have the potential to be flawed or distorted. But the idea that the productivity of a developer can't be measured at all is something I've never heard anyone seriously claim.
> So then the OP shouldn't have made the claim
Come now, it was you who moved those goalposts and you moved them half a field or more. OP claimed REPLs "have benefits". Your response was (paraphrased) "demonstrable measurement of productivity improvement or GTFO". That sort of ante-upping just isn't that nice for good conversation, and certainly not when you're demanding a standard none of us can meet about anything.
> If your language doesn't have a REPL, your language is less productive. Deal with it.
That seems exactly like the kind of claim that everyone should view with a healthy dose of skepticism, and I think zzalpha's initial response[2] hit that right on the nose.
[1] - https://news.ycombinator.com/item?id=14344891
[2] - https://news.ycombinator.com/item?id=14344957
I repeat: there are no perfect measures of productivity. But there are imperfect measures that have some utility. The idea that we cannot measure at all because we cannot measure perfectly is simply untrue.
In this case we could, for example, take 1000 individuals with similar years of programming experience and given them two languages and a non-trivial problem to solve and see how long they take to come to a working and correct solution.
Is that perfect? No. But it's still something that's measurable. Do that with a reasonably large sample and you can probably start making inferences.
Our industry suffers from a horrible lack of concrete, scientific studies to back common wisdom. We would all benefit from ignoring Fowler, here, and getting down to the nuts and bolts of finding solutions to that problem. Until we do, while we'll have lots of fun having pointless debates on HN that cannot be resolved because we have no real data, the industry simply won't move forward.
Unit tests provide some additional benefits, but are a heavier approach with a slower, clunkier feedback loop. There are times when those additional benefits are not worth the added cost. Unit tests are also additional code that must be maintained.
I guess it's one of those things that's imho hard to appreciate if you never experienced it.
That's called a remote debugger, and it's hardly unique to languages supporting a REPL.
I guess it's one of those things that's imho hard to appreciate if you never experienced it.
The true key to understanding REPLs is their role in consuming third-party libraries. While languages both with and without REPLs will have well-used packages in their package ecosystems that are well-documented; languages with REPLs will also manage to have well-used, poorly-documented packages: packages whose "documentation" consists only of the de-facto ability to reflect on the API in a REPL, doing the moral equivalent of exploring a filesystem using cd(1) and cat(1), until you figure out what functions—and what arguments—combine to produce an acceptable result for your use-case.
That may sound like a bad thing, but it's not! Those packages are packages that wouldn't exist otherwise; they're marginal packages, packages which people wouldn't have had time to write if they were required to also document them properly enough to make use of them without a REPL. They're needs being satisfied, that would otherwise—given the stricter requirement of useful API documentation—be going un-met.
If you look at e.g. Ruby's gem ecosystem, there are tons of packages that have more than a million downloads, and either no docs or awful docs. How? Because Ruby is extremely amenable to exploring APIs through a REPL. You take a module or class, ask it what its children are, what its class methods are, what its instance methods are. Find a class with instance methods that sound right, attempt to instantiate it. Figure out you can't do that, look around the class methods for something that sounds like a factory method. What arguments does said factory-function take? Well, feed it some at random and see what error you get. Etc.
For languages with a reasonably sophisticated IDE, use the IDE itself to jump straight to the class/function declarations to understand the surface area of the API, and jump to the decompiled code for the implementation of those functions if you're the type to want to understand the machinery.
Other languages (like Haskell) may not have the IDE support but attempt to solve the problem with auto-generated docs so you can at least see the surface area of the API and can start prodding it.
~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days.
Admittedly, I've never used an IDE; I write all my C in vim.
> ...you write compiled unit tests and/or test programs to poke around at the API.
That assumes you can get your tests to compile; or that the compilation errors are at-all helpful when they don't. If you've got a library that
1. ships as a binary blob + header files, and
2. most of its functions take handles to structs that are declared opaquely in the SDK headers; and yet
3. nothing you do with the badly-documented "create handle" parts of the API is giving you a struct that the "consume handle" parts of API will do anything with but crash...
...then you'll really wish that you had a REPL; or rather, a language runtime that enforced some level of introspect-ability on everything, so that a REPL could show you what's in the struct and whether your calls so far have failed to touch some obviously-necessary-to-fill-in part of it.
Without such support, you will have to rely on reading the decompilation results of both ends of the API to figure out what's really going on.
Yes. I write roughly equal amounts of C (microcontroller firmware) and Python (overall system control, running on embedded Linux).
I absolutely wish I had a REPL for C. When implementing with a new library in Python, I'll usually use iPython to explore it, and if I need to run a decent amount of data through, I'll use a Jupyter notebook. I'd put the difficulty of grokking a C library somewhere between 10x and 100x harder.
They were quite common advertising in The C User's Journal and Dr. Dobbs.
And now we get to the real meat of it.
It's not a REPL you want.
It's reflection.
It just so happens that the latter is frequently paired with the former.
And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compiler, debugger, and IDE can do a much better job.
But as a feature it's orthogonal to a REPL.
But when you are working in a language with runtime code generation—one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an IDE cannot†.
A REPL in a dynamic language (that takes advantage of its dynamicity) can be used to "explore" down CORBA/DBUS object trees; or fluently walk REST or SOAP endpoints without needing pre-baked WSDL descriptors to guide you to them. Heck, an Erlang REPL can hot-upgrade remote nodes. :)
† Or, at least, not a traditional IDE. You would need an IDE connected to a "live session" of your project—essentially a hybrid IDE-REPL. (Examples: Light Table; Emacs' CIDER extension for Clojure.)
Two dynamic and one static languages.
(Still, doesn't fit all use cases of a REPL for this. REPLs are especially nice for when you want to fit together highly generic APIs)
And if you are writing Coq or Agda—well, you certainly don't need a REPL at that point. The code writes itself. ;)
I happen to use more often the IDE's graphical debugger than the REPL.
Still Visual Studio has had immediate mode (aka REPL) since VB days, followed by .NET support.
When I wonder how something works or if I need my memory to be refreshed, I just fire up jupyter console and test quickly the code. I don't open the doc or search on the net. I have the live result immediatly.
When I want to debug my web server, I drop a REPL in the server and play with the code. It's more efficient that just debugging, because I can actually modify the code live and see what happens.
When I need to understand a format and how to manipulate / tranform data, I use the REPL (or jupyter notebook) because it's the most natural way to do it.
I don't know how much Python you have done, but you have been missing one of the greatest tool of the ecosystem.
It's like saying you don't see that much the benefits of an IDE for refactoring in Java. "yeah it's cool but how much do you use it hu ?".
So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto all of them, and (2) this is very much my personal opinion.
---
I'd still defend the position though. Every language has merits, but especially for a lot of the older ones, there are so many accumulated problems that it's worth considering newer languages just because they're learned so much for the mistakes of their predecessors. For example, I've been doing Ruby for quite a few years now:
* Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability. It buys you a little early productivity, but any honest person with a huge Ruby codebase can tell you that it's a liability.
* The only way to get truly good performance is to write a C extension. The language's whole implementation and performance-sensitive libraries are all C. Contrast this to modern languages where it's an embarrassment if your compiler is _not_ written in the language itself (Rust, Go, Swift, etc.).
* Core build infrastructure (Bundler) and environment management (rbenv) is maintained separately from the language. It works fine, but the reason it's not more core is not because it's better that way, but because the language's original designers didn't realize they'd be necessary, so they had to be developed separately. This has the effect of making the whole toolchain complex and hard for beginners to understand because none of it is integrated.
* The interpreter starts out faster than a compiler, but it breaks down fast. Codebases in the 100,000s of lines or more will take on the order of 10-100 seconds to start up, and the only way to get back to a fast edit-compile-debug loop is through tricks like Zeus. After you resort to that, unreliable runs and weird loading problems become a part of common life.
These aren't small problems. Also, I'm picking on Ruby here, but you could drill into a lot of existing languages and find flaws that are roughly on this level (JS/Python/C++/Erlang are easy, but even fan favorites like Haskell and Scala have pretty serious ones). Newer languages have their problems too, but rarely anything on this sort of existential scale.
We should stop pretending that all languages are equal with their own share of upsides and downsides. Given decades of language building, it would be disappointing if lessons hadn't been learned. Luckily this isn't the case.
In terms of what we write new projects in given a few years, there are other good contenders, but like I said above, I think that Rust has nailed a performance/safety/productivity/ecosystem compromise that's quite a bit above and beyond most of anything else.
Anyway, I was around for this kind of talk when Java was new and shiny, and there were people in the Java community claiming that Java was the future for programming, and any languages in the future would target the JVM or be phased out. That didn't happen, even though Java did well for itself.
What's really telling is that Java didn't replace C/C++, despite all the hype back then. Those two languages remain widely used.
There is an absolutely enormous amount of Java out there.
https://www.tiobe.com/tiobe-index/
That's what is being claimed above, and what some in the Java community were claiming in the 90s. Also, probably some in the Javascript community these days.
But it's never happened. If there was the One True Language to rule them all, then Lisp, C++ or Haskell would have done it by now.
The point with Java is that even though it was targeting the C/C++ crowd specifically, and it became widely popular, did not cause C/C++ to die.
Again, who is claiming this? Can you link me?
If you want to argue with some several post up, please go several posts up. If you want to argue against me, than please do so on the merits of what I said.
The remaining 20% are stuff like device drivers or high performance libraries that are easier to write in C or C++, or legacy MFC applications.
Also if you look at operating systems like Android, Google makes it very explicit that you need a very good reason to down into the NDK dungeons, to the point that the set of allowed libraries only cover the use cases of 3D graphics and bringing native libraries into Android.
Likewise when Android Things was still called Brillo, the plan was to re-write the Android Framework in C++, instead they ended up bringing ART into Brillo.
Citation needed. Just because static typing is has been more fashionable for the past 10 years, doesn't mean it's a closed case. Before that people were extolling the virtues of dynamic languages.
Some people deciding they prefer static typing doesn't constitute some kind of consensus or fact.
I've worked with very big duck typed codebases for quite a few years now (and largely statically typed in C# before that) and the above is my opinion. Duck typing is convenient early on, but it makes understanding code (especially where it gets complicated or you didn't write it) quite difficult, and any kind of refactoring downright scary. After a point you (1) start getting hugely defensive with tests because without close to 100% coverage you just can't know if anything works, and (2) stop making big changes and instead accept that small incremental deployments towards a greater end is the only safe way towards making progress.
I suspect that how much you agree with this statement is strongly correlated to the size of your codebase. I'd be surprised to meet people with codebases on the order of 100k lines or greater that don't largely share this sentiment.
I'll admit, my commercial experience has all been in statically typed languages. But there are a lot of complex, well written pieces of software written using dynamic types. Maybe you don't meet their proponents, but they do exist.
FWIW, I quite like static typing, but I consider it a feature, not a religion.
https://drive.google.com/file/d/0B0cKsRm-3yprYTR5YTRaRFBfR28...
He said they mostly just test everything at the interfaces. However, it's simplicity also allowed for powerful tools in code generation, refactoring especially, and so on.
I like testing as much as the next person and consider it very important, but your tests should be testing business logic rather than whether your syntax is correct. The problem with dynamic languages is that while you're certainly doing the former, you're also doing way too much of the latter. Until you hit runtime, you have no idea whether you misreferenced a variable or invoked a method that doesn't exist, so you end up writing an exaggerated number of tests that are repetitive, slow things down, and end up requiring considerable maintenance.
> (2) is true for pretty much every large statically typed codebase I've worked on.
Yes, incremental deployment is always a good idea, but it's a matter of degree.
Take for example a case where I need to rename a method that's widespread throughout the codebase. In a static language, I wouldn't give this a second thought. If there's a problem my compiler will catch it, and that's the end of the story.
In a dynamic one, this is a dangerous operation: the old method name may still be getting invoked dynamically in a non-obvious way, or another branch may have been merged _after_ I branched but _before_ I deployed that still has an invocation of the old name. Hopefully you have tests on these paths that will reveal the problem, but you might not, and to hedge against that possibility, you have to roll the change out to production carefully and slowly (because even there, it might be some time before some unwitting user inadvertently triggers the bad flow).
I think what you really want here is fast compiles and iterations. You can do that without a REPL if using a language that compiles ultra-fast. Industrial BASIC's I used a long time ago compiled in a split second with me seeing the results immediately. Wirth-style languages tend to be able to do that. I hear Go compiles really fast. The wait doesn't really matter at that speed. Highly-optimized, slower compiles and tests can run overnight in background on dedicated machine, too.
Am I the only one who sees this as pure BS? Some people like REPL's, and that's cool. But not everyone. I find it utterly annoying that in any REPL I've ever used I first have to import (or similar) the libraries I want access to in that repl environment. You end up generally writing a file to do the imports for you, or cutting and pasting.
With all that effort I almost always find it easier to just write a test-case, even in languages with a REPL. At that point I have a repeatable and testable piece of code that can be run, with almost zero error due to the REPL environment not being setup properly.
Please point to a single place where anyone has ever said this. We have never positioned Rust as an end-all be-all language: it's a language that deliberately makes compromises in order to excel at a niche.
Right now, I don't do much serious work in Rust, almost solely because of compilation speed.
If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).
Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman?
I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.
This is already true today; that is, this cost is only paid the first time you compile. It's still not fast enough for people.
On my machine, a fresh build of rustc takes an hour, and small changes take 20 minutes, and even that makes it a giant pain. It's an ergonomic thing, IMO.
A bit influenced by the fact that rustc has to compile itself three times. :P
https://edn.embarcadero.com/article/20803
And even today Delphi 10 is quite fast.
Same applies to many other compiled languages with modules.
And no where near as fun. Hilarity ensued when I didn't realize there was no garbage collector.
Turbo Pascal was more a kind of simplified Ada than a pure Pascal, which made me look down on C when checking down the laundry list of language features of Turbo Pascal 6.0 versus ANSI C89 in 1993.
Also by 1999 no one was doing anything serious in Turbo Pascal with the last version being targeted at Windows 3.1.
Delphi 1.0 was released for Windows 95, and it did at least have some kind of GC for COM based classes.
Also Delphi 10 might not have every Rust feature, but it surely has it own set of complex language features.
Or if you prefer Ada, C#, D are also possible sources of information regarding performance of compilation toolchains, with relatively complex languages.
I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times it's worse.
To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.
Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air).
I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath<T> and AsRef<T>, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)
I always thought `cargo new` should have been called `cargo cult`.
Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse?
http://androidbackstage.blogspot.de/2017/04/episode-64-gradl...
https://www.youtube.com/watch?v=BKRK4SvMtRk
The Android Gradle plugin being slow as molasses is a typical discussion theme at Google IO since it was introduced. Being partially written in Groovy also doesn't help.
On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time during development or after updating dependencies.
For me, the compile times are fine, and the end product generally doesn't need as much debugging as an interpreted language that requires no compilation at all, or has minimal validation, prior to running.
I think the user experience is more important than the developer experience. Using shared libraries that are likely already in memory provides a better user experience because it's faster, more stable, more secure and uses less memory.
The cargo approach will end up with windows/node level bloat where every app bundles half an OS.
Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. All those other languages also have packages provided in many distros, but the developtment tool listed that downloads and installs relevant packages is also used when appropriate. For the regular, non-developer user that needs a module to support some program, that may be never. For the developer working in those languages that needs the newest version of the package, regardless of the back-patching policy of their distro, that may be often.
As I said, rust is meant to be a systems language, it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
It's meant to useful as a systems language, so was designed with certain constraints in mind. It is whatever people want to make of it. There have been plenty of instances I've seen on HN alone of people mentioning use that isn't specifically tailored for a systems language.
> it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
Those are entirely orthogonal issues. Cargo works with the system just as well as tar and make. They're just binaries. You could just as easily say that traditional source tarballs shouldn't be provided because people might download the source and use their compiler to build instead of using the distro package. This is a non-issue. The only people that will even have the choice are those that chose to install the compiler (whether it be a C compiler or Rust), and even then the vast majority that actually do so will probably end up having a good reason for doing so.
Cargo is part of the build tool chain. Just because it can be used to distribute a package, and even while it probably will be used to distribute a package, that doesn't mean it's purpose is to do so, or that it's inappropriate that it exists. Any feature can be abused. You should not judge it by the abuse, but by its intended and common use.
Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well.
If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious.
After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well.
I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.
Compiling the whole world, including dependencies is big waste of time.
I already tried to play around with workspaces to see if at least crates only get compiled once.
With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.
This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search.
Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)
Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager.
> If you're pre-building something and pushing a package for say dpkg or rpm
The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities.
> Should an OS want to bless crates, cargo does have an override for crates.io
That's a recipe for dll hell if I've ever heard one.
most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue.
If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you believe it's doing it wrong, but every package manager for every OS out there does things differently, Rust can not fix this.
> That's a recipe for dll hell if I've ever heard one.
The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there, with the cargo manifest used to generate the various package managers dependency graphs as necessary. This would probably look a lot like, or actually be an integration with, FPM.
Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app.
> I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there
Basically, but more to the point, when a bug or security issue is fixed I don't want to rely on individual programs updating their dependencies. Let's say 10 years from now the rust version of gstreamer is widely used and a security issue is discovered, I want to be able to "apt-get upgrade" and know that it's patched. This is how things work now with the c version, but this can't be done with cargo, every app using the library has to update it's dependencies and many (particularly any corporate ones) will never update. Rust might be a boon for security but cargo could undermine the effort.
Aside from that, static linking creates a tonne of bloat, memory and disk. There is a reason windows apps are often so bloated compared to their linux counterparts.
> The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I don't think that's good enough, if rust wants to be a systems language then it has to work with the system, not be a layer on top of it like java/.net/node. It can do this technically, but culturally it's looking more like node and less like c.
If I'm installed zlib for general system use, I want a package manager. If I'm installing a Rust compression library to be compiled into the program I'm working on, I want that to be managed by my build chain (especially since the version I'm using in my build may not necessarily match what I have installed on my system to run).
As another example, if someone makes a cook general purpose library using Rust, eventually it should be packaged up and shipped in the normal distro package format by the distro if it's useful. I wouldn't expect cargo to be the normal way to distribute software. It's the Rust equivalent of the old tar -zxvf package-1.2.3.tar.gz && cd package-1.2.3 && ./configure && make && make install. You can do it, but if you have a distro package, use that first.
To be clear, neither does the Rust team. You're exactly on point here.
From the getting started chapter of the rust book (which I believe you wrote?). That implies that rust can't be used without cargo right there. And I'm not seeing any libraries published as ubuntu packages.
After this conversation I thought I should expriment more with rust and it's linking options and quickly ran into an error of some sort (quite possibly a system one) trying to buils hello world with dynamic linking:
http://stackoverflow.com/questions/44012802/rustc-and-prefer...
> That implies that rust can't be used without cargo right there.
rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year.
Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. It's like the difference between Make and pbuild or a similar tool; see the parent comment about "./configure && make" vs a system package.
> And I'm not seeing any libraries published as ubuntu packages.
Debian has an entire tool, https://crates.io/crates/debcargo, which automatically re-packages a Cargo package into a .deb. Currently, they only package the Rust compiler itself and Cargo, but this work was done specifically so that programs in Rust could be included in the distro, but packaged the way distros like. They've mostly been working on that stuff; I assume by the time Buster's cut-off date happens, there'll be some stuff; I'd like to see ripgrep, personally.
I haven't used -C prefer-dynamic in a while; usually SO questions get answered relatively quickly though.
The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installation section of ripgrep (http://blog.burntsushi.net/ripgrep/#installation) "cargo install ripgrep" is an installation option.
And because static compilation is also a distribution mechanism (just not for the end user) the binaries are 10 times larger than grep, not to mention a giant GPL trap for commercial users.
Please don't misrepresent my writing. `cargo install` is NOT the primary distribution mechanism for ripgrep. The installation section starts with instructions that use standard system package managers, and only then suggests installing it using cargo if you're a Rust programmer. Why did you leave that out?
You might also consider looking at the actual README of the project[1], which lists several more installation options, including using brew, chocolatey, pacman, emerge, dnf, yum and nix. There is clearly an effort to suggest that users install ripgrep using their standard system package manager.
Some of the points you've made in this thread are valid concerns, but please don't misrepresent other peoples' hard work while you're doing it. It's extremely rude.
[1] - https://github.com/BurntSushi/ripgrep#installation
Build tools like Maven and Gradle, as well as IDEs' internal build tools, will be smart and compile only the changed files.
Also a bit disappointed when compared with other languages that support modules, specially the ones whose toolchains support binary dependencies.
Not everyone has a high end development workstation.
I am however confident the experience will eventually improve.
Compilers are pretty hard. Languages like C and Go are able to short circuit the problem by having a simplistic type system, but the Rust team's main option here is hard work, and so far they seem to be more than willing to engage in it.
> At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse.
Citation needed on that one. How can you even make that kind of comparison fairly?
For all I know, that might be true, but it's one of those "citation needed" type things.
But I do take advantage of all VC++ improvements for fast C++ compilation, even playing around with the ongoing research work for C++ modules.
It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD.
On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5 minutes.
Lack of incremental compilation and cargo not being able to deal with binaries dependencies has putted me off, after all if I want slow builds I can have them already in C++ when I go template meta-programming craziness, which are not that slow when using the experimental work Microsoft is doing with C++ modules.
Also since our use of C++ is constrained to libraries used from Java/.NET/Android/iOS, the build times are usually relatively fast.
Hard to sell Rust to anyone on the team, if that means their workflow would become slower, in spite of the safety improvements over C++.
I'm used to ~100kloc of C++ taking half an hour per config+platform on a 4-6 core, 16GB+, SSD machine. Less hygenic than your codebase sounds like, but with some beefy PCHs. Toolchain updates are usually a full day affair in this context, although that's not entirely from just the compiler bump.
Of course, incremental vs full rebuilds are no contest. Rust is at least working on incremental builds now that they have MIR AFAIK. And binary cargo support would be really nice as well. As would be compiling in general.
Cite a source? This isn't my experience at all, Rust is still way faster at compilation than C++ on average. The advantage that C++ currently has is ccache which helps avoid needless rebuilds (which pairs well with C++'s smaller compilation units relative to Rust); building this behavior into the compiler is part of what the incremental compilation initiative is addressing.
> It consists of ~7700 lines of Rust
...
> Compile times with Rust are Not Great. This is easily my single biggest gripe about Rust right now. The build for A Snake’s Tale takes 15+ seconds, which makes iterating rather tedious. The current incremental compiler work also doesn’t seem to make the build for A Snake’s Tale’s codebase any faster.
Actually, the compiler isn't the bottleneck - most of the time is LLVM codegen. So 'cargo check' is fast - the miri MIR interpreter likewise.
Why?
Because returns from startups are exponential and the interest rate is higher than the interest rate on the technical debt.
It's why compiled is a great choice for an established corporation with a well defined need and a large user base, while interpreted is better for most other business contexts, especially with tools like Numpy.
https://usehelix.com/
I'm still not sure what the best way of doing things is. I tend to think that Rust is going to be the programming language of tomorrows operating system, but I'm not sure if it is going to get the wide library support of something like Cython, since the scientific community isn't as fractured as the software community. Tools like graph-tool / scipy / etc are hard to live without.
Like, they _are_ making a lot of progress, but because of the amount of time spent on developing/informing the community and other non-implementation pieces it feels like a rocket ship rather than "just" a well executed project.
I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting.
Here are a few that I think about personally and which are probably a little more unusual to see:
* Batteries not included: the standard library's been pretty stripped down in favor of moving things out into external crates. The justification is that packages included in the standard library tend to ossify and become liabilities as they outlive their usefulness [1]. I buy the argument, but am a little worried that it's going to result in a fractured ecosystem where even extremely common functions like HTTP don't have "one true path" so we get a dozen different packages that try to handle it.
* Tunnel vision focus on Tokio: to my eye the community seems a little obsessed with Tokio and zero-cost futures. It's really nice how performant it is, but I'm not crazy about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`). I think that for most cases where performance is not an absolute mission critical necessity, a light runtime that manages asynchronous operations for you (say like Go's) is probably the way to go because it unlocks far better productivity. I'm cautiously optimistic about the possible inclusion of something like an `await/async` construct.
[1] https://blog.rust-lang.org/2017/05/05/libz-blitz.html
How is that more boilerplate than any other way to have concurrency?
To give one specific example, WinRT uses futures, and there you can write async code that flows from C++ through C# to JavaScript and back, with mapping to a common ABI type done transparently at the interop layers (https://docs.microsoft.com/en-us/uwp/api/windows.foundation....).
If and when we standardize on a higher-level ABI that includes fibers or something similar, then the other approach might make more sense. Of course, the problem is that there isn't a single consensus design to standardize on...
Is there another survey more suited to use Rust as a language ala "State of Clojure"? I don't use Clojure anymore but I still love reading these every year to keep up to date with the progress it's making.
For ex: http://blog.cognitect.com/blog/2017/1/31/state-of-clojure-20...
Edit: Oh nevermind, it seems the questions change if you select 'Yes' or 'No' at the beginning for "still using Rust". I didn't totally stop using Rust I just spent time learning it, experimenting on some projects, but I don't have a day-to-day need for it - not sure if either possible answer applied to me.
Edit: fixed.
That's utter nonsense.
I think you're mistaken "de-facto standard" for "standard". They are not the same thing, and whether brotli actually is a de-facto standard is debatable, but it's not the standard.
It's perfectly acceptable to do whatever you want with your own web stack and application. You wouldn't be getting much pushback if you simply justified it as "It's what I want to do", but you are providing evidence that is factually incorrect, where no evidence is really required.
Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.
Actually, if you look at the top level comments that I've made, that's exactly what I said. What I'm getting in response to that is that I'm basically 'breaking the web' because I don't want to comply with sniffing request headers and offering gzip to Apple WebKit users. If I don't care about supporting your web browser, then I don't care about supporting your web browser. You can't make me.
> Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.
That kind of security isn't a concern to me. Not having compression at all would take a larger toll on my bandwidth, and increase latency of page delivery. Bandwidth isn't free.
wget and curl both also fail to decompress your site's contents.
Same problem in netsurf, lynx, and links.
> wget and curl both also fail to decompress your site's contents.
I'd consider this a good thing, actually.
And it's not just Safari. I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Safari sends the Accept-Encoding header with a value of "gzip, deflate". If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.
> I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec.
Again, I do not support HTTP! The website is HTTPS-exclusive. HTTP is basically a legacy protocol at this point. Every website should be encrypted.
> If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.
I may do just that then.
You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really don't care about software you don't use, then why are you so dead set against serving up uncompressed content to that software?
> Again, I do not support HTTP!
You completely missed the point. I know your site doesn't support HTTP. But HTTPS is generally understood to be part of the umbrella of "HTTP". It is in fact literally the same protocol (well, for HTTP/1.1; HTTP/2 is a brand new protocol and irrelevant for this discussion), just wrapped in SSL.
> I may do just that then.
Just so we're clear, your site currently does not work, and will continue to not work, with tools like `curl` or `wget`, or nearly all other non-browser tools people have written.
I'm not sure where you think the contradiction is. That I do not support web browsers that don't support Brotli should already tell you that I don't care if they support Brotli or not! If there is no support, there is no support! Doesn't effect me.
> You completely missed the point. I know your site doesn't support HTTP. But HTTPS is generally understood to be part of the umbrella of "HTTP". It is in fact literally the same protocol (well, for HTTP/1.1; HTTP/2 is a brand new protocol and irrelevant for this discussion), just wrapped in SSL.
Basically completely irrelevant to what's being discussed here. I do not support non-SSL HTTP connections. That is all!
> Just so we're clear, your site currently does not work, and will continue to not work, with tools like `curl` or `wget`, or nearly all other non-browser tools people have written.
Naturally. I would prefer to not have anyone using these tools on my server.
You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed responses. You had to modify it to add always-on Brotli encoding.
> I do not support non-SSL HTTP connections.
Why do you keep repeating this? That's completely irrelevant to the discussion at hand. Nothing about this discussion has anything to do with whether or not the HTTP protocol is wrapped in SSL.
> Naturally. I would prefer to not have anyone using these tools on my server.
So, you want a web site that completely breaks HTTP such that only works with a handful of browsers and doesn't work with the probably tens or hundreds of thousands of pieces of other software that speaks HTTP.
Why?
I did not have to go out of my way to 'break support for these browsers'. All I did was replace the gzip-compression code in my page cacher with brotli-compression code. In other words, I went from always-on Gzip encoding to always-on Brotli encoding! I have never supported serving uncompressed files! The web browsers I care about (Firefox, Chrome) support Brotli, and that's all I care about! There is no purposeful breaking of web browsers. That's just persecution complex talk.
> Why do you keep repeating this? That's completely irrelevant to the discussion at hand. Nothing about this discussion has anything to do with whether or not the HTTP protocol is wrapped in SSL.
You're the one that keeps bringing up that the only difference between HTTP and HTTPS is that HTTPS is HTTPS with SSL. I am merely responding to your comment that your comment about them doesn't matter! What does matter is that my website only supports the HTTPS protocol, not HTTP. The web server only listens on port 443 with TLS enabled.
> So, you want a web site that completely breaks HTTP such that only works with a handful of browsers and doesn't work with the probably tens or hundreds of thousands of pieces of other software that speaks HTTP.
This is nothing more than pure trolling. All major web browsers support Brotli over HTTPS. Apple's WebKit is the only man out, and they are, at best, a minority on the web. Firefox supports it, Chrome supports it, and Edge supports it. Even if Edge didn't support it, the fact that Firefox and Chrome support it is more than enough for me. Other browsers are just bonuses.
Furthermore, yet again, I do not have a HTTP server, so there is no HTTP here to break! HTTPS is implemented to spec, HSTS headers and all! My website is meant to be viewed by people, not machines. In addition, as the web is moving to being HTTPS-exclusive, it's about time that you start getting used to it. You're wasting your time.
> What does matter is that my website only supports the HTTPS protocol
No, that has literally no bearing on this discussion about your use of Brotli encoding. You're weirdly fixated with this, but it's completely irrelevant.
> This is nothing more than pure trolling.
Do you normally go out of your way to insult people who are trying to have a discussion with you? Because that's what calling someone a troll is.
> All major web browsers support Brotli over HTTPS
Why doesn't Safari count in your eyes as a major browser? Or perhaps more interestingly, why doesn't iOS Safari count? Are you really ok with your site not working for 100% of iOS users?
> In addition, as the web is moving to being HTTPS-exclusive, it's about time that you start getting used to it. You're wasting your time.
Why do I have to keep repeating this? HTTPS has literally nothing to do with this discussion. You keep bringing it up over and over again as if it's somehow meaningful, but all it tells me is that you literally have no idea what you're talking about.
https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
> > Important note: Brotli availability is restricted to HTTPS connections.
You Cannot Use Brotli Without HTTPS. Chrome does not support this, and Firefox does not support this. The same goes for Edge. One of the major reasons for me moving my website to HTTPS is so that I could use Brotli compression. Otherwise, Firefox and Chrome will merely get a content encoding error page because br is an unknown encoding format when using HTTP! HTTPS is required, and Google engineers are telling you this themselves. You're wrong, and Google engineers are right. End of story.
> Why doesn't Safari count in your eyes as a major browser? Or perhaps more interestingly, why doesn't iOS Safari count? Are you really ok with your site not working for 100% of iOS users?
I do not care if iOS users using Safari are unable to access my website. In the same way that iOS app developers do not care that Android users cannot use their apps, I do not care if iOS users using Safari are unable to access my personal blog. My target audience is not iOS users. My target audience consists of Linux users using either Chrome or Firefox.
So basically, you have tunnel vision and are just here to bicker and argue senselessly about things you don't understand or are unwilling to accept. I'm not sure why you're so upset that I have decided to not support your access to my personal blog. No matter how many times I explain things to you, you never seem to get it through your head. This is my website, not yours. I will not support gzip, and I will not support uncompressed content, nor will I support tools that only work with HTTP.
> One of the major reasons for me moving my website to HTTPS is so that I could use Brotli compression.
Why do you care so much about this particular compression format?
> Otherwise, Firefox and Chrome will merely get a content encoding error page because br is an unknown encoding format when using HTTP!
You clearly did not test this, because Chrome interprets Brotli responses just fine over HTTP. I wager Firefox does too, but I'm not about to install Firefox just to test.
> You're wrong, and Google engineers are right. End of story.
Google engineers are right, but you are not right. You don't understand what the Google engineers are saying. The link you provided specifically has to do with the Accept-Encoding header and not Brotli support as a whole.
> My target audience consists of Linux users using either Chrome or Firefox.
I still don't understand why you're intentionally breaking the open web. It makes no sense.
> No matter how many times I explain things to you, you never seem to get it through your head.
You should try actually listening. You keep explaining things that are factually wrong or completely irrelevant. You seem to not actually understand HTTP, HTTPS, Content-Encodings, or even the idea of the open web in general. And you're going out of your way to break 99% of tools out there for no discernible reason. Why do you love Brotli so much that you're willing to break HTTP just to use it?
> You clearly did not test this, because Chrome interprets Brotli responses just fine over HTTP. I wager Firefox does too, but I'm not about to install Firefox just to test.
This is just willful ignorance on your part. I have already tested this, and it is partially why I moved towards implementing HTTPS. The web is full of resources to back this up: https://encrypted.google.com/search?hl=en&q=Brotli%20require...
> Google engineers are right, but you are not right. You don't understand what the Google engineers are saying. The link you provided specifically has to do with the Accept-Encoding header and not Brotli support as a whole.
You don't seem to understand what you think you understand. Accept-Encoding means that it will not publicly state that it supports Brotli. I wonder why that is..... because Brotli is disabled for HTTP connections. End of story again! Stop beating the dead horse! You are wrong.
> I still don't understand why you're intentionally breaking the open web. It makes no sense.
I don't understand why you think I am. If anything, you are merely trolling and wasting your time.
> You should try actually listening
I've listened and listened, but you aren't speaking anything worth listening to. You yourself refuse to listen to my point of view and explanations, so why should I bother listening to your BS?
> You keep explaining things that are factually wrong or completely irrelevant.
I have done nothing of the sort. You, however, are stating that Brotli works over HTTP. This is factually incorrect. It is not allowed.
http://www.omgchrome.com/brotli-http-compression-coming-to-c...
> Be aware that while the compression algorithm is designed for HTTP content encoding it currently only works over HTTPS.
https://samsaffron.com/archive/2016/06/15/the-current-state-...
> Brotli is HTTPS only > > If you visit a site over HTTP your browser will not accept the br encoding. The reasoning for this is documented at the end of the chromium issue.
https://ayesh.me/apache-brotli
> 'm not sure if there is a technical reason behind this, but all the browsers I tested with require HTTPS in order to enable Brotli support. I have written a small post about more reasons to switch to HTTPS as well.
You are basically calling Google and each of these authors that I've linked as liars as we all have tested Brotli over HTTP and HTTPS and can concur precisely what Google and Mozilla engineers stated: Brotli is only supported with HTTPS!
> And you're going out of your way to break 99% of tools out there for no discernible reason.
First you said it was 40%, and now you are saying it's 99%? Both statistics are bogus given that around 80% of users are using either Chrome or Firefox, and versions that support Brotli!
And going out of my way? I already explained to you how I did not go out of my way. I am not targeting anyone. It was only a few lines of code to change my content cache from being Gzip-backed to Brotli-backed. You just have a persecution complex. I actually had to go out of m...
I really do not appreciate you continually calling me a liar (since I've told you in no uncertain terms that I personally have tested this behavior), especially since all you're doing is an appeal to authority ("Google engineers!") based on a misunderstanding of the issue at hand. You keep claiming you have "evidence", but all your "evidence" proves is that you need to work on your reading comprehension skills, because those pages do not say what you think they say.
> You are basically calling Google and each of these authors that I've linked as liars
Let me try this again:
YOU DO NOT UNDERSTAND THIS ISSUE. YOU DO NOT UNDERSTAND HOW CONTENT ENCODINGS WORK OR WHAT EFFECT HTTPS HAS ON BROTLI. I AM NOT CALLING THEM LIARS, I AM CALLING YOU INCREDIBLY IGNORANT.
I am done with this conversation. I am not going to respond to any more of your comments. You don't understand basically any part of what's going on here, but you think you do and you won't even acknowledge the possibility that you are wrong. You're also misinterpreting nearly everything I say, because you're not actually reading my damn comments, you're just skimming them looking for things you can argue against. Case in point, your sentence that starts with "First you said it was 40%"; I was talking about tools that speak HTTP, which was extremely clearly from context, and you're completely misinterpreting that as browsers, and what's more you're even putting words in my mouth (literally nowhere did I say 40%).
That is a serious breach of HN's civility rule and the sort of thing we ban people for. When someone is provocatively repeating wrong statements (or appears to be) and is getting increasingly rude, the way to deal with that is not to lose your own cool, it's to realize that there's no win in this and just leave it.
A.k.a. don't feed the trolls, it takes two to tango, two wrongs don't make a right, and sundry other things our mothers told us.
This is the sort of argument that gets a few combatants hot and bothered and clogs up the site with tedium for everyone else. We ban accounts that do this, so please make sure it doesn't happen again. HN threads are for good conversation, and there's no worse conversation than this kind of bickering.
I also don't depend on my blog for food. But I do care and if this were a customer project or something commercial you'd be dead in the water. That's a friendly way of saying that your opinion on what is 'standard' really doesn't count for much with me. You've polluted this thread with I don't know how many comments essentially shouting down each and every patient and restrained effort to teach you something but you won't take a hint.
You are, in fact, right. But I advise you to read about HTTPS here, so you can more clearly understand the points others are making: https://en.wikipedia.org/wiki/HTTPS.
That says it all really. Unfortunately it also seems to be a common attitude in the rust community.
Something doesn't become legacy just because a newer option has been available for a year.
Eh, maybe in some segments, but I don't think that's the majority culture. See https://github.com/rust-lang/rfcs/pull/1985 for something extremely relevant to the discussion here, heh.
Also, you don't seem to understand. I'm not telling you to support gzip. If the browser doesn't support Brotli, then just send back uncompressed content.
And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.
> And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back.
My website does not support HTTP. HTTP is basically a legacy protocol at this point. My website is HTTPS-exclusive. It does not listen on port 80. That Brotli doesn't work through HTTP is not surprising, given that HTTPS support is a base requirement for Brotli support.
Yes, I said HTTP instead of HTTPS, but that wasn't meant to signify that I was using unsecured HTTP, since HTTPS is supported virtually everywhere and generally understood to be a part of HTTP. More specifically, if I actually try and access http://mmstick.tk, I just get redirected to https://mmstick.tk anyway, without having a content body, so it's not even possible to get Brotli-encoded data out of your server over HTTP. And if I run `curl https://mmstick.tk` then I get garbage, which was the whole point of that sentence and what you still haven't even addressed.
Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP.
Attempting to access the site via HTTP will merely redirect you to the HTTPS service. Nothing is being hosted on the HTTP service. When you reach the HTTPS service, your browser will receive a HSTS header that will cause your web browser to automatically direct to the HTTPS server and not touch HTTP at all for future requests, ever. Nor can your connection be downgraded to HTTP.
> Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP.
Tell that to Google, Mozilla, and Microsoft. You cannot use Brotli compression over HTTP. Only when you are using the HTTPS protocol can you use Brotli. And in general, if you support HTTPS and are using an update browser, you more than likely already have support for Brotli today.
> You cannot use Brotli compression over HTTP.
This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Brotli-encoded response over unsecured HTTP.
My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.
I highly doubt that you actually tried this in practice. You are merely assuming that it works. For Google to overturn their decision would fly against all reasoning for the decision in the first place.
> My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.
You seem to not have any experience with Brotli support and why the decision was made to only support it over HTTPS. One such comment that outlies the reasoning is from a Google employee themselves ( https://bugs.chromium.org/p/chromium/issues/detail?id=452335... ).
Hence, all vendors have followed suit and are not implementing brotli for HTTP. SSL prevents all the middle man infrastructure in place from employing such tactics that would break websites serving content with the br content encoding. There still exists much infrastructure in place that snoops HTTP traffic and, when it is detected that the content encoding is an unknown format (brotli), it will compress the stream with gzip and change the content encoding to gzip, thus breaking the website.
In addition, yet again, Google engineers clearly state that Brotli support is only available over HTTPS connections!
https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
One of the big reasons for my decision in pursuing HTTPS support on my personal blog was so that I could, in fact, use Brotli. I already had the code in place, but enabling Brotli on my web server would merely give errors about the content encoding being unknown, and as you will notice, br is missing from the list of available accepted encodings by the browser! Yet it is there when connecting via HTTPS! That's because Brotli is completely and utterly disallowed over HTTP! Google engineers stated it themselves. You can't have it both ways.
I told you explicitly that I tested it. Now you're calling me a liar. I am not "merely assuming that it works", I actually tested it to the point of controlling the exact bytes that the server sent to the client using a hand-constructed HTTP response and then pointing Chrome at that server.
> For Google to overturn their decision …
I just looked into the specific behavior here. Here's what I found:
* If you point Chrome at localhost, it includes "br" in the Accept-Encoding header.
* If you point Chrome at some other domain using HTTP, it does not include "br" in the Accept-Encoding header.
* Either way, if the server actually returns a Content-Encoding of "br", Chrome will respect it.
So basically, Chrome always supports Brotli-encoded responses. However, it only requests Brotli over HTTPS and doesn't request it over HTTP, and the only reason for this distinction is to avoid middleware servers from mucking with Brotli-encoded pages that they don't understand.
> It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS.
Again, you don't understand what you're actually reading. There are two parts to Brotli support. The first is whether the browser will declare that it supports Brotli. This is the Accept-Encoding header. The second is whether the browser will actually correctly interpret a response encoded as Brotli. HTTPS only affects the first part. Chrome only declares to the server that it can accept Brotli when sending an HTTPS request and not when sending an HTTP request. But if the server ignores the Accept-Encoding header and hands back a Brotli response anyway (like your server is doing), Chrome will handle that exactly the same way over HTTP as it does over HTTPS. Because it's just a content encoding, and there is literally no reason to make the code that handles content encodings care about HTTP vs HTTPS.
> Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story.
Please try testing this, because I promise you this is wrong. Switch to HTTP and if the server returns a Brotli-encoded response (with the Content-Encoding header set correctly) Chrome will still decode it. The only thing HTTPS controls is the contents of the Accept-Encoding header and not the actual behavior of the response decoder. I have tested this multiple times against Chrome 58.0.3029.110, using both localhost and a remote server. You clearly have not, and in light of this your final sentence is particularly ironic.
You are right in that brotli decoding is only supposed to work in secure contexts (so technically not just HTTPS, btw -- localhost is also considered a secure context, see https://bugs.chromium.org/p/chromium/issues/detail?id=624426).
Eridius is right in that it currently does work over insecure HTTP in Chrome, as confirmed in this open bug: https://bugs.chromium.org/p/chromium/issues/detail?id=579606 -- in which one Chromium dev comments "Decoding brotli even if it isn't requested is both bug and feature. It allows developers to test brotli without setting up https serving." Seems like they concluded that it is indeed a bug, however.
Reality and specifications often diverge...
(I do think not supporting gzip is absolutely bizarre, but that's another issue.)
What about serving up an error page when the user's browser odesn't have compressor you support?
What about paying attention to web standards?
What about people who are stuck with old software for one reason or another?
I have limited bandwidth. I don't want to serve uncompressed content over HTTPS.
> What about serving up an error page when the user's browser odesn't have compressor you support?
I will do that once I figure out how to get the Request header from Rocket's API.
> What about paying attention to web standards?
I'm already complying with HTTPS web standards. I'm even pending for the HSTS preload list ( https://hstspreload.org/?domain=mmstick.tk ).
> What about people who are stuck with old software for one reason or another?
That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable.
You wouldn't host a page if you didn't want to share its content, doesn't failing to do so make it atleast partially your problem?
You are ignoring the list of encodings the client gives you, you are paying attention to some and not all. If we all did the web wouldn't work.
Maybe they have good reasons, you aren't them and you don't know their situation. But you have chosen to not share with people with tech older than one year...
Step back, and try to take an objective look at this. Do you know what percentage of web browsers actually in use will work? Do you know what percentage of people visiting your page see only gibberish?
Finally, Why are so many of your comments in the gray and everyone else's not in the gray? Why do so many of your technical peers disagree with you?
The current release of Firefox is only 53.0.2. If you need 52 to view a site, you're overdoing the new features.
You repeatedly posted uncivilly in these comments. That's a bannable offense on HN, so please don't do it again, regardless of how wrong you think others are.
Completely lost track of what thread I was reading.
One of these years we might implement a "More" link at the bottom of threads so you have to go to a second page to see them at all.
I am using Firefox 53.02 on Linux, and my browser is sending this request header:
Accept-Encoding: gzip, deflate, br
As far as I know Firefox fully supports brotli compression. Any idea what is wrong?
All the interesting bits are Rust :)
AgiData built a MySQL proxy [2] out of it... They manage sharding MySQL servers for enterprises. They claim their working it into production.
[1] https://github.com/jwilm/alacritty
[2] http://www.agildata.com/building-scalable-mysql-proxy-rust/
(Dropbox has a variety of things using Rust, and IIRC some of them are pure Rust. I don't remember the details.)
[1]: https://news.ycombinator.com/item?id=11283758
I personally love that Rust is getting used to complement so many other languages (e.g. Rust's first known production use was as part of a Ruby gem). Easy integration is something to be celebrated, because it means you don't need to rewrite the whole world to get benefits.
I'm very happy to see mixing like this too!
Also, I want to plug just how fun Rust is to write once you begin to learn how it works. It's totally awesome to write fast code that doesn't segfault, especially when it comes to things where tooling in other languages is lacking, such as doing parallel data processing. Speaking of which, I'll shamelessly plug some recent results from a Buddhabrot[0] renderer I wrote[1] in Rust:
http://lelandbatey.com/projects/buddhabrot/3k--mellowish-fra...
[0] - https://en.wikipedia.org/wiki/Buddhabrot
[1] - https://github.com/lelandbatey/rust_buddhabrot/
I use Golang daily, and have been spoiled by the opinionated approach taken to solving both CPU and IO-bound workloads.
The impact of Rust on the programming safety community has grown so big that even hardcore Ada developers are getting really nervous about Rust's powerful competition.
https://groups.google.com/forum/#!topic/comp.lang.ada/H35QcY...
Although Nim and Lisp are still more productive than Rust for my use cases -- Rust really needs a convenient edit-compile-debug cycle, and also an easy bootstrap from source mechanism -- I am watching Rust's development with pleasure.
I am pretty convinced that within the next ten years Rust will not only cause a serious decline of C++ but also eat a big portion from Ada's lunch in safety critical applications.