[HN Gopher] Full-time open source with Andrew Kelley
___________________________________________________________________
Full-time open source with Andrew Kelley
Author : signa11
Score : 136 points
Date : 2021-08-03 06:29 UTC (1 days ago)
(HTM) web link (corecursive.com)
(TXT) w3m dump (corecursive.com)
| agbell wrote:
| Podcast host here. I left this comment in a different submission
| but will repost here since front page and all.
|
| Andrew shared the backstory behind why he created Zig, why he
| decided to leave his job to work on it full time and why he is
| confident he can build THE language to replace C.
|
| Let me know what you think of the episode.
| AndyKelley wrote:
| I just want to mention that it was delightful working with you.
| I would definitely recommend anyone invited to come on your
| show to accept the offer. I've become a sponsor of the podcast
| and I invite others to join me :)
| ncmncm wrote:
| My only question is why nobody can seem to keep track of
| whether your name is Kelly or Kelley.
|
| Even in the podcast transcript it is both.
|
| Actually that's not true, I have another question. The single
| greatest strength of both C++ and Rust is the destructor: it
| makes them viable. Its lack is all that keeps me from
| thinking Zig is something I might want to use. Why doesn't
| Zig have an analog of the destructor / Drop trait?
| jdright wrote:
| Because there is people that think defer is a good solution
| (which it isn't).
| nusaru wrote:
| Coming from C, it's a bit better than nothing at all.
| bluejekyll wrote:
| > THE language to replace C.
|
| One thing I think people keep getting hung up on is this idea
| of there being a pure replacement for C. Consider the fact that
| C has already been displaced in many areas. Consider C++ as the
| first big one, it didn't add memory safety over C, but for many
| it was more ergonomic and easier to reuse code across different
| systems (the STL is a big advancement here). That took a huge
| number of users away from C. Then you have Java that added
| memory safety and that pulled away even more folks.
|
| What's been left is a particular niche for C that is being
| being targeted by new features in C++, Rust, and possibly Zig.
|
| The question really becomes what niches will each of these
| languages carve out from the existing C usage? Why would users
| adopt one over the other? There's plenty of space for all of
| these languages to thrive, what I don't think we'll ever see is
| "the one true C replacement", first because C itself will
| continue for a long time, but also because each of the existing
| C replacement languages are already are doing well. Will Zig
| capture the last C uses? I doubt it, but that's nothing against
| Zig, it's just the plain truth about how the computing world
| works. See the continued devotion to FORTRAN as an example.
| jolux wrote:
| I respect the hell out of Andrew and what he's accomplished
| with Zig, but to an extent I think it's counterproductive to
| be creating new languages that aren't memory safe. What niche
| does Zig fit? As far as I can tell, it seems to be people who
| find Rust cumbersome, and don't think it's worth the benefits
| in memory safety.
|
| I don't personally understand why I would choose Zig over
| Rust. I think it's long past time we closed the book on
| unsafe languages as a profession.
| blacktriangle wrote:
| There's two things going on here.
|
| 1) We need to move to safer languages
|
| 2) Rust is the way, the truth, and the light of safe
| languages even though its brand new and barely tested out
| in production.
|
| The first is a defensible position, the second is why
| people can have a reflexively negative reaction to anybody
| pushing Rust.
| steveklabnik wrote:
| > even though its brand new and barely tested out in
| production
|
| What would get you to change your mind on this? Like,
| Rust has been heavily tested in serious production for
| years at this point. 1.0 was six years ago. Where is the
| bar? How much usage counts? What is no longer "brand
| new"?
| blacktriangle wrote:
| 1) More time. Rust is what, 6ish years old now? And in
| those years its continued to evovle and grow.
|
| 2) More software. Particularly older software, watching
| Rust code bases evolve over time.
|
| 3) Most topical to this thread, watching how other
| approaches to safer programming shake out. Its hard to
| have confidence in a solution to a generic problem when
| you can only evaluate a single solution. For example I
| find Zig to be a potentially much better solution since
| it has a far smaller surface area.
|
| Somebody on HN said: Rust is what you get when C++
| programmers try and fix memory safety, Zig is what you
| get when a C programmer tries to do it, and based on the
| Rust and Zig code I've seen this really rings true.
|
| Rust is on a great track, but it seems way way too early
| to declare victory and start claiming that everybody
| exploring the same safe programming space is functioning
| as an unethical professional.
|
| EDIT: As an aside I enjoyed your blog post on learning
| Ada, stream of consciousness and all. You ask what the
| bar is, the bar is Ada. Decades in the market, formal
| standard, multiple implementations. I wish somebody would
| dig into why we need Rust, Zig, or something else when
| Ada exists. Is it just because Ada syntax is unfamilar to
| todays programmers or is there something fundamentally
| unsound about Ada?
| erik_seaberg wrote:
| Ada has destructors and can limit pointer type to
| lifetimes of large memory pools, but as far as I know it
| doesn't prevent use-after-free for _single objects_ the
| way Rust does. Lots of Ada is embedded on small platforms
| where they statically allocate a fixed number of objects
| anyway.
| steveklabnik wrote:
| All of this is still relative, what is "more"? is it four
| more years? Ten more years? Twenty? How much software is
| "more" software?
|
| I always find that C++ vs C comparison to be amusing,
| given I work with a bunch of C folks who don't like C++
| but love Rust... not everyone likes languages for the
| same reasons. There's a grain of truth in sayings like
| this, but it's not the whole picture.
|
| (I am also not saying Rust is the only thing, or that
| Rust should "win" over Zig, whatever that means, or
| anything more broadly. My comment is purely about how
| Rust is too "new" and "untested", in a vacuum.)
|
| Thanks for the comment about the blog post. It was a fun
| one to write.
| ksec wrote:
| >Is it just because Ada syntax is unfamilar to todays
| programmers or is there something fundamentally unsound
| about Ada?
|
| Every time I asked the same question the answer was
| syntax.
| ifreund wrote:
| This comment is a perfect example of what Andrew was
| talking about here:
|
| > Andrew: It's funny how it just kind of changes course as
| the language gets taken more and more seriously. And now,
| all the comments are even starting to shift to kind of like
| the philosophy of memory safety and whether Zig is immoral.
|
| I'd suggest you go listen to the podcast or at least read
| the "Zig Is Immoral and Unsafe" section of the transcript
| as well as the following one.
| jolux wrote:
| Well, I feel pretty strongly about this issue as someone
| who cares about security. It is a question of ethics to
| me. I mean, saying Rust is unsafe because it has the
| unsafe block is like saying Haskell isn't a pure language
| because it has IO. Yes, but it totally misses the point.
| The language is designed to minimize and constrain usage
| of unsafe features. And, outside of unsafe blocks, you
| know your code is safe. This is an important guarantee.
| flumpcakes wrote:
| > outside of unsafe blocks, you know your code is safe
|
| Only for some common memory mistakes. And ony if the
| compiler doesn't have a bug. This sounds like a nitpic,
| but let's be clear that Rust is not "safe" as if it was
| some global quality that covered all of the language.
| jolux wrote:
| > Only for some common memory mistakes.
|
| Yes, I'm talking about memory safety, because memory bugs
| cause most vulnerabilities.
| nicetryguy wrote:
| > Rust is "Safe"
|
| I'm tired of this meme. It's not true. Any Rust code that
| goes low level liberally uses unsafe{} blocks. There are
| also debugging and test modes in Zig that will sniff out
| leaks for you.
| bluejekyll wrote:
| > Any Rust code that goes low level liberally uses
| unsafe{} blocks
|
| This isn't an accurate statement. Liberal use of unsafe
| is not common or best practice in Rust. My favorite
| educational series that shows how little unsafe is
| required to work in low-level spaces is Phil Opperman's,
| "Writing an OS in Rust": https://os.phil-opp.com/
|
| That being said, I don't think most people use "Rust is
| safe" in an particular way that's different from saying
| Java is safe. Rust in many ways offers similar (and
| stronger) safety guarantees than Java (one of the safest
| langauges to date). Is Java safe? We all know that bugs
| can be created in every language, it's really the
| different classes of bugs that each language offers some
| defense against that sets them apart from each other.
| AnIdiotOnTheNet wrote:
| I think Andrew would contend that it is memory safe, it
| just defines that safety in a different way than Rust:
|
| > [...] So, the way I would describe it is that Rust has a
| kind of like vertical memory safety approach where on the
| top, it's safe. And then, on the bottom, you hit the unsafe
| block, and it's not safe, right? [...] Zig is more of I
| would say horizontal safety approach. So, there's no unsafe
| blocks where it's all contained in, but each feature of the
| language models safety in a different way. So, as an
| example, the pointer type in Zig actually can represent
| alignment. In Rust, if you want to mess with pointer
| alignment, you have to use an unsafe block and you've
| turned off safety for alignment. In Zig, you have pointer
| alignment in the type. So, it's actually completely safe,
| and in Rust it's not.
|
| And of course the reason it doesn't use anything like a
| borrow checker:
|
| > [...] Zig also wants to be optimal and optimal means you
| want to fully use the hardware that you have. So, my
| hardware lets me use virtual memory and it lets me use
| intrusive data structures. And it lets me write code in a
| certain way that's the most efficient way to use all the
| CPU and all the memory. So, if my language doesn't let me
| use all my hardware features, it's not optimal.
|
| I can't help but agree. We should strive to allow optimal
| code to work, and we should also do our best to prevent the
| programmer from doing unsafe things unless they are
| explicit about what they're doing. Are programmers
| sometimes going to do the wrong thing anyway? Yes, of
| course. The same way that someone can get frustrated and
| wrap their code in unsafe, they can use @ptrToInt without
| thinking it through.
| sdfzug wrote:
| now please translate it into non-marketing words, please.
|
| He says Rust is on the top safe (vertical), but not at
| the bottom, because the bottom isn't fully proven.
|
| He also says Zig is horizontally safe -> there is unsafe
| code on any layer, but also safe code. Also, it doesn't
| seem like there is something like "unsafe" for Zig. How
| can you say anything is safe then?
|
| So Zig has one feature that makes it harder (impossible?)
| to write broken code than with Rust in UNSAFE code. How
| does this bring anything to the table besides eloquently
| dismiss Rusts safety guarantees? E.g. allowing to state
| libraries to only have safe code in them>
|
| Afaik Rust let's you fully use the HW as well (and as
| much as possible within safe code).
| chubot wrote:
| The safety guarantees don't come for free. There are
| tradeoffs. That should be clear from the fact that Rust
| as a language is still changing, i.e. relaxing ownership
| rules and adding new mechanisms to the type system. If
| there were no problems, then there would be no language
| changes necessary.
|
| Examples of people writing Rust code and hitting problems
| of expressiveness and performance:
|
| _My experience crafting an interpreter with Rust_
| https://ceronman.com/2021/07/22/my-experience-crafting-
| an-in... (I'd be interested in experiences from others
| who have implemented a GC'd language runtime in Rust)
|
| Also see _Why I rewrote my Rust keyboard firmware in Zig:
| consistency, mastery, and fun_
| https://news.ycombinator.com/item?id=26374268
|
| You can argue about how much the tradeoffs matter, which
| is heavily domain specific. But you can't argue that the
| tradeoffs don't exist.
| jolux wrote:
| > it just defines that safety in a different way than
| Rust
|
| Memory safety is already well-defined, though. It means
| that you _can't_ write code that mishandles memory in a
| dangerous way. In Rust, code outside of unsafe blocks is
| guaranteed to have this property. As far as I know, no
| such feature exists in Zig. So Zig is starting from a
| point where it can't _guarantee_ the safety of _any_
| nontrivial program, right?
| TimSchumann wrote:
| In my (admittedly) very limited usage/understanding of
| Zig, this is a fairly accurate description of where the
| memory safety comes from.
| ksec wrote:
| I think the horizontal vs vertical memory safety argument
| needs to be better marketed. Because right now Memory
| safety PL is quite literally trademarked by Rust in any
| discussions.
| tasogare wrote:
| I'm reading a page about Zig from the official documentation
| and it says:
|
| > For C/C++ projects, having dependencies can be fatal,
| especially on Windows, where there is no package manager.
|
| Which is doubly wrong. First there is an official package
| manager for Windows (winget), but there is also vcpkg, a
| package manager for C and C++ libraries, also developed by
| Microsoft.
|
| Otherwise the language seems to have good design, so it's bit
| regretful to use strawman argument about package managers.
|
| PS: the doc page is
| https://ziglang.org/learn/why_zig_rust_d_cpp/
| geodel wrote:
| > First there is an official package manager for Windows
| (winget
|
| Just calling half finished product "official" doesn't really
| mean much. On my linux server from operating system to
| thousands of utilities are packaged in native format and
| available via package manager like yum. On Windows forget
| dependency management etc not even basic installation of one
| percent of ecosystem is covered by package manger.
| losvedir wrote:
| Thanks for the transcript! I'm not usually a fan of audio/video
| so I love that I can just read the interview.
|
| How is it generated? Speech recognition? Much in the way of
| hand editing necessary?
| agbell wrote:
| I tried machine translation but it just isn't there for
| technical content. I use rev.com, which is a human
| transcription service. I supply them with a thesaurus of
| terms used and then proof read it and correct it myself
| after. The headings and jump points I add manually.
| VyseofArcadia wrote:
| I have some feedback about the transcription. There are
| some places where you are transcribing a conversation with
| Andrew, and you're labeled as Adam. There are some other
| places where you are not having a conversation with Andrew,
| but are instead acting as a narrator to insert context or
| clarification. These are also labeled as Adam.
|
| It becomes clear which are which from context after a
| couple sentences, but it's a little jarring. It would be
| nice if the second kind were labeled Narration or Voiceover
| or something.
| agbell wrote:
| Thanks for reading. Interesting idea! I did have this
| thought myself at some point and went and checked on some
| other narrated podcasts and found they kept it all under
| one label, but I can see how that could be confusing.
| Maybe I'll try that for the next one.
| wyldfire wrote:
| I listened to this the other day. I usually don't listen to
| podcasts like this and when I do occasionally click on one I
| rarely follow through and finish the episode. I enjoyed this
| one and finished it -- though, I was already interested in the
| subject matter.
|
| The topic of funding Zig came up during the podcast. So,
| Andrew, if you come across this post: can you have zig
| foundation accept cryptocoin donations? Not sure how hard that
| is to do but if you toss up an bitcoin/monero/etc address I
| will donate some.
|
| Also, Andrew - you should consider giving a talk at an upcoming
| US or Euro LLVM conference. Even if it's just a lightning talk,
| it would be valuable for the community to hear about a non-
| clang compiler (or a super-clang compiler). I think US Bay Area
| will have one in ~October 2021?
| hawkesnest wrote:
| I've been listening through the podcast's episodes and find it
| very interesting! It hits all the right marks for me. It's well
| structured, the audio quality is good (better in more recent
| episodes), length is appropriate, solid pacing.
|
| In fact, I just became a "Junior Engineer" supporter on
| Patreon. Keep up the great work. Hopefully one day I'll have
| done something worth talking about on your show.
| agbell wrote:
| Thanks for listening and thanks for supporting me!
|
| Yeah, the further you go back into the back catalog the more
| you are listening to my learning-to-podcast phase. Hopefully
| they aren't too bad... I am a slow but persistent learner.
| andi999 wrote:
| His understanding of undefined behavior seems off. Undefined
| behavior does not imply that the program crashes. I agree with
| him though that this would be a nice feature.
| ifreund wrote:
| > Andrew: In release fast mode, which is unsafe, you will get
| actual undefined behavior. So, you might crash or you might get
| overflow. You might go down to zero or you might run an
| unrelated function.
|
| Are you perhaps confusing this with statements made about the
| debug and release safe build modes?
___________________________________________________________________
(page generated 2021-08-04 23:01 UTC)