[HN Gopher] Two years of fiddling with Rust
___________________________________________________________________
Two years of fiddling with Rust
Author : elqatib
Score : 35 points
Date : 2022-11-06 20:57 UTC (2 hours ago)
(HTM) web link (n-eq.github.io)
(TXT) w3m dump (n-eq.github.io)
| drogus wrote:
| I agree with some of the points, but some of them are a bit
| weird. Like: creating a section called "Rust is unpredictable",
| because one library panicked?
|
| Another thing is with the out of bound reads. Sure, you _can_
| make an out of bound read, but I 'm pretty sure most of the
| production projects use clippy that would error out on this and
| require you to use `v.get(0)` instead of `v[0]`.
| woodruffw wrote:
| I read this as a relatively junior Rust programmer getting the
| lay of the land. I can certainly understand the "unpredictable"
| label from that perspective: there are a lot of people just
| learning Rust who might be "oversold" on what the language can
| and can't do, and are surprised when their programs fail hard
| rather than statically preventing all bugs (or, worse, silently
| doing the wrong thing).
|
| > Another thing is with the out of bound reads. Sure, you can
| make an out of bound read, but I'm pretty sure most of the
| production projects use clippy that would error out on this and
| require you to use `v.get(0)` instead of `v[0]`.
|
| To be precise: you can't cause an OOB read in safe Rust. You
| can write code that _would_ read or write OOB, but Rust will
| always insert a panicking bounds check (unless it can prove
| statically that the operation is always in range).
| HKH2 wrote:
| let _ = v[0]; // panics
|
| Why don't you use .get() instead?
| Arnavion wrote:
| You obviously can, but indexing with `[]` is the default way
| one would think of doing and it can certainly be surprising
| that it panics.
|
| Besides, the slice API is full of "infallible" functions that
| panic when given bad parameters - just search for "Panics" in
| https://doc.rust-lang.org/stable/std/primitive.slice.html -
| because it's expected that it would be more annoying for people
| to deal with the fallibility (like having to manually
| `.expect()` or bubble up the error) when they "know" that it
| wouldn't fail.
| woodruffw wrote:
| "Infallible" is not a term that the Rust library docs use, to
| my knowledge. You'll note that none of the panicking APIs on
| that page claim to be infallible, only memory safe.
|
| (I happen to think Rust can and ought to _substantially_
| improve the ergonomics of infallible API design, as well as
| provide more compiler support for avoiding fallible
| dependencies. But it 's unreasonable to treat fallibility as
| a _deficit_ , since it's explicitly outside of Rust's safety
| model.)
| andrewmcwatters wrote:
| Rust will never be a contender for C, because Rust does not
| embody the same lasting concepts C does. Rust is an obvious
| competitor to C++, where complexity growing without bound
| abounds.
|
| But for those of us looking for a C alternative, we have it, and
| it's Go. Is it a perfect replacement? I don't think so. But it is
| the closest spiritual successor the industry has.
|
| "Go bears a surface similarity to C and, like C, is a tool for
| professional programmers, achiev- ing maximum effect with minimum
| means. But it is much more than an updated version of C."
|
| "Go is sometimes described as a ''C-like language,'' or as ''C
| for the 21st century.'' From C, Go inherited its expression
| syntax, control-flow statements, basic data types, call-by-value
| param- eter passing, pointers, and above all, C's emphasis on
| programs that compile to efficient machine code and cooperate
| naturally with the abstractions of current operating systems."
|
| -Preface of "The Go Programming Language"[1][2][3]
|
| "We'll start with the now-traditional ''hello, world'' example,
| which appears at the beginning of The C Programming Language,
| published in 1978. C is one of the most direct influences on Go,
| and ''hello, world'' illustrates a number of central ideas."
|
| - Chapter 1.1 Hello World, "The Go Programming Language"
|
| [1]: https://go.dev/learn/#featured-books
|
| [2]: https://www.gopl.io
|
| [3]: https://www.gopl.io/ch1.pdf
| Someone wrote:
| For me, "bare to the metal" is one of the main benefits of C. I
| don't see go have that.
|
| So, what are, in your opinion, the lasting concepts of C, and
| how does go embody them?
| woodruffw wrote:
| > But for those of us looking for a C alternative, we have it,
| and it's Go. Is it a perfect replacement? I don't think so. But
| it is the closest spiritual successor the industry has.
|
| I don't understand the "spiritual successor" part: Go
| _intentionally_ broke ABI compatibility with the C world and
| _intentionally_ does a lot of very un-C-like things: a large
| standard library, a GC 'd runtime, a compiler toolchain that
| reimplements the "standard" toolchain, etc.
|
| Go is a clear productivity, reliability, and security
| improvement over C. But I don't know if I would characterize it
| as a successor language, other than in the "came from the Bell
| crowd" sense. Which also applies to C++.
|
| Edit: Go is also not well known for binary interoperability,
| which is one of C's main selling points.
| [deleted]
| Matl wrote:
| I had this conversation before and I think I know what they
| mean; they don't mean it in a low-level, technical sense.
| It's meant more in the sense that Go is very much of a
| similar philosophy in terms of abstractions not getting in
| the way of your work. That is, if you're a moderately
| competent Go dev there's little to decipher looking at pretty
| much any codebase.
|
| In other words, you'd spend most of your time familiarizing
| yourself with the code itself, not Go.
| woodruffw wrote:
| I think I understand that as a _virtue_ of Go, but I don 't
| see how it makes it a successor language: C famously has no
| abstractions, meaning nothing that gets in the way of your
| work _and_ nothing that helps it either.
|
| The most productive C codebases are the ones that have
| existed for years, where every possible utility and type
| has been built from scratch out of need; Go programmers are
| able to be productive from the get-go.
| vore wrote:
| What lasting concepts of C do you have in mind? I think Go if
| anything is a contender for Python: a significant number of use
| cases that require C e.g. embedded, hardware interaction,
| kernel etc. are really not good use cases for Go at all.
| halayli wrote:
| You might consider yourself a C programmer but you'll see a
| push back being accepted as one when you look at Go as a C
| alternative. For a language to be a C alternative it should
| offer at a minimum full memory control and layout. The compiled
| instructions would map very closely to the code with barely any
| runtime related calls sprinkled and definitely not GC ones. Go
| is a great language, but vastly different than C.
| yazaddaruvala wrote:
| > But for those of us looking for a C alternative, we have it,
| and it's Go.
|
| What exactly have you been using C for?
|
| Go has a very heavy runtime and is garbage collected. It also
| cannot be embedded within other languages. Go has very
| different performance characteristics. Go on embedded might be
| possible but would be a big exercise for the reader.
|
| I'm really not sure what you mean by Go is C alternative.
|
| The only similarity between C and Go I see is the syntax and
| that there were no generics, and even that is no longer the
| same. The only other similarity is the need to cast to and from
| the equivalent of `(void *)` to get around the typechecker.
| throwup wrote:
| A language with a GC and a green thread runtime can perhaps
| replace C in specific applications, but I definitely wouldn't
| call it a spiritual successor to C. There's way too much extra
| _stuff_ between you and the CPU. Odin and Zig seem most likely
| to take that crown one day. Maybe.
| AnimalMuppet wrote:
| Depends on what you think C is. If you think it's a simple
| language, then yes, Go is reasonable to view as C's successor.
| But if you think of C as a language for writing OSes and doing
| low-level programming, I'm not sure that Go is there.
| nicoburns wrote:
| I think Rust is a competitor for C in much the same way that
| C++ is a competitor to C. And I suspect it will eventually
| gobble up more of C's market share than C++ has, because it's a
| much better language (no disrespect to C++ - Rust is at least
| 20 years newer), the linux kernel being a good example of this
| effect.
|
| There probably is still a niche for a simpler language than
| Rust or C++, but I don't see Go fulfilling that niche. Zig
| seems like the strongest candidate here.
| throwawaytemp22 wrote:
| Article is light on substance. Author has a few glaring holes in
| his understanding of basic Rust concepts, and the writes this:
|
| > One of the projects I worked on consisted of bridging 900K+
| lines of C code from and into Rust. There was no great difficulty
| in doing this
|
| I'm calling bullshit.
| iudqnolq wrote:
| I suspect you misunderstood the word "bridging". I interpret
| that as FFI. Rust <-> C FFI has some tedium, but it's
| straightforward. The only complexity comes if you don't fully
| understand C.
| rowanG077 wrote:
| I don't get the compile speed hate. Rust compilation is
| inconceivably fast to me. Like what are you incrementally
| compiling that takes you out of the dev flow?
| gamegoblin wrote:
| > This is a very common misconception that stemmed from a recent
| conversation with one of my non-Rust engineer colleagues. For
| him, it was inconceivable that a Rust program would panic because
| of an out-of-bounds runtime memory fail.
|
| I feel like this is just a misunderstanding (probably from a
| somewhat junior engineer, or at least an engineer unfamiliar with
| low-level programming) between segfault and panic.
|
| Consider a program in which an array was accessed based on the
| index provided by some user input -- how could this ever be
| proven to never go out of bounds?
|
| Rust won't segfault here like some naive C will, but it will
| panic, because you hit the assertion that the index is less than
| the length of the array.
|
| Formal verification to prove that a program will never panic is a
| very neat field unto itself. There is some work in this space in
| Rust, but it's bolted on top, not built into the language (this
| is the case for most formal verification of most non-research
| languages).
___________________________________________________________________
(page generated 2022-11-06 23:00 UTC)