[HN Gopher] Prossimo - Memory safety for the Internet's most cri...
___________________________________________________________________
Prossimo - Memory safety for the Internet's most critical
infrastructure
Author : eplanit
Score : 89 points
Date : 2021-06-18 14:29 UTC (8 hours ago)
(HTM) web link (www.memorysafety.org)
(TXT) w3m dump (www.memorysafety.org)
| oscargrouch wrote:
| TIL: That there's an ORG to effectively harass people like Daniel
| Stenberg to rewrite popular stuff in Rust.
|
| To the Internet Security Research Group just fuck you! you will
| take my C++ out of my dead cold hands.
|
| I've never expected to see fascist ideology to get encoded into
| language culture.
|
| Lets make it even better, why don't we all get back to
| typewriters giving there will be no more bugs?
|
| There is a right way to do it: Do your own cool things in Rust.
| It will get popular and the language will get there eventually.
| This is not the right way, as developers are formed over
| technologies and their knowledge is even more important than the
| tools. Rust will form developers that will do great things, if
| C++ is a thing of the past it will get obsolete organically.
|
| Please rewrite Linux in Rust if you wish but leave Linus Torvalds
| alone. I cant wait for the next Rust driver module to freeze my
| flawless Linux in "dirty" C..
| mwcampbell wrote:
| > TIL: That there's an ORG to effectively harass people like
| Daniel Stenberg to rewrite popular stuff in Rust.
|
| This is both inflammatory and wrong. ISRG isn't harassing
| Stenberg; they're paying him to do the work they want done. And
| he's not rewriting curl or libcurl in Rust; he's adding
| optional new backends for key pieces like the HTTP and TLS
| implementations.
|
| https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...
| oscargrouch wrote:
| What is inflammatory is the way a part of the Rust community
| deals with other languages.
|
| You are right is not just ISRG, but it is part of this big
| masonry-like movement forming to replace C++, not by virtue,
| but by force and politics. Unlike any other language out
| there that is trying to do it in a clean manner.
|
| Android for instance was the last asset with a takeover in
| this hostile manner, no other language out there ever did
| before. Despite we have tons of other safe memory languages
| out there.
|
| I cheer for Rust the technology, to grow, but lets care about
| the language, because its not enough we work so hard to make
| things work, we still need to feel miserable, no matter the
| things you have done, because you are not using a pink
| t-shirt (one vector on a multivector of preferences and
| goals).
|
| Is the end there is much more details into why we choose X
| and Y.
|
| A lot of C and C++ code are out there, and with them a lot of
| great knowledge. man-years of work, of life into them.. they
| are wonderful pieces of engineering, and yet, just because
| they are "not written in the right language (tm)" it will
| force by culture and not by virtue that they get kicked off
| like garbage.
|
| This is totally disrespectful, and most of the time is pure
| marketing and salesman pitch. Rust has yet to prove itself in
| a lot of fronts, and this will only happen with time.
|
| I've seen Daniel being constantly bullied to feel miserable
| for having its tool in C, in Twitter, in mailing lists.. and
| he is just a sample..
| tialaramex wrote:
| > not by virtue, but by force and politics.
|
| It looks like virtue to me.
|
| You seem to like C++. Look at the C++ direction of travel.
| Lifetime annotation? Rust has it, Bjarne now wants it in
| C++. Volatile access? Rust has it as methods read_volatile
| and write_volatile, and C++ is moving away from "cv
| qualfier" towards that same approach. Modules? Rust has
| them. C++ is now getting them. Backwards compatibility?
| Rust has editions, C++ is trying to do epochs.
|
| C++ has spent years trying to argue that "Good" C++ won't
| have all the terrible problems, and so far it just hasn't
| worked out that way. I think the backward compatibility
| nightmare will consume C++ faster than it can try to dig
| itself out.
|
| Here's the biggest problem: The people who can't leave C++
| for Rust are also most invested in the features that
| prevent C++ from evolving to compete with Rust. If you're
| programming x86-64 machines with a C++20 compiler, you
| could go to Rust anyway, you'd be excited about a C++23
| with lifetime annotation and epochs, but not so excited
| that you will throw effort at helping that to happen rather
| than Rust. Whereas if you're programming a specialist DSP
| and you're looking forward to getting C++ 17 next year when
| your vendor offers it, you can't move to Rust easily
| because there is no Rust for your DSP (yet?) but you also
| don't care about C++23 because your compiler vendor hasn't
| even announced a C++20 compiler yet.
| oscargrouch wrote:
| Just a correction: Im not implying that Rust have no
| virtues, it has a lot, and its a very strong candidate to
| write new projects into whenever you think you need C++.
|
| I would and will consider Rust always, and it probably
| will make sense to use instead. If my former post implied
| that i dont like Rust, im correcting here, because i like
| it and i thinks its cool technology and that it have
| virtues C++ don't have.
|
| I was saying that, specially now that the language is
| more mature theres a thriving community around it, it can
| go by virtue..
|
| C++ is where it is now because of its "killer apps".
| OS's, Browser, Games, a great amount of complex software
| with millions of lines of code.
|
| And they are not garbage that need to be replaced. Rust
| taking over by virtue will be by creating killer apps in
| it. Showing itself as a great replacement for projects
| that can also be coded in C++.
|
| Security folks invested in Rust saying that all new code
| in Android will now be coded in Rust its not replacing by
| virtue as important things like domain knowledge and
| getting used to a tool is also very important, and it
| will probably go away. Security is just one thing that is
| important in a project, its not the only one. But of
| course if you let the security folks decide, other
| important aspects will not be taken into account (I
| tought it was a really bad move by the way, as other
| problems not linked to security will appear with time).
| tptacek wrote:
| Nobody with influence agrees with this assessment.
| Without taking the bait on this "C++ software is garbage"
| stuff: there's general acceptance that some significant
| chunk of memory-unsafe software, particularly the stuff
| most exposed to attack, or that runs on the systems we're
| most concerned with being attacked, needs to be replaced
| with memory-safe alternatives.
|
| It is simply not the case that Rust's only role is in
| "new killer apps". Replacing C++ code is part of the
| raison detre of Rust.
|
| You knew this was a pointless dead argument the moment
| Linus Torvalds began entertaining Rust kernel modules.
| The debate is over. That doesn't mean --- regardless of
| what any website says --- that all C++ software is
| "garbage", or that anyone is going to pry C++ out of your
| cold, dead hands. But it does make arguing about whether
| the maintainer of curl should accept funds to replace
| some of their code with Rust tedious and unproductive.
| mwcampbell wrote:
| To be blunt, the security of the software that runs so much
| of the world is way more important than the feelings of
| some programmers who feel that their beloved languages are
| under attack.
|
| With ransomware and other online attacks on the rise, the
| stakes are too high to allow safer alternatives to be
| developed at a leisurely pace by volunteers. That's why
| ISRG is paying to have the work done, and why corporate
| projects like Android are putting financial resources into
| this as well. It's not a sinister attack on your favorite
| language, just an effort to make software more secure.
|
| Getting back to something you said in your previous
| comment:
|
| > you will take my C++ out of my dead cold hands.
|
| Is this really the hill you want to die on? To me this
| suggests a lack of perspective on what really matters. A
| programming language is just a tool, not something to get
| attached to. When a better tool comes along, be open to
| using it when you can. Especially if someone pays you to do
| so. I used to be a big fan of both Python and Lua. Now I
| usually don't use them for new projects, though I may still
| if I think one of them is the right tool for the job.
| Ericson2314 wrote:
| > With ransomware and other online attacks on the rise
|
| Yeah we really need to show the world better defense is
| possible, or the US military, always hungry for mission
| creepy, is just going to subsidize critical
| infrastructure that should have never been private in the
| first place with free counter attacks or whatever.
|
| The non-technical policy consensus is already "defense is
| hard", not "we're incredibly sloppy and we should be
| ashamed of ourselves", and so changing norms is really
| important and already an uphill battle that's just going
| to get harder.
| oscargrouch wrote:
| > To be blunt, the security of the software that runs so
| much of the world is way more important than the feelings
| of some programmers who feel that their beloved languages
| are under attack.
|
| As someone that have created software in at least 7
| programming languages, including Rust, I agree with you,
| i only disagree with the recipe and the tactics used.
|
| The bugs will happen, and contrary to the constant
| hammering sales pitch, Rust will not escape from them.
| Its like saying we are free from uncertainty. Its a false
| promise and anyone with real life experience in big
| software that are not neurotic about security like
| someone that only see software under this perspective
| would do.
|
| Now, i believe Rust will likely have less bugs in the
| end? It depends most of the coder, but taking that
| variable out of the way, its more likely because its
| design is more strong into that direction.
|
| Cant people fix security bugs once they happen? this will
| be the approach be it in Rust, C++.. Rust still will have
| to wrap insecure parts in unsafe{} blocks anyway, the
| same way a C++ coder do only that its not a keyword.
|
| Im all for Rust having the right to tell its strenghts, i
| like the tech and what its offering, i can see why it can
| be better, but lets take care of the language used and
| the ideology behind our wording, its all i'm asking
| here..
|
| Its time for the Rust community to grow up and stop
| pitching by shaming other languages, projects and
| communities, as if its the only reasonable answer like as
| if was some sort of master-race of programming languages
| and everything else should be replaced because its
| garbage.
|
| This is not true, and while i like the tech, im worried
| about how a culture formed around bullying "inferior"
| languages will become with time.
| geofft wrote:
| The Rust community tries _extremely_ hard not to shame
| other languages, projects, and communities. If you 're
| talking about ideology, you will not see any ideology
| from the Rust project saying "This other language sucks."
| You'll just see "We're trying to build a high-quality
| technical product."
|
| In fact, the Rust compiler itself depends heavily on LLVM
| (C++), Cargo fetches crates using libgit2 (C), rustup
| downloads updates using libcurl (C), Rust uses the C
| standard library (C) instead of directly making syscalls
| like Go/Zig/etc. do, memory allocation used to use
| jemalloc (C) until they switched to using the platform's
| C standard library for compatibility, etc. If there were
| any belief in the Rust community that other languages are
| garbage, those dependencies would have been replaced long
| ago.
|
| If outsiders are saying that other languages are
| inferior, it is because they've examined the evidence and
| made up their minds, not because anyone is organizing a
| bullying campaign. Most of the people saying that do, in
| fact, have extensive "real life experience" with C and
| C++ and have come to their conclusions based on that
| experience.
|
| Which is to say, I don't know any way that the Rust
| project could try harder to steer the language and
| ideology to be more respectful of other languages other
| than by making Rust a less compelling language.
| tptacek wrote:
| I mean, I'm a fan of this project and happy about Rust's
| emerging role in the world, but that first sentence is
| obviously not true. Maybe they're trying harder lately.
| steveklabnik wrote:
| It has been longstanding policy of the project itself to
| take this stance. That doesn't mean that every single
| community member follows our example, though, or that
| everyone involved is perfect. But we made a deliberate
| decision to try and avoid this as much as possible.
|
| Part of this was informed by my past experiences...
| oscargrouch wrote:
| "Here's Daniel a guy who struggle to keep his open source
| project used by millions working in very important big tech
| projects. Despite the fact that big companies use its
| project, he mostly get funded by ordinary people who can pay
| a few bucks"
|
| "But Daniels destiny is about to change, a ORG that funnels
| capital from big tech companies to make software more secure
| is about to give him a grant"
|
| "Here Daniel, we have a grant so you can fix your security
| bugs"
|
| "Oh great, now i can invest in more unit test and have people
| to fix them.. and.. "
|
| "But you will only receive the money if you or someone we pay
| for write those parts in Rust"
|
| While Daniel is being payed, this is not actually/only
| focusing on security as an end goal, but is using security as
| a pitch to rewrite popular software in Rust which in the end
| will probably have more bugs giving the older software were
| much more battle tested..
|
| So we have people with foot on big tech collect money through
| an org to rewrite software in Rust and not to ACTUALLY help
| the people doing software with very low resources to fix
| their software.
|
| Daniel is saying he will still keep doing it in C. So why do
| this org tried this approach giving i bet whatever you want
| that this money invested for them to focus on security even
| in C would make it have less bugs, because the real problem
| here is economics and less the language.
|
| Its a pity that an ORG is being used as a facade to create
| implants of Rust in popular projects, instead of helping out
| open source developers with money that would probably reach
| them if they did not act as the middle man to those important
| projects.
|
| See their goals here, is not even about security as a whole,
| but memory safety, and while they cite other languages, this
| is clearly biased towards Rust.
|
| https://www.memorysafety.org/docs/memory-safety/
|
| Please dear ORG take the money from big tech, invest part of
| it for new projects in Rust if you wish, but really help the
| open source maintainers to fix their security bugs in the
| technology they use. Note that you are receiving this money
| using their projects to receive the grants. Really help them
| make their software more secure.
|
| If you are really into the Rust hype, so create a fork in
| Rust, show that you were right.. or at least be open when
| collect the money to invest what your real goals.
|
| But its a pitty, a project like OpenSSL for instance wont see
| a dime of this money. So sorry if i dont feel happy about
| this..
| mwcampbell wrote:
| Again, Stenberg himself seems to feel differently about
| what's going on than you do. From his blog post "What goes
| into curl?" [1]:
|
| > I'm the lead developer of the curl project but I also
| offer commercial support and curl services to allow me to
| work on curl full-time. This means that paying customers
| can get a "priority lane" into landing new features or bug-
| fixes in future releases of curl. They still need to suit
| the project though, we don't abandon our principles even
| for money.
|
| [1]: https://daniel.haxx.se/blog/2021/06/16/what-goes-into-
| curl/
| px43 wrote:
| Eh, memory safety hasn't ever really been the problem with
| mod_tls, or curl, but it would be nice to have some solid
| examples for other projects to build on.
|
| The Linux kernel project sounds interesting. It would be nice if
| there was an effort to purge as much C code as possible from the
| core of the kernel and really enforce standards such that even a
| maliciously designed kernel module should not be vulnerable to
| memory corruption bugs.
| topspin wrote:
| Here[1] is the ongoing list of "curl security problems." Note
| the several memory safety related issues. The two most recent
| are: May 26, 2021 CWE-416: Use After Free
| May 26, 2021 CWE-457: Use of Uninitialized Variable
|
| There are numerous others that follow including out-of-bounds
| reads, overflows, etc. I can't imagine where you got the idea
| that this somehow "hasn't ever really been" a problem for curl.
|
| [1] https://curl.se/docs/security.html
| simion314 wrote:
| Why not have all this Rust energy focused on a new kernel (not
| a toy/experiment), a kernel architect ed not evolved. You would
| get better results and if you need Linux compatibility add
| support for it from the start in soem kind of
| emulation/compatibility layer.
|
| Putting Rust into kernel seems to me that is a lot of effor for
| microscopic gains.
| huachimingo wrote:
| Redox OS https://www.redox-os.org/
| geofft wrote:
| Li et al., "An Incremental Path Towards a Safer OS Kernel,"
| HotOS 2021 (two weeks ago), is an academic paper arguing that
| putting Rust into an existing kernel will deliver you much
| more than microscopic gains and will yield better results
| than starting from scratch. https://sigops.org/s/conferences/
| hotos/2021/papers/hotos21-s...
| Ericson2314 wrote:
| I think they are complementary goals.
|
| On aspect of the Rust-on-Linux worked I've helped out with is
| trying to make sure standard library abstractions aren't just
| suitable for userspace. I hope the medium term result of this
| is more comparability between bare metal projects on axes
| where they _aren 't_ trying to differentiate.
|
| Longer term, I hope that means a corpus of driver that can be
| shared between kernels, revolutionizing kernel diversity the
| same way LLVM revolutionized programming language diversity.
| aaomidi wrote:
| A new kernel has a massive uphill battle to fight to get to
| where Linux is today. Like, an absolutely huge battle to
| fight.
|
| Although it would be great to eventually see it.
| simion314 wrote:
| I know, but Linux will not be forever, someone will start a
| new kernel that will replace it. All this giant tech
| companies could afford to pay some experienced people to
| start working on it. The initial scope would be limited but
| if the architecture and the language combo would give it a
| performance and security boost then for sure it will be
| adopted and new contributors would appear. If the
| performance/security would be similar to Linux/BSD then for
| sure the progress would be very slow.
| tialaramex wrote:
| > Linux will not be forever
|
| Linux is thirty years old. And Linux isn't something from
| whole cloth, it's a Unix, it didn't have some legal and
| technical baggage that UNIX(r) brand Unix had but it's a
| Unix. And Unix is over sixty years old.
|
| We may very well be done. Unix isn't the best conceivable
| Operating System, but it seems like it's good enough, and
| in being good enough it became so enormously popular that
| any new alternative has to be night-and-day better or why
| bother?
|
| I'm reminded of the Two's Complement Integer thing.
| Historically it was unclear if this was the "best" way
| for integers to work. Hardware existed, and sold well
| decades ago, with some other ideas for how integers could
| be represented and calculated. But, gradually, over time,
| even if Two's Complement wasn't clearly the best, it
| _was_ clearly the most popular, and the others weren 't
| clearly _better_ so why fight it? Sure enough, "Two's
| Complement Integers" get to just be how integers work by
| default in newer languages.
|
| If Linus and all the subsystems people were screaming
| "Nothing but C, under any circumstances" then perhaps you
| could imagine a competitor to Linux comes along in ten,
| twenty, thirty years. But so long as they remain open to
| changes that actually have good results, they're going to
| stay on top.
| Ericson2314 wrote:
| Rust has been prominent in Fuscia's userland (which is
| bigger proportionally because it's a microkernel), but
| not the kernel (Zircon) itself.
|
| Considering Google's funding of these ISRG projects, I
| hope this changes.
| tptacek wrote:
| Because ISRG is trying to direct funds to projects that will
| actually protect current Internet users; notably, this isn't
| a _research_ project, but rather a funded engineering
| project, focusing on things that are already in wide use.
| tialaramex wrote:
| Memory safety hasn't been a problem with mod_tls because
| mod_tls is the module written in Rust.
|
| But likely you were thinking of mod_ssl. Except, mod_ssl is how
| Apache ends up using OpenSSL, where the famous Heartbleed bug
| is literally exactly the sort of memory unsafety that you'd
| never do in Rust.
| [deleted]
| Animats wrote:
| On the "critical infrastructure" front, I'd like to see a few
| "hard nuts" built. Not many. Just a few special purpose boxes, to
| start:
|
| - A BGP server.
|
| - A DNS/DNSSEC server.
|
| - A WiFi/home network gateway.
|
| Those are critical infrastructure. They're self-contained units
| which talk well-defined protocols. Their functions don't change
| much. The first two aren't that price-sensitive. They should be
| verified down to the bare metal.
|
| Apply to DARPA or NIST or DHS for funding for such a project. You
| might get it.
| jaas wrote:
| Good ideas!
|
| We are already working on plans for DNS. BGP has been in the
| back of our minds for a while but we haven't had the bandwidth
| to start seriously looking into that yet. If you have ideas get
| in touch!
| tptacek wrote:
| I get why BGP sounds like a good target, since it's self-
| contained and high-importance, but I'd assume the most
| important BGP4 deployments on the Internet aren't in systems
| that can replace their BGP4 servers with anything that Cisco
| isn't itself shipping. Lots of people run little `birds` to
| advise their upstreams, but they're not running full-feed
| defaultless; they're minimally exposed. I think the win from
| a community-driven BGP4 project might be small compared to
| the investment. But you've been thinking about this already,
| so I'd love to hear about how wrong I am. :)
| jaas wrote:
| What you are describing matches my impression of things. It
| has been on the back burner because even if we had a great
| memory safe version of, say, openbgpd, I am not sure that
| would have particularly widespread impact. You are probably
| right that we would need to convince Cisco and friends to
| move to memory safe code.
| tptacek wrote:
| A Rust or Go DNS server that served as a drop-in
| replacement for BIND or nsd, on the other hand, is a big
| win. :)
| kijiki wrote:
| Big Internet BGP servers also aren't super exposed due to
| the common use of TCP MD5 (RFC 2385) or TCP AO (RFC 5925).
| The userspace daemon won't even see packets from attackers
| who don't have the shared secret for that peer link.
| sometimesshit wrote:
| "Using C and C++ is bad for society, bad for your reputation, and
| it's bad for your customers."
| baybal2 wrote:
| That made me laugh. Can people treat such people seriously when
| they obviously aren't?
|
| Dumb, aggressive promotion is characteristic of "trendy hipster
| projects" usually abandoned once the "cred" harvest is
| finished, and people involved go on.
| topspin wrote:
| It would be funny if they couldn't cite an endless stream of
| evidence for their argument. They can, however.
|
| And it's not going to stop. That's the thing about the memory
| safety argument; the people making it have an endless supply
| of ammunition, resupplied daily.
| bombela wrote:
| It's both funny and true at the same time.
|
| I used to advertise my worth in how good my C++ is. Until I
| had a dumb after free error after git merging two adjacent
| line in the wrong order. A simple vector push done after
| capturing vector.begin instead of before. Nobody saw that in
| code review. Even reviews from C++ experts at the company. Of
| course it took 6 months until the first segfault.
| Invalidating 6 months of work. Rust would have not compiled.
| As simple as that.
|
| Now imagine if you could write code without living in fear of
| making everything blow up because of a single moment of
| weakness. That's Rust for me.
| tptacek wrote:
| These people are obviously serious.
| baybal2 wrote:
| It looks to me an another attempt to force feed people Rust at
| any cost irrespective of the rationale.
| bbarnett wrote:
| All I keep seeing, is how rust is perfect for everything, will
| fix everything, should be everywhere, etc, etc. There's gotta
| be a profit motive involved. There must.
| geofft wrote:
| There is _absolutely_ a profit motive involved! The less time
| you spend dealing with segfaults and inexplicable double-
| frees because you have no idea where the _first_ free is, the
| more time you can spend working on features that impact the
| business 's bottom line. The fewer emergency patches you have
| to deploy, the more uptime you have and the less you spend on
| the required ops work. The fewer zero-days you suffer, the
| fewer existential threats to your business. And so forth.
|
| None of this would be happening if the market didn't care. I
| was one of the people who started the Linux kernel modules in
| Rust project (I'm credited in the announcement), but I
| started it because I thought it would be fun, and I have a
| day job that isn't related to Rust at all. So I've spent
| almost no time on it recently.
|
| The corporate sponsors behind this effort are interested in
| this because they use Linux (and curl and so forth) at a
| large enough scale where this sort of thing matters. I would
| guess that, for instance, Google cares about getting Rust
| into Android's kernel because they want to credibly claim
| that Android has fewer zero-days than iOS, and they have a
| clear public agenda of wanting to get rid of zero-days (see
| e.g. https://googleprojectzero.blogspot.com/p/0day.html).
|
| So that's their profit motive, and I'm very happy it exists,
| because this work is too important to rely on the free time
| of people like me.
|
| (To be abundantly clear: I am not paid by any of the involved
| organizations, and I had no advance knowledge of this before
| the public announcement.)
| nneonneo wrote:
| Very tangential, but the _very slight_ angle on the "Memory
| Safety" highlight threw me for a loop. For a moment I wasn't sure
| if it was actually slanted or not until I zoomed way in to
| confirm the slant.
|
| That's distracting as heck and I can't think of a good reason to
| have such a weird highlight...
| tptacek wrote:
| JFWIW: the guidelines ask us not to write comments like this
| (CMD-F for "too common to be interesting").
|
| https://news.ycombinator.com/newsguidelines.html
| [deleted]
| xvilka wrote:
| Finishing Firefox oxidation[1] should become a priority too.
| Also, combining all separate modern alternatives[2] to coreutils
| and such in Rust, like exa, dust, etc into one umbrella project.
|
| [1] https://wiki.mozilla.org/Oxidation
|
| [2] https://github.com/ibraheemdev/modern-unix
| nerdponx wrote:
| I love that Rust has become a successful systems language with
| memory safety. And while I use many of these "coreutils
| replacements" frequently, they are mostly _not_ equivalent to
| the originals, and I think it 's disingenuous to claim that
| they are.
| tialaramex wrote:
| They aren't drop-in replacements, but I think "equivalents"
| is fair.
|
| Your existing bash scripts don't work in an alternate
| universe where computers come with ripgrep not grep, but that
| universe isn't very different otherwise. Some things are a
| little easier to do, some things are a little harder to do,
| there are different bugs than in our universe, but it's way
| less strange than a universe where Lisp Machines still
| dominate, or even one where the Network uses X.25 rather than
| IP.
| dochtman wrote:
| See also https://github.com/uutils/coreutils/
| Ericson2314 wrote:
| Good luck getting Google to fund that one particular go, heh.
| Even if they do fund Mozilla.
| ferdowsi wrote:
| Why the push to have RustTLS replace OpenSSL, instead of Go's TLS
| library (which is mature and widely used?)
| tptacek wrote:
| Go's TLS is the right choice if you're working on a project
| that uses Go. Go is often a good choice if you're rewriting a
| whole project to be memory-safe. But if you're retaining a lot
| of your C/C++ code, and trying to surgically replace the
| attack-surfacey bits with memory-safe code, that's Rust's job,
| not Go's.
| mwcampbell wrote:
| I would guess because Go, having a garbage collector and green
| threads, has a heavier runtime than Rust and is therefore
| harder to embed into programs written primarily in other
| languages. Can anyone else speak more authoritatively on this?
| Ericson2314 wrote:
| C -> Go FFI is a lot harder. Per their website, they are a big
| on a modular approach where libraries can be made memory safe
| concurrently.
|
| Languages with non-trivial runtimes like Go or Haskell just
| don't support that same model. You would want to convert your
| libraries in a certain order so there is one continuous C vs
| non-C boundary.
| topspin wrote:
| This doesn't deserve the downmods; when one assumes good faith
| all we have here is a straightforward question.
|
| Here is the answer; When you wish to provide a library that you
| intend for use in diverse applications[1] -- and OpenSSL is a
| excellent example of exactly this case -- you cannot choose a
| language with a complex runtime. Go has a complex runtime.
| There is no getting around this; any non-trivial software
| implemented in Go will require a number of runtime facilities
| and accommodating that becomes a burden for the library user.
|
| Rust has about the same runtime burden as C/C++. It links the
| same way as C/C++ and imposes the minimum possible burden on
| the library user.
|
| [1] diverse as in essentially all platforms, from
| microcontrollers to high performance systems at scale, over
| decades of evolution.
___________________________________________________________________
(page generated 2021-06-18 23:01 UTC)