17 ms·

And WindRiver just sent their first pull request[1] to support VxWorks as a target. Shameless plug - I made a proposal[2] to create Business Applications Worki

• wbl 7y ago
  You don't need to avoid the GC. Why not SML or the like? Why Rust?
  • jonbarker 7y ago
    It's not uncommon for up to 1/3 of usage and therefore the bill on VMs in the cloud to be consumed by garbage collection. So if you can rewrite it without a garbage collector, you can save money. A great book on this topic is "The Beast Is Back" by jetbrains. Advocating C++ in that case (written in 2015). If GC makes you more productive, that's good, but at some point rewriting things without GC makes sense.
    • icebraining 7y ago
      How much is the usage consumed by malloc/free or equivalent?
      • ncmncm 7y ago
        malloc/free are not used in modern C++. The fraction of runtime involving allocation and deallocation, at the level where they happen, is typically negligible. In servers, after program startup, it is often (and deliberately) exactly zero.
        • steveklabnik 7y ago
          They're not directly invoked, but that's still what's called under the hood.
          • deleted 7y ago
            [deleted]
          • ncmncm 7y ago
            In Rust as in C++. But the fact that the actual calls don't appear in your source code means you don't incur any programmer cost relying on them. Yet, where runtime cost would be a problem (typically, affecting latency on a hot path) it can be avoided entirely.
        • lossolo 7y ago
          > malloc/free are not used in modern C++. I think using term "are abstracted away" is better choice here. You still allocate memory, dosen't matter if it's malloc/free, mmap/unmap or compiler is doing it for you. It cost time and space. Sometimes the cost is negligible but not always, depends on application.
        • jchw 7y ago
          > malloc/free are not used in modern C++. I don’t think that was their point. > The fraction of runtime involving allocation and deallocation, at the level where they happen, is typically negligible. In servers, after program startup, it is often (and deliberately) exactly zero. This is at least slightly misleading, though. Obviously, memory comes from somewhere. You can amortize costs by not needing to allocate new pages often. Minimizing the amount of memory consumed by an application dynamically is the only way to absolutely reduce the cost. There’s lots of ways to do this, and plenty of C++ and Go software aim for “zero allocations.” However, there is still actually allocations in many softwares with “zero allocations” because they still use the stack. For deeply concurrent applications, the stack ends up being a lot of memory. If you reduce the amount of stack memory per fiber, it reduces memory usage initially, but then fibers are more likely to hit the guard page and allocate more stack. There’s strategies to reduce dynamic allocations pretty much all over (even in GC’d languages like Go.) The fact is, though, avoiding it is much akin to avoiding the GC. In Go, its actually identical to avoiding the GC. (As a note in post, I acknowledge that not every concurrent application uses fiber style concurrency, but I believe with minor adaptations this point still stands for many classes of applications. Fully avoiding OS allocations is possible, but it definitely isn’t the “default” for C++ apps.) —— This isn’t to say your point is not correct at least for some viewpoint, but it’s not actually that simple, which is absolutely worth noting.
    • stcredzero 7y ago
      So if you can rewrite it without a garbage collector, you can save money. Save money over what? It's usually a lot easier to optimize memory use than to rewrite code. Going by the 80/20 rule, 80% of the memory pressure on the GC will be created by 20% of the code. So amortize the price of the rewrite over the expected lifespan of the app. Then compare this to, let's say, the cost of optimizing 10% of the app to eliminate 40% of the memory pressure. Then, also factor in the likely rate of bugs introduced in a rewrite compared to the optimizing GC and the cost of incurring, finding, and fixing those bugs. Going by this analysis, I would suspect that in some environments where rapid iteration is key, progress is fast, and apps have short lifespans, it might be better to optimize GC instead of rewrite to eliminate it. I'd also expect that in other cases, it is better to rewrite to eliminate GC.
      • ncmncm 7y ago
        This analysis assumes that not using GC costs something. However, in modern C++ code, as in Rust code, you can root around as long as you like and not find any code outside low-level, standard libraries that does any memory management. Avoiding GC costs exactly nothing in progress or in iteration time. So, the analysis of GC overhead is always going to pit cost X against cost zero, no matter how low you manage to get X.
        • stcredzero 7y ago
          Avoiding GC costs exactly nothing in progress or in iteration time. This might be true in new development. The specific context in this discussion was rewrites. So, the analysis of GC overhead is always going to pit cost X against cost zero, no matter how low you manage to get X. Again, you're talking about new development. That's not going to fit everyone's situation.
          • ncmncm 7y ago
            OK, I get you. The problem is that whatever level of GC overhead you start with, or achieve, it will be non-zero, and its actual magnitude, including typically big cache-footprint knock-on effects that show up attributed, in perf results, to mainline processing, will be practically impossible to estimate reliably without comparing against a rewrite. So, instead, you generally have to say: we compared some similar(-ish) program Y that was rewritten and cut the number of server instances required to meet demand by 30%, 60%, or what-have-you. But, exactly for the reasons you cite, comparisons published are against performance under GC after that optimization has already been done, as much as was practical.
    • weberc2 7y ago
      C++ still needs to allocate and free memory too and for all we know naive C++ might spend more time in memory management code than a GC language.
      • ncmncm 7y ago
        There is a fair bit of C++ code in use. We have no need to guess. And, the answer is that real programs in obligate-GC languages spend overwhelmingly more time in GC than C++ or Rust. Much of this time is spent waiting on cache misses, which are hard to track to the responsible bit of code.
        • weberc2 7y ago
          Do you have evidence for this? Specifically C++ and Rust tend to be written for applications where tight control over memory is necessary and so any sample like you're describing is going to be biased by these carefully tuned C++/Rust applications. Even the standard libraries for C++ and Rust differ considerably in allocation behavior from Java or Python--these languages are conventionally designed to allocate differently, but that doesn't mean that the GC is the problem. Further, different programming paradigms allocate memory differently and the distribution of these paradigms across GC languages and non-GC languages (or whatever terms you like) are almost certainly varied. There are lots of confounding variables to control for, and until you control for them you're pretty much just guessing.
          • nicoburns 7y ago
            I think it's pretty obvious if you use these languages. A lot of things that require you to heap allocate in Java or Python (like classes!) have stack-allocated versions in rust/c++. Which means that code which avoids slow heap allocation is much nicer than equiavlent code in Java that must avoid high level abstractions. You're right that the GC isn't necessarily the issue. It's more the forced heap allocation which most GC languages come with.
            • weberc2 7y ago
  • nestorD 7y ago
    I though about it (why use Rust if your do not need high performances and can do with a GC) and the two good reasons for me would be the quality of the ecosystem (Cargo is great and you can find solid libraries for most use case) and the fact that its libraries have a strong focus on correctness that I have not found elsewhere (and that caught bugs in code that I transcribed from F# to Rust).
    • vardump 7y ago
      > ...why use Rust if your do not need high performances... Because you want better battery life? Reduce power and cooling costs? Reduce cloud service bill?
    • ncmncm 7y ago
      At the last Rust meeting I attended, people were complaining bitterly about Cargo. I didn't get what it was, exactly. But there was talk of a replacement in the wings.
      • steveklabnik 7y ago
        What “rust meeting”? There’s certainly no plans of a replacement from the Rust teams.
• stcredzero 7y ago
  enterprise software, quant and "normal" finances, taxes, and governance, the areas now completely dominated by COBOL and Java. So Java really is the new COBOL?
  • ncmncm 7y ago
    Yes. Except, of course, that COBOL is also the new COBOL. There may be more new code being written in COBOL now than ever before.
    • codesushi42 7y ago
      FAANG still uses Java heavily. Android will keep Java relevant for a long time, even after the introduction of Kotlin.
• hello_moto 7y ago
  Please don't take this personally. I think it's great that you wanted to push Rust to the area where Java flourished (by Java I'm guessing Enterprise?). I respect your passion. Personally, I never like a language that has esoteric syntax utilizing various non-alphabetical characters. Perhaps this particular aspect is what drew me to languages like Java/JavaScript. I don't mind writing "public static void" because writing code is like 10-20% (the rest is code-review, meeting stakeholders/Product Owner/PM, come up with plans, write documentations, etc) of my activity throughout a decade of my career as a Dev. There are some caveats (or rather ... personal dislike) with Java and JavaScript for example: I don't like the Closure syntax in Java and I don't like the fact that JavaScript lacks cohesiveness => People who write ES5 code do have to implement patterns specific to JS in order to re-create some of the OOP constructs. ES6 with Class/constructor/static syntax help but then they added generator via '*' (asterisk, but why? why don't use the keyword 'gen' or 'generator' just like async/await keywords?). The other thing I realized lately is that I prefer GC platform/ecosystem so that I can focus less on the platform itself.
  • sbov 7y ago
    I'm curious what esoteric syntax utilizing various non-alphabetical characters you're talking about in Rust? I recently started learning it and nothing jumps out to me as particularly egregious.
    • steveklabnik 7y ago
      There are three ways this objection is usually expressed: 1. Long ago, Rust had some interesting built in syntax for different kinds of pointers, and so people checked out Rust then, and didn't realize we got rid of it. This objection has happened less and less since that was ~5 years ago (wow time flies), but sometimes it still comes up. 2. The lifetime syntax uses a single apostrophe, like 'a. We took this syntax from OCaml (though slightly re-purposed), but if you haven't used OCaml, and many have not, it can feel very weird. 3. Not everyone prefers the "curly braces and semicolons" style of systems languages, and so they feel the <>s and ::s and {}s and ;s are noisy. We kept this style to be familiar to systems programmers. In general, Rust doesn't have a lot of unique syntax, but it does draw from two generally disparate areas: functional languages and systems languages. If you haven't used both before, some of it can feel strange. It happens.
• Thaxll 7y ago
  Rust is not "more" safe than a GC language because it has a borrow checker.
  • weberc2 7y ago
    It’s more safe than those languages because of its type system. Memory safety isn’t the only kind of safety, after all. :) NOTE: maybe the parent edited his comment between my reply and yours?
    • blub 7y ago
      I see this statement is oft repeated on HN, but no proof is offered in its support. Rust can guarantee the elimination of race conditions in low-level multi-threaded code, but aside from that there's nothing really safer about its type system compared to say Java. And one would anyways use a higher-level concurrency library in Java, or perhaps the concurrency annotations, making the formerly mentioned advantage barely relevant. Memory safety is certainly not the only kind of safety, but it is alas the only kind of safety supported by Rust (and every other language except C and C++).
      • staticassertion 7y ago
        > Memory safety is certainly not the only kind of safety, but it is alas the only kind of safety supported by Rust (and every other language except C and C++). I think the parent poster's entire point was that Rust does provide safety beyond memory safety. Perhaps not as a forced concept, ie: you do not have to express all structures as finite state machines, but you can very elegantly express your structures as finite state machines. And you can do so in a way that most other languages can't, because of affine types.
        • blub 7y ago
          Ok. Where's the proof that finite state machines are safer? Or that expressing structures in a certain way is safer?
• mastry 7y ago
  I think Rust is probably too complex for the average enterprise developer who seldom thinks about code outside of work. Not that these developers aren't smart - they just have different life priorities than a lot of HN readers and Rust experts.
  • abc_lisper 7y ago
    This is spot-on. Worked with enterprisy java devs .. seen their code. They couldn’t give a shit about code quality
    • codesushi42 7y ago
      Java exists to make shitty code less shitty. But in reality it will often hide the shittiness through countless layers of abstraction. Java is a great glue language. But if the problem you are solving can't be fixed by glue, say performance, computationally heavy algorithms or something of that kind, then look elsewhere.
  • seren 7y ago
    I am so to speak an industrial entreprise developer working with Vxworks on a medical device. This is exactly the kind of context where you don't mind if the compiler takes a bit longer or if you have to fight the borrow checker in exchange of not having a data race or a memory leak with catastrophic consequences at the wrong time. Today we are using static or dynamic code checker (which are not cheap) but it would be so much better if we could simply not create some kind of issues in the first place. I know that Rust is not a silver bullet either but having some Rust support in Vxworks makes so much sense. This is basically my secret wish of the last few years coming true. If anyone at Windriver is reading this, thank you! It does not mean we are going to rewrite everything tomorrow, but at least we can seriously consider that for new features we could introduce some Rust services in a few years likely.
  • firethief 7y ago
    Rust's complexity isn't accidental unless it's being used for a job where it's overkill. Achieving memory safety in non-GC languages (let alone the degree of other static safety Rust enables) is easier in Rust than C++.
• oscargrouch 7y ago
  Well, good luck with that, i guess. But being realistic, i dont think any non-GC´ed language has a chance to become the next corporate darling as Java is now. In that sense, Go, Swift, C#, etc are much more fit to become the next kings in this area, and even them will do it very, very slowly. The script family of languages also dont make a good fit, giving they tend to be bad at creating big, performant and constantly evolving kind of programs (Javascript, Python, etc). I guess the languages which are AOT compiled, GC´ed and mostly objected oriented with some mix of FP will probably be more of a fit the take the crown jewels of the king Java. The problem Rust will face in this scenario, is that it requires people with a level of brain power that contrary to 'high tech' is not that much available in the corporate level, (and the ones that have dont want to spend all of their lives behind a computer screen). And also is a "productivity hog", when we compare to sophisticated languages like C# or Swift, as productivity in Rust is on par with C++, which is not good enough when compared even with the verbose and over-enginered Java codebase. It´s basically the same reasons why, C++ is not the prefered language there. And i dont think just using the magic word 'safe' will have any charm for this kind of crowd. Giving while Rust can use this trick against C and C++, it doesnt work for productivity minded languages like Go, Kotlin, Swift and C#. Mind you that modern GC´ed languages are pretty safe, and also pretty fast. So it will be very hard to convince the corporate layer to use a language where there will be scarcity of labor, and that means they will have to pay more and be able to have less employees. The smartphone revolution gave performant and resource aware languages a renaissance and Rust is surfing in this wave. Rust has a lot of chance in smartphone, embedded, libraries and utilities and even in specific scenarios on the server. But even for the "rewrite all in Rust" mantra for C++ (a language Rust is competitive with) it will stop going forward, giving the Unix, C and C++ codebases are pretty much very influential and with a lot of sophisticated and complex stuff already out there. Anyway, i dont understand this urge to use just one language for everything. I think this is unrealistic and illusory, and i think its a better approach to elect two or three languages with fitness in some fields and just use them. The "one language to rule them all" was already the Java approach since the nineties, and while it make it a very popular language, it was in a time where the competition were not that great and even then, it proved to not work really well in all scenarios (and i think thats a good thing because it means we are free from a computer language monopoly, which would slow down the evolution in the field).