[HN Gopher] Building an efficient and portable programming langu...
___________________________________________________________________
Building an efficient and portable programming language with Zig
Author : DyslexicAtheist
Score : 128 points
Date : 2021-05-13 11:42 UTC (11 hours ago)
(HTM) web link (www.fastly.com)
(TXT) w3m dump (www.fastly.com)
| v8dev123 wrote:
| I am attracted to the Zig syntax, but I don't like Kelly
| ant6n wrote:
| He's a great guy!
| cassepipe wrote:
| Care to elaborate on why?
| v8dev123 wrote:
| vLang
|
| He has gone greater length to tarnish this language creator.
| It shows me he is up to something and I don't like that.
|
| I pretty much don't use Vlang, but I dislike the way Kelley
| behaved.
| UncleOxidant wrote:
| Yeah, he might have come on kind of strong against the V
| guy, but as I understand it there are some vapor-warey
| aspects to VLang (or were at the time he pointed them out).
| [deleted]
| drcode wrote:
| Curious why someone wouldn't like Kelley- Is it because he
| shoots down feature additions a lot?
| skohan wrote:
| I don't know much about Kelley, but if the goal is to create
| a "C replacement", aggressively keeping the language surface
| area small seems like a reasonable way to go.
| blacktriangle wrote:
| And even if you don't think that's right, we already have
| the large-surface area systems programing language
| experiment in Rust. Aren't we better off with Rust and Zig
| exploring clearly different paths for a C replacement than
| both of them trying the same things?
| v8dev123 wrote:
| Simple, small languages getting complicated when used in
| large applications while complex languages become simple
| and easier when used in large applications.
| skohan wrote:
| That mostly seems correct, but Zig will be an interesting
| one to watch due to the approach of having powerful
| compiletime execution. I.e. Zig doesn't have generics in
| the traditional sense, but you can get them by writing
| normal code which creates types for you at compiletime.
| The promise would be that you can get more advanced
| features without adding complexity to the language, i.e.
| like in Rust where you have to basically understand the
| AST in depth to be able to write macros. We'll see if it
| pans out.
|
| Also for instance Go has been able to stay relevant while
| staying very small. Complex languages can help with
| complex projects _if there is a good program structure_ ,
| but one advantage of simple languages is there is only so
| much of a mess which can be made if developers go a bit
| off the reservation.
| dnautics wrote:
| Yeah this is not my experience. Enterprise distributed
| systems are much easier in erlang and elixir, which are
| simple languages, over java, which is not.
| v8dev123 wrote:
| They are functional languages. There is difference.
| drcode wrote:
| Exactly, this is why he sometimes comes off as a jerk,
| because he tells people stuff like "No, you can't add your
| virtual function table feature to Zig, OOP programming is a
| bad idea in a systems language."
| matheusmoreira wrote:
| Indeed. In this video he explains the reason why he made
| those choices:
|
| https://youtu.be/Gv2I7qTux7g?t=120
|
| All these programming language features require a lot of
| machinery, complicating the binary interfaces of the
| resulting software and preventing code reuse.
| v8dev123 wrote:
| He is childish. He had record breaking flame war in HN.
| matheusmoreira wrote:
| What was it about? Link?
| suby wrote:
| I'm assuming that he's referring to this thread,
| https://news.ycombinator.com/item?id=20229632
| klyrs wrote:
| A key feature of a "flame war" is long chains of
| responses. By not responding to amedvednikov, AndyKelley
| did not participate in a flame war on that post. It was a
| call-out. His criticism was quite relevant at the time,
| because the article was a false release announcement, and
| the project was garnering a lot of attention (and taking
| people's money) by making outlandish claims, with (at the
| time) nothing to show for it.
| v8dev123 wrote:
| There were many posts both in HN and outside HN including
| Github, Reddit, Twitter.
|
| His criticism is not constructive. He had Linus style
| comments.
| klyrs wrote:
| There is no such thing as "constructive criticism" of
| suspected fraud -- there were a bunch of red flags, and
| AK was not remotely alone in sounding the alarm. Do you
| have constructive criticism to offer, is AK still
| badgering AN, or are you just airing grievances about 2
| year-old drama?
| v8dev123 wrote:
| > There is no such thing as "constructive criticism" of
| suspected fraud
|
| You can criticize anyone constructively. What they are
| today is not what they are in the future. People can
| change even Andrew, but if something is repeated over and
| over, it is a sign of their personality.
|
| I see his act as harassment. I know that Vlang had red
| flags, but I feel Russophobia or Jealousy in his actions.
| I looked through everything, but the guy didn't let the
| man talk and explain himself. So, the other side of the
| story is hushed up. It's like asking someone to prove
| their worth, otherwise they'll be killed. Naive Bayes can
| uncover many cases of fraud, but bias can turn things
| upside down.
|
| I'd hope that Mr Andrew is not an Anarchist.
| klyrs wrote:
| > You can criticize anyone constructively
|
| Please, show us how that's done. Otherwise, please stop.
| AK's last word on the matter was rather cordial, and what
| you're doing here is toxic.
| AndyKelley wrote:
| For the record this was my last public statement about V,
| which I made nearly 2 years ago: https://twitter.com/andy
| _kelley/status/1142503808901308418
|
| ends with "I'm genuinely glad it turned out this way.
| Good luck on your endeavor and welcome to the programming
| languages club."
| bsedlm wrote:
| what or who is Kelly?
| bionade24 wrote:
| Andrew Kelley, the initiator of Zig
|
| Edit: name spelling
| cassepipe wrote:
| Kelley btw
| [deleted]
| v8dev123 wrote:
| I'm leaving HN and it's echo chamber all together. HN has no
| basis with reality. Bye!
| FnControlOption wrote:
| Your account has only been registered for 30 days...
| einpoklum wrote:
| > Hannah: How is it possible that Zig applications run faster
| than C code while also having far better security guarantees?
|
| In a marketing interview with biased questions, anything is
| possible.
|
| TBH, I have a positive impression of zig, but this kind of
| interviewing doesn't help it.
| pjmlp wrote:
| Indeed, Zig still hasn't a story for use after free issues.
| MaxBarraclough wrote:
| Not sure what 'story' is intended to mean here. Is use-after-
| free undefined behaviour in Zig?
| AnIdiotOnTheNet wrote:
| There isn't really anything in the language that prevents
| use-after-free, partially because allocation isn't even
| part of the language and exists entirely in userland code.
| However, IIRC the standard library does include an
| allocator that tries to detect use-after-free.
| Ar-Curunir wrote:
| Allocation isn't part of the core language in Rust
| either, yet it prevents use-after-free generically via
| RAII
| yakubin wrote:
| Currently I'm using Rust in a project without RAII. RAII
| is neither necessary nor sufficient to prevent use-after-
| free. In Rust use-after-free is prevented by the borrow-
| checker. In C++ with RAII use-after-free is still
| possible, because normal references aren't tracked with
| regard to the lifetime of pointees.
| pjmlp wrote:
| Microsoft and Google are trying to improve it via
| lifetime analysis, but after 3 years it is still pretty
| much WIP due to C++ semantics.
| skohan wrote:
| Isn't that an intentional design decision in Zig? As far
| as I understood, Zig isn't trying to "solve" memory
| management, it's trying to provide manual memory
| management with better tools than C to help you do it
| right, but it's explicitly _not_ trying to save you from
| yourself in this respect.
| pjmlp wrote:
| Except that C and C++ already provide similar tools, one
| just needs to actually enable them.
| MaxBarraclough wrote:
| I don't follow. You recently pointed out to me that most
| of the serious security bugs in the Chromium codebase
| (C++) are rooted in memory-management. [0] It's no simple
| thing to fix these bugs. Not even Google can do so in
| their most treasured code.
|
| [0] https://news.ycombinator.com/item?id=26862330
| pjmlp wrote:
| The point being that Zig improves very little regarding
| that, because it is based on the same kind of tooling.
| creata wrote:
| You don't need allocations to be part of the language,
| you just need destructors (or linear types.) But the Zig
| authors intentionally omitted destructors because they
| want all control flow to be explicit. There's more at
| [0].
|
| Side note: the proposal at [0] seems very close to [1].
|
| [0]: https://github.com/ziglang/zig/issues/782
|
| [1]: https://www.haskellforall.com/2013/06/the-resource-
| applicati...
| matheusmoreira wrote:
| > allocation isn't even part of the language
|
| It's not supposed to be. In most cases, memory allocation
| is an operating system concept. As a systems programming
| language, zig must not abstract this away from the
| programmer.
| blueblob wrote:
| Is use-after-free ever really defined behavior?
| matheusmoreira wrote:
| Yes. Undefined behavior exists only in standards. It's
| perfectly possible for implementations to define
| everything.
|
| https://www.joelonsoftware.com/2004/06/13/how-microsoft-
| lost...
|
| > I first heard about this from one of the developers of
| the hit game SimCity, who told me that there was a
| critical bug in his application:
|
| > it used memory right after freeing it, a major no-no
| that happened to work OK on DOS but would not work under
| Windows where memory that is freed is likely to be
| snatched up by another running application right away.
|
| > The testers on the Windows team were going through
| various popular applications, testing them to make sure
| they worked OK, but SimCity kept crashing.
|
| > They reported this to the Windows developers, who
| disassembled SimCity, stepped through it in a debugger,
| found the bug, and added special code that checked if
| SimCity was running, and if it did, _ran the memory
| allocator in a special mode in which you could still use
| memory after freeing it._
| [deleted]
| MaxBarraclough wrote:
| That would depend on the language and the libraries.
|
| You could roll your own 'safe' memory pool in C such that
| use-after-free doesn't produce undefined behaviour. You'd
| still have a bug, but it wouldn't have to invoke UB at
| the level of the C programming language.
| smasher164 wrote:
| The question is if this should be done at the language-level
| or library-level. With sufficient metaprogramming
| capabilities, an enterprising programmer could write safe
| resource management abstractions for Zig. However, this
| wouldn't make the language "safe by default," which seems to
| be what Rust programmers are bringing with this criticism.
|
| Even if Zig doesn't bring safety by default to the language,
| however, I think you could get it in practice by making the
| standard library enforce safety. Then, unless someone goes
| out of their way to write their own libraries from scratch
| and eschew all of the safety mechanisms, they would likely
| live in this safety bubble.
| pcwalton wrote:
| Can you write a borrow checker that enforces alias-xor-mut
| using metaprogramming? I'm skeptical, because of the flow
| sensitivity you really want to make it practical.
| smasher164 wrote:
| Not sure, but I became optimistic of there being _some_
| solution after I saw someone implement affine typing
| using stateful template metaprogramming:
| https://godbolt.org/z/PnPPrnPjY.
| pcwalton wrote:
| That's neat, but also flow-insensitive (and wow,
| generating a definition for every single _use_ of a
| variable can 't be good for compile-time memory usage).
| smasher164 wrote:
| Yeah, I'm unaware of any push to bring flow-sensitive
| typing, or a mechanism that affords flow-sensitive
| analysis, to Zig.
| pron wrote:
| You could with some changes to the type capabilities, but
| I don't think that's the right direction. The main
| question is do we want soundness or not? This is a
| general question for various correctness properties, and,
| at least in the formal methods space, the answer seems to
| be "not always." Soundness has a cost, and stopping 100%
| of UAF bugs for the cost of making the language more
| complex and even adding a few bugs of other kinds, might
| not be worth it if you can stop 99% of them for a
| fraction of the cost. I think the goal should be to not
| have soundness -- IMO it has more downsides than upsides
| in this case -- and make good runtime detection joined
| with fast compile/test cycle and even automatic test
| generation.
| pcwalton wrote:
| I mean, you're essentially saying here that memory safety
| is not worth having, which is a position increasingly at
| odds with the evidence.
| pron wrote:
| Not at all. I'm saying that sound guarantees are not the
| only way to achieve memory safety. The goal isn't to use
| a language that makes sound guarantees, but to write
| correct _programs_ (even Rust programs don 't give you
| sound guarantees for memory safety as many of them depend
| on unsafe code that isn't soundly proven). That the
| cheapest way to write such programs is to have sound
| guarantees for everything is an interesting hypothesis,
| which would get you a language like, say, Idris, but it
| is not the consensus. There are many paths to safety and
| correctness, and not all of them go through soundness.
| I'd venture to say that most properties your life depends
| on in safety-critical systems are not soundly guaranteed.
| pcwalton wrote:
| When I say "memory safety" I mean "language-enforced
| memory safety". You're saying that having the language
| enforce memory safety isn't worth it.
|
| > even Rust programs don't give you sound guarantees for
| memory safety as many of them depend on unsafe code that
| isn't soundly proven
|
| Yes, and there are also bit flips caused by cosmic rays.
| But the point is that the evidence suggests that
| language-enforced memory safety is actually worthwhile.
|
| > That the cheapest way to write such programs is to have
| sound guarantees for everything is an interesting
| hypothesis, which would get you a language like, say,
| Idris, but it is not the consensus.
|
| Straw man. Nobody is talking about proving all code
| correct. What _is_ reasonably describable as consensus
| nowadays is that having the language enforce memory
| safety is worthwhile.
| bsedlm wrote:
| I like to think Zig is what we would have if we knew back then
| (when desiging C) what we know now.
|
| (note: "we" excludes me personally but I mean it as "us who
| work and study comptuing at large")
| not2b wrote:
| The difficulty is that in the days when C was being designed,
| computers were much more irregular than they are today. There
| were one's complement machines, machines that didn't have
| power-of-two word sizes, no standardization of character
| sets, IEEE floating point hadn't been invented yet. The
| irregular machines weren't fringe stuff, they were the
| dominant architectures (IBM 360/370, DEC PDP-10, Pr1me, just
| a big collection of weird stuff). And compiler technology was
| much less advanced. So C was a messy compromise.
| dnautics wrote:
| Iirc, C was also designed by committee, and a lot of
| industry players got some of their grubby hands on the
| spec... (I could be wrong) but I belive the utter mess that
| is short/long/char sizes arises from hardware manufacturers
| wanting their code to be "trivially portable" across
| platforms with different machine words.
| not2b wrote:
| No, the different sizes were done by the original
| creators, not by some committee. They had to: a PDP-11 is
| a 16-bit machine, a PDP-10 is 36-bit, etc.
| pjmlp wrote:
| High level system programming languages are about 10 years
| older than C, which in its early days only cared to target
| the PDP-11 model used for the first UNIX rewrite.
|
| Authors just chose to ignore what was already out there and
| do their own thing instead.
|
| UNIX's success in the universities made the rest.
| pjmlp wrote:
| We already knew in 1981.
|
| "Many years later we asked our customers whether they wished
| us to provide an option to switch off these checks in the
| interests of efficiency on production runs. Unanimously, they
| urged us not to--they already knew how frequently subscript
| errors occur on production runs where failure to detect them
| could be disastrous. I note with fear and horror that even in
| 1980, language designers and users have not learned this
| lesson. In any respectable branch of engineering, failure to
| observe such elementary precautions would have long been
| against the law."
|
| C.A.R Hoare on his Turing award speech in 1981.
| skohan wrote:
| > There is no big company behind Zig, and the non-profit
| foundation stands on its own legs thanks to a balanced mix of
| corporate and individual donations. We don't have any big tech
| company on our board of directors, and frankly, we like it this
| way.
|
| I hope it stays this way. And maybe it can given the way the
| foundation has been bootstrapped, and that the project is driven
| largely by a single creator. Having the funding be driven largely
| by small donations of actual developers is a healthy incentive
| structure.
|
| Zig, next to Rust, is one of the more interesting language
| projects going on these days. Since Rust became orphaned from
| Mozilla, I am a bit ambivalent about the amount of investment in
| the project which is being driven by tech giants currently.
| oblio wrote:
| Is there a popular language without investment from tech
| giants?
| scrollaway wrote:
| I mean at some point, if the tech is good, tech giants will
| use it. And then you'll have a flurry of people rambling in
| shock "Wow, Google depends so much on [tech] and they don't
| even give a single penny to the devs!".
|
| Programming languages getting a bunch of investment from its
| users is open source working possibly at its best.
| stephc_int13 wrote:
| A some point, I think this is inevitable.
|
| And to be honest, I don't care that much about who is behind
| a tech, as long as they are making the right choices. (except
| if it is Apple)
| jacobmischka wrote:
| The title made me think it was going to be about creating a _new_
| language using Zig to build the compiler. I 'm glad that wasn't
| the case.
| UncleOxidant wrote:
| That's what I thought it would be about as well - not a great
| title. I kind'a wanted to read about creating a new language
| using Zig.
| EamonnMR wrote:
| Does anyone have a link to a good zig book/tutorial? I keep
| seeing it and want to try it out.
| jedisct1 wrote:
| https://ziglearn.org is a nice way to start!
| stephc_int13 wrote:
| The language has not reached 1.0 yet, it would be silly to
| write a book at this stage.
|
| You can find documentation on the language website, also there
| is an active community and you can ask questions direction on
| Discord.
| bsedlm wrote:
| as far as I can tell, none really good ones exist yet...
|
| the documentation is still scattered. The official website [1]
| is a good starting point. and I wish I'd seen this [2] earlier
| (I hope this gets incoporated into the official resources)
|
| [1] https://ziglang.org/learn/
|
| [2] https://www.lagerdata.com/articles/an-intro-to-zigs-
| integer-...
|
| This is probably the most comprehensive resource:
| https://ziglang.org/documentation/master/
| bionade24 wrote:
| https://github.com/ratfactor/ziglings
| lackbeard wrote:
| Start with Ziglings: https://github.com/ratfactor/ziglings and
| then after working through all the exercises read chapter 2 of
| ziglearn.org.
| okareaman wrote:
| As a C programmer, I didn't like that Zig just gets rid of
| macros. I prefer the Rust approach to make better macros.
| CheezeIt wrote:
| One big benefit I see is that it increases design pressure on
| other features of the language.
| stephc_int13 wrote:
| I think they also have better macros, with compile time code
| evaluation.
| pierrebai wrote:
| There are many erroneous claims made regarding Zig allocators.
| Contrary to what is claimed, the fact that you pass an explicit
| allocator does _not_ affect: - That an out-of-
| memory condition is elegantly handled or not. - That an
| out-of-memory condition is properly reported to the caller.
| - That is simplifies WebAssembly support; whatver you put in the
| allocator your could put into malloc. - That it easily
| allows arena allocators; you can only use an arena allocator if
| you intimately know every single uses of the passed in allocator,
| allo the implementation details of the libraries you call and of
| *all* its dependencies. If a dependency, for example, implements
| a cache, the arena allocator will corrupt it when deallocated.
| stephc_int13 wrote:
| I am rarely impressed by new languages, I tend to think we
| already have too many, a lot of them are slow and or redundant.
|
| But I like to see the emergence of a few sane proposals to
| replace C/C++, I've been extremely impressed so far by the work
| done by the team behind Zig.
|
| The best feature, from my perspective, is that Zig does not
| intend to be a better C++ but a better C.
| ta_ca wrote:
| my _only_ beef with zig /jai is that they both have strong
| opinions on things like operator overloading and i am afraid
| they will end up just like java.
|
| i have nothing against having strong opinions, i am the biggest
| offender but completely disallowing some features, some of the
| best features static typing can offer is just nonsense.
|
| every language designer should study common-lisp and start with
| the operators : and :: these two operators alone tell you that
| the language designed for practical use.
|
| for me overloading the operator + and function 'add' is exactly
| same. you should then forbid function overloading as well now.
| you can argue about the weakness of operator overloading but
| disabling completely, not even a workaround?
|
| why not just enable oo and have _safe_ alternatives instead? .
| safe(a + b) . a s+ b
| AndyKelley wrote:
| quoting myself [1]:
|
| "It's really easy to make fun of C++, but everyone has that
| one feature of C++ that they like. And they want to put it in
| Zig. If everyone had their favorite feature from C++ in Zig,
| Zig would just be C++. But I'm not going to let that happen."
|
| https://youtu.be/Gv2I7qTux7g?t=454
| ta_ca wrote:
| andrew,
|
| a language with first class cross-compilation alone is
| enough for me to respect you as a language designer and zig
| have so many features like this. i am a huge fan.
|
| i have only one favourite feature in c++ and it is
| templates/ctfe. without the function/operator-overloading
| templates are incomplete, i would then use c instead. i am
| still using c++ with all its failures, with all its
| complexity, with all its uglyness|ineleganceonly because
| c++ got one thing right. you can at least somehow modify
| the language.
|
| edit: i have to point out that i have never worked in a big
| team (more than 10) and you can (probably should) safely
| ignore my ideas/opinions.
| stephc_int13 wrote:
| In my opinion, operators overloading could be safely used if
| they were explicit.
|
| With something like that:
|
| var x = a [+] b;
|
| There is no possible mistake.
| dnautics wrote:
| proposed and rejected. I went to a lang meeting and tried
| to steelman the issue, without having a strong investment
| either way (I had one use case, where I would slightly
| prefer the infix operation).
|
| https://github.com/ziglang/zig/issues/8204
| stephc_int13 wrote:
| Good to see it was discussed :)
|
| It is probably better to have native support for small
| vector operations, as this can also help to streamline
| SIMD optimization.
|
| In practice (as a video game dev) I only use operators
| overloading to have infix notation on vector maths.
| skohan wrote:
| Yeah gamedev/simulation is the use-case where I think
| operator overloading is really a value-add. It's really
| nice to be able to write linear algebra code which reads
| like math.
| david2ndaccount wrote:
| Pretty sure jai has operator overloading as it is intended
| for games and being able to add two vectors is something you
| want to do all the time.
| stephc_int13 wrote:
| Operator overloading is something that has often been
| misused, and even if I tend to like syntactic sugar, I
| understand that being explicit is more important.
|
| When trying to understand a codebase, it is much easier to
| not worry about hidden indirections.
| ta_ca wrote:
| but you can misuse anything, + vs add was an example for
| this.
|
| being able to misuse a PL i believe is not a bug but a
| feature. we really suck at predicting the future.
| stephc_int13 wrote:
| This is not the role of langage designers to prevent bad
| programmers to write bad code.
|
| But it is better to avoid giving them too many ways to
| shoot themselves in the foot.
|
| Forcing the code to be explicit is good design, in my
| opinion, simply because it is much easier to write code
| than to read it, we have to put more weight on the
| clarity side.
| blacktriangle wrote:
| Is your point with the ':' and '::' operators that by
| allowing anybody to break package encapsulation at will the
| language pragmatically allows for situations that the
| original package designer did not anticipate? I could see
| that.
| ta_ca wrote:
| that is exactly my point. it has everything. elegance,
| vision, practicality... it doesn't treat programmers like
| drones.
| stephc_int13 wrote:
| My concern about zig/jai and others, is meta-programming.
|
| Meta-programming can be super powerful and practical, and the
| current trend of reusing the language itself is clearly
| better than previous attempt.
|
| But meta-programming in itself is not a novel idea, C macros
| and C++ templates are past well studied examples, and both
| produced awful results.
|
| I am not sure they can prevent a new cycle of this nightmare.
| ta_ca wrote:
| in fact i believe templates are the greatest idea in static
| typing. they look awful because its design and the
| implementation is awful not the idea. c++ failed because
| they didn't know and too late to turn back, and rust just
| looks same, you should see d-templates.
| stephc_int13 wrote:
| I think that templates can be practical and readable if
| used with moderation, just like macros.
| skrtskrt wrote:
| Maybe I am just a huge dummy, but I have yet to find
| examples of metaprogramming in the wild that aren't just
| mind-meltingly hard to grok. (Most of what I have seen is
| Python and Rust).
|
| I have no doubt about how powerful metaprogramming is, but
| it makes me feel that understanding and contributing to
| libraries that use it is out of my reach.
| skohan wrote:
| I think what's novel about Zig's approach is that the
| metaprogramming is just normal code which happens to be
| executed at compile-time.
|
| I have found that when any project gets to a certain
| size, it's almost inevitable that metaprogramming will be
| required, unless you want to make everything super
| dynamic and sacrifice performance. The idea of being able
| to do metaprogramming in the language I used to write the
| program itself is an interesting one.
| _dps wrote:
| I don't know if Kelley would agree with my
| characterization, but I don't see comptime as
| metaprogramming. Instead it opens the very interesting
| possibility of having types as values, as long as those
| values are resolvable at compile time. This lets you do
| things that feel like metaprogramming (e.g. making a
| generic container structure) but it seems a better
| conceptual fit to me that you're programming with types
| as values rather than generating code from a template or
| macro.
___________________________________________________________________
(page generated 2021-05-13 23:01 UTC)