[HN Gopher] Game Jam 2 Results
___________________________________________________________________
Game Jam 2 Results
Author : eggy
Score : 166 points
Date : 2022-09-09 10:43 UTC (12 hours ago)
(HTM) web link (wasm4.org)
(TXT) w3m dump (wasm4.org)
| gorjusborg wrote:
| It would be awesome to understand the reasons zig was utilized.
|
| My guess is that it is about the language tooling, but it would
| be nice to hear from the authors themselves.
| galangalalgol wrote:
| Looking at the top 5 they used zig,zig,rust,odin,asmscript
|
| Rust is the highest level represented. I'm guessing the level
| of control needed to hit the tight constraints of wasm-4
| preclude anything that you wouldn't use for a microcontroller.
| C and c++ would work too, but what fun is that?
| quic5 wrote:
| I can only speak for myself here but of all languages I've
| tried for WASM-4 (WAT, C, Rust & Zig) it is the most productive
| one for me.
|
| I really enjoy the balance of safety and control in Zig. I can
| build using Debug mode during development, turning nearly all
| my bugs into crashes which are easily fixable using in-browser
| source-level debugging. But in Release-Small mode the result is
| fast and more importantly really small since there's a 64kb
| cartridge limit.
|
| Another factor is the Zig Standard Library which designed to be
| portable and usable on freestanding targets. I can not
| emphasize enough how pleasant this is. For example I can just
| use a `std.heap.FixedBufferAllocator` to back a `std.ArrayList`
| with no problem.
|
| The comptime feature of Zig also comes in handy when you have
| to minimize code size.
|
| The seamless C interop furthermore improves my productivity
| since I can just use any C code I like. I've used a C perlin
| noise library in a previous game for example, saving me a lot
| of time.
|
| Plus I've used Zig for the previous WASM-4 jam and just liked
| it so I didn't bother trying any other language.
| dom96 wrote:
| My guess is it comes down to how much the Zig community (in
| particular I've seen Zig's VP of community mention it) has
| advertised it.
| kristoff_it wrote:
| Yeah, I did. The previous WASM-4 Jam had Zig and C tie at the
| top followed by Rust. Other languages also had more
| representation than in this last one, maybe also because of a
| greater overall number of entries (44 total).
|
| https://youtu.be/7ydnjX999kk?t=894
|
| I also think that there is a correlation between the majority
| of participants being from Europe and Zig. At the moment
| almost all our meetups are in Europe.
| [deleted]
| Tepix wrote:
| The harsh restrictions sure spur creativity!
|
| On the other hand, is the SNES " _The Legend of Zelda: A Link to
| the Past_ " style everyone's favourite pixel art style, or is it
| just me? Without tricks it did 256 colours of of 4096 in Mode 7.
| You can't do art that's as pretty with four colours. Is it a
| restriction that's too harsh or are we ok with games that just
| aren't very pretty?
| rcarmo wrote:
| 26 or so data points, but still interesting. I myself have become
| enamored with Zig's relative simplcity and straightforwardness,
| although some of my friends keep telling me to do Rust instead.
| newaccount2021 wrote:
| eggy wrote:
| Yeah, not a lot of data points, and a niche subject, game dev,
| but I am playing with the Mach game and graphics engine, and so
| far so good. I started programming in 1978 in CPM Basic, C,
| 6502 assembler, etc. I play with Rust, but if I am really
| looking for high-integrity software, I am currently using
| SPARK2014 (the subset of Ada), that has some legs beneath it.
| Rust and AdaCore are starting to work together to bring some of
| this into Rust, but it's not there yet. So for me, Zig is my C
| replacement, and SPARK2014 is my C++/Rust replacement. You can
| go low-level with SPARK2014 too, and IMHO, it is far easier to
| understand than Rust, yet it already has all the high concepts
| of software integrity, safety, and verifiability. Excited about
| cross-platform graphics and performance with Zig and Mach.
| pcwalton wrote:
| How is Spark2014 easier to understand than Rust? The
| borrowing rules [1] are more or less the same.
|
| [1]: https://docs.adacore.com/spark2014-docs/html/ug/en/sourc
| e/la...
| eggy wrote:
| Perhaps "understand" was the wrong word given I meant for
| me to understand. I have a C background and Pascal as well
| as assembler back in the day (late 70s/early 80s). I dove
| into Ada/SPARK2014 and picked it up much quicker than Rust.
| Ada has been around a lot longer than Rust, so I think it's
| syntax allows for a clearer readability even if they have
| similar borrowing rules. If I had my druthers I'd be
| programming in APL or J all the time, so take what I find
| clearer with a grain of salt. There wasn't as much
| tribalism around PLs as there is nowadays. I guess people
| stake a lot of emotion on what they have chosen as their
| main language or programming paradigm they may have
| committed so much of their time learning. I still recommend
| Ada/SPARK2014 to anyone who asks me about verifiable or
| high-inegrity software with a follow on comment to keep an
| eye on Rust especially with Adacore and Ferrous Systems
| teaming up to help Rust get there.
| pryelluw wrote:
| Thanks for sharing. Going to enjoy some time with Spark2014.
|
| OT: Searching for Spark2014 brings up a lot of results about
| the 2014 Chevrolet Spark. A shit box of a car of there ever
| was one.
| eggy wrote:
| Hah, Chevy Spark, and it's a gasoline car!
|
| I usually put "SPARK2014 programming" or "SPARK2014 Ada" in
| my searches. I used to get annoyed by all of the Apache
| Spark stuff that came up, but that seems to have waned a
| bit this past year or two.
|
| Vermont Technical College (VTC) used SPARK2014 to program
| their CubeSat and the book, "Building High Integrity
| Applications with SPARK"[1] is a great intro to it in a
| nice context of practical use.
|
| There was also an article on the AdaCore site about someone
| who rewrote some drone firmware in SPARK2014, which is
| another nice real-world application. [2]
|
| [1] https://www.amazon.com/Building-High-Integrity-
| Applications-...
|
| [2] https://blog.adacore.com/how-to-prevent-drone-crashes-
| using-...
| unwind wrote:
| Gasoline cars have sparkplugs, so it's not really a
| strange association. At least not in my opinion.
|
| In fact, I guess in gas cars sparks are "better" since
| they are engineered in, and doing useful work.
| eggy wrote:
| I didn't say it was strange. I found it amusing that this
| is what came up during the other person's search for
| SPARK2014, and yes, thinking it sounded like a suitable
| electric vehicle name. Chevy called their electric
| offering Volt, and Volts are in the battery in a gas car
| too, but I think you get the picture.
| cardanome wrote:
| For me Rust is a language that I would absolutely love to work
| with in a professional context. The type system and borrow
| checker have your back and help you make changes to the code
| without fear of accidentally introducing any regressions.
|
| For private lone-hacking projects though it feels way too
| complex and opinionated. Here Zig definitely gets closer to
| what I need, though sadly it made unused variables an compiler
| error (curse you golang for making that popular) which is super
| annoying for prototyping.
| vanderZwan wrote:
| I never understood this attitude, it's not like commenting
| out variables is difficult.
| bluGill wrote:
| It isn't difficult, but it is friction. You hit compile and
| a few seconds later you get an error that is unrelated to
| the change you wanted to test. I agree with all those
| errors once those changes are for production, but sometimes
| I wish the compiler would just shut up and let me test the
| actual change I just made to ensure it works.
|
| Commenting out a few variables isn't always easy either.
| Every try to add const to a legacy C++ project - it can
| take days to fix all the errors resulting from adding const
| to something that clearly is const in usage. I don't know
| zig, but I wouldn't be surprised if sometimes you get into
| this type of situation in a large code base (does anyone
| have a very large code base in zig yet?)
| vanderZwan wrote:
| > _It isn 't difficult, but it is friction._
|
| Only until getting rid of unused variables becomes a
| habit before you hit the compiler. Which is a good habit
| to have anyway.
| rcxdude wrote:
| it's still friction when it's a habit, there's a
| cognitive overhead to tracking that every time you make a
| change.
| hota_mazi wrote:
| Good habit, maybe, but it shouldn't cause a compilation
| failure.
|
| Add to that the snowball effect: you comment out a
| variable, compile, and you get another error because
| commenting out variable a made variable b unused. Rinse
| and repeat.
|
| It's a huge and totally unnecessary time sink.
|
| It should be opt-in, so that it's a warning by default,
| and then, when I'm ready to push my code, I could run
| some --strict mode that would force me to clean up my
| code.
| NyxWulf wrote:
| One of the features in go that makes it workable is you
| can assign it away via: _ = somevar
|
| That eliminates the unused chain problem. Not sure if zig
| included that part of the feature as well.
|
| Generally I agree though. The main problem with forcing
| unused variables, imo, is that it forces you to _think_ a
| certain way. When I 'm exploring the solution space on
| something, those constraints feel inhibiting.
| simion314 wrote:
| >it's not like commenting out variables is difficult.
|
| But if you comment var A that uses var B now B is unused
| and you need to commnet B, but now B was using a function
| parameter C and this param is unused now so you need to
| update the function signature (I do not use Go,Zig so maybe
| they did not forced you to also use all the function params
| my experience is with linters where ehwn you comment
| something then more unused warnings appear)
| vanderZwan wrote:
| Wow sounds like you really need to clean up your
| codebase.
|
| Seriously, I have _never_ had this problem while coding
| in Go, and I 'm a very very sloppy coder.
| simion314 wrote:
| As other said, it is not a good practice so inline all
| the code, I prefer well named variables, and I assume you
| can find examples in your code where you have a local
| variable that depends of a function parameter.
|
| Funny enough I was correcting my son c++ homework
| yesterday, he had a complex if statement like
|
| if (somefunction(m,n, y[j]) == m[j])
|
| and I made him make a local variable to make it clear
| what is happening. then the code was easier to understand
| and debug because we culd print that local variable and
| see if is fine.
|
| Btw, try not too respond that smug, you proved that you
| are an inexperienced coder and a shit person.
| vanderZwan wrote:
| I'm not so sure about that one, despite clearly being in
| the company of people who _feel_ attacked, _I 'm_ not the
| one attacking people here. I'm commenting on code
| practices, and baffled at other people's rage about the
| compiler demanding that you don't have unused variables,
| but I haven't attacked anyone.
| simion314 wrote:
| You commented about my code quality, but I will assume
| you were in a rush and missunderstood that I was talking
| about work in progress stuff and debugging, so if that
| was teh case I apologize (if is not the case then you
| might understand in a few years)
| spoiler wrote:
| What are you talking about? I don't understand how you've
| never encountered variables depending on each other.
|
| In any moderately complex function you'll have more than
| one expression, and those can depend on each other. And
| you want them to be named and assigned; it makes it
| easier to read and decode intent and debug things (unless
| you're one of those wizards who get it right on the first
| try every time, kudos to you then). I'd not approve a PR
| that inlines/embeds complex concepts within larger
| expressions just to avoid creating variables...
|
| Edit: typos
| vanderZwan wrote:
| Of course I have encountered dependent variables, but if
| I have a _long chain of unused variables_ that means that
| either that code is ready to go, or the code organization
| needs refactoring.
| afiori wrote:
| At first you have a long chain of _used variables_ that
| end up into a value used somewhere.
|
| If then you refactor away that single final value you
| need to delete all the previously used variables that now
| need to be "deallocated" by you.
| simion314 wrote:
| Dude, it is about debugging, or work in progress...
|
| Did you ever tried to debug some issue and start
| commenting stuff to try and find the problematic area?
| Hell when I comment stuff soemtimes private function will
| get unused , so with a shit compiler you would need to
| also comment the private functions, remove unused classes
| etc.
|
| In my code I assure the linter will say 0 warnings.
| hhmc wrote:
| You seem to be missing the whole point being made -- they
| are unused because of (temporary) changes during
| _prototyping_.
| vanderZwan wrote:
| Ah yes, prototyping. The stage of coding where one has
| lots of snippets of code meant for trying things out
| quickly. Definitely a context full of long chains of
| dependent variables.
| hhmc wrote:
| One might imagine prototyping new functionality in a
| existing, complex, codebase..
| xmonkee wrote:
| I am seriously mind-blown that you've never encountered
| this problem in Go. You're trying something, and you see
| an error, you comment out a function and replace it with
| a print statement. And now suddenly you have to comment
| out a bunch of things up to the import statement just to
| fucking test out a simple hypothesis.
| nindalf wrote:
| Possibly because the IDE helps with that. Including
| adding and removing import statements. I feel like this
| complaint is more theoretical than something felt by
| people using Go day to day.
| anothernewdude wrote:
| I just want the quick edit to test something to be quick.
| oflor wrote:
| It's not difficult, but it's disrupting to your coding
| flow, which is bad in itself and even worse when
| prototyping.
| throwawaymaths wrote:
| More disrupting than a really slow compiler?
| adgjlsfhk1 wrote:
| allowing undefined variables doesn't slow down the
| compiler.
| TakeBlaster16 wrote:
| Yes. If Zig takes 100ms to compile, and Rust takes 2s,
| but you just spent 20 seconds commenting unused vars in
| your Zig code, then the slow compiler comes out ahead.
| It's a great example of how good UX can be more important
| than raw performance numbers.
| throwawaymaths wrote:
| Yes, but you comment out unused variable _once per
| variable_ (you can leave those underscores in and clear
| them out before release). The 2s happens _every time you
| compile_. The badness of slow compiles is non-linear,
| too. As you start to get to 30s, the likelihood that you
| check Facebook, Twitter, or hn goes up. At least when you
| 're underscoring unused vars you're doing something
| _active_.
|
| If it gets to 2-5 minutes the likelihood that you stop
| writing tests and rely on the compiler for bugfreeness
| goes up - or the likelihood that you create debt by
| increasing the complexity of your code organization.
| alpaca128 wrote:
| > (you can leave those underscores in and clear them out
| before release)
|
| You can leave those "unused variable" warnings and fix
| them before release
|
| The difference is that warnings are visible, the
| underscores however suppressed the compiler's ability to
| help you.
| TakeBlaster16 wrote:
| Strawman. Incremental compile times don't hit 2-5 minutes
| in either language, otherwise it obviously wouldn't be
| viable for real-world use.
|
| And juggling variables was an ongoing ordeal when I
| tried. I can't imagine how you would work on code without
| changing any of the variables.
| throwawaymaths wrote:
| It's really not a problem for me. I've worked on probably
| about 20k LOC of zig. Probably the one time it was an
| issue was when I wrote some code that wrote zig -- and
| then it pushed me into realizing that this was a code
| smell, and a refactoring fixed it.
|
| Compile times of 2-5 minutes can happen in langs that are
| not rust. You mentioned rust, not me. And anyways the 30s
| to hn thing is real.
| rcxdude wrote:
| It is a truly bizarre decision for a language which aims to
| have a fast change->compile->run cycle, since it can
| basically double the time the compile cycle takes.
| xedrac wrote:
| Yeah, I would like a flag that makes the compiler as loose
| as possible, maybe something like "-fprototype". Then when
| I'm ready to get serious about correctness, I can remove
| the flag and be all pedantic.
| TakeBlaster16 wrote:
| That's the one thing keeping me from considering Zig for new
| projects right now.
|
| If some enterprising young developer is reading this and
| wants to make a name for themselves, you should fork the Zig
| compiler and change those errors to warnings. It would be an
| extremely popular project.
|
| EDIT: I'll even give you a catchy project name. Wig: Zig with
| Warnings
| refulgentis wrote:
| You should also consider that optimizing for incorrectness
| and prototyping speed might not be the professionally
| responsible choice in 2022.
| TakeBlaster16 wrote:
| "Optimizing for incorrectness" is a funny way to describe
| the practice of enforcing lint checks as part of a CI
| pipeline.
| refulgentis wrote:
| You're right, the provocation here is _engaging in
| intentionally choosing a language, and choosing Zig, is
| optimizing for incorrectness_. I didn 't mean the flag.
| suby wrote:
| I also misinterpreted the comment. Either way, I don't
| see the harm in optimizing for prototyping speed. It's
| orthogonal to the safety issues.
| alpaca128 wrote:
| Unused variables don't make a program incorrect. When you
| comment out unused variables to prevent Zig's compiler
| error you don't remove the dead code, you in fact make it
| more likely to stay in the codebase because now it's only
| visible to humans. While almost every other language will
| print out a clearly visible warning without disrupting
| the workflow.
|
| I can only see downsides and no upside in this design.
| Why would you slow down the development workflow for
| something any decent compiler will discard as basic
| optimization step? It's an error about something that has
| absolutely no impact on the resulting program and its
| execution, you can probably find a dozen better reasons
| for Zig to throw errors where it doesn't.
| AndyKelley wrote:
| You're not alone.
|
| Fridays are my live streaming day and I've chosen today's
| topic to be the user experience of unused variable errors.
| I have an idea to solve this that can satisfy both parties
| - those who don't want to be bothered by such errors, and
| those who want the premise upheld that if Zig code
| compiles, it does not have any unused variables.
|
| In approximately 60 minutes I'll go live on
| https://www.twitch.tv/andrewrok/
| nicoburns wrote:
| There's actually already a patch for this posted on the
| github issue. It's only about a 5 line change.
| TakeBlaster16 wrote:
| The patch works, but it's not efficient to have every
| user patch their own compiler on every release (and forgo
| the system package manager for upgrades). I was also
| envisioning adding a warning system, changing the checks
| to warnings instead of removing them completely, and
| adding a `-Werror` flag (or maybe `-Wno-error`). It would
| be a bit more than 5 lines, but still relatively low
| effort compared to how impactful the project would be.
| fuu_dev wrote:
| It might be good to add a respectful comment on the issue
| on github to emphasize the UX issues it creates.
|
| issue: https://github.com/ziglang/zig/issues/335
| kristoff_it wrote:
| The current plan is for `zig fmt` to have an optional flag
| that makes it automatically fix unused variables.
| TakeBlaster16 wrote:
| That's just going to result in people committing unused
| vars to their repos. People are already doing that now
| after adding '_'s by hand.
| https://news.ycombinator.com/item?id=32753079 It's going to
| get even more common when underscores are automatically
| added all over your project without user input and you have
| no chance of remembering where they all were.
|
| If the goal of not having warnings is to increase code
| quality, it's actually doing the opposite.
|
| I don't understand this insistence on working around the
| problem by layering on tooling, instead of just fixing the
| problem to begin with.
| [deleted]
| jpbadan wrote:
| From the perspective that development time is a big constraint in
| a game jam it's no wonder zig is more popular than rust
| skohan wrote:
| Arguably Zig is a better fit for game dev. At the high end game
| dev is all about memory layouts and cache optimization, and
| that goal can run counter to Rust's approach to memory safety.
| pcwalton wrote:
| Memory safety isn't in conflict with low-level control over
| memory layout.
| skohan wrote:
| It can just be limiting in terms of ergonomics. Like I've
| implemented a couple of ECS's and what you want to do is
| dispatch a bunch of threads over big swaths of structured
| memory. One of the main things the borrow checker doesn't
| want you to do is use the same memory on multiple threads.
| You _can_ do that in rust, and people have, but you have to
| put a lot of effort into convincing the borrow checker that
| what you 're doing is ok, or else find ways to side-step
| the borrow checker.
|
| So basically rust imposes a lot of limitations on how you
| can structure your program relative to something like Zig
| or C.
| pizza234 wrote:
| Jams can be very fad-driven. I'm not familiar with this jam,
| but Rust's latest game jam was dominated by Bevy, which is a
| very bad choice for quickly writing a game.
| nindalf wrote:
| It was a Bevy jam, organised by the Bevy developers to
| celebrate the new release of Bevy.
|
| It's still early days for Bevy but they're making steady
| progress.
| pizza234 wrote:
| No, it was the Rusty Jam.
|
| Independently of Bevy's progress, a parallel ECS is not a
| good choice for a prototype-like game project.
| anothernewdude wrote:
| I never got my rust wasm build to work without needing JS.
| quic5 wrote:
| Then you will enjoy WASM-4 since it handles the glue code for
| you. There's no JS in you game but the web emulator is
| written in JS
| Existenceblinks wrote:
| All WASM related stuff seems lacking of know-how of WebAssembly
| itself. I want the promise of "language-agnostic". For example, I
| have AST, I want to generate WebAssembly (either text or binary
| format, lets start with .wat), there's only a couple articles I
| found talks about how to map string to wasm's memory or table.
|
| Current situation is it's not language-agnostic as movement, it's
| just c/rust mostly.
|
| So wasm-4 seems to have more interesting examples than the other
| e.g. https://wasm4.org/docs/tutorials/snake/handling-user-input
| titzer wrote:
| This is good feedback for the Wasm community.
|
| Right now I am teaching a VM course on the back-half of the
| Wasm equation: how to build an engine for Wasm. The course is
| about more than Wasm, of course, so there is a lot of content
| about JVMs and dynamic object models, but the projects are
| based around Wasm.
|
| In the future I envision university compiler courses getting
| divided into two halves, either as one course with two halves,
| or two full courses. The first course/half would be entirely
| frontend: parsing, semantic analysis, IR, translation, lowering
| --and the target would be WebAssembly. The second course/half
| would be all about compiling Wasm to machine code. If the
| second course wanted to go more in the VM/runtime direction, vs
| focusing on compilation, it could include the upcoming GC
| extension or a custom extension to have objects.
|
| I think Wasm is the future of code formats and languages, so
| I'd like to move the needle here for PL implementors.
| Existenceblinks wrote:
| > I'd like to move the needle here for PL implementors
|
| You read my mind, yes. That's why I said I have AST.
|
| Is your course private? I'm interested.
| titzer wrote:
| http://www.cs.cmu.edu/~btitzer/cs17-670/fall2022/
| Existenceblinks wrote:
| Ok thank you. At least there is accessible assignment
| project 1-4ab and the https://craftinginterpreters.com/
| good!
| MobiusHorizons wrote:
| Are you trying to say web assembly is not well documented, or
| are you commenting on the state of tooling? It seems to me that
| most compiled languages can target wasm these days (eg c, c++,
| zig, rust, go, .net)
|
| The specifications are open and detailed [1]. Specifications
| like that can be daunting to consume if you want a place to
| start from instead of a complete overview of the landscape, but
| there are tutorials in pure web assembly if you want to get
| started.
|
| [1]:
| https://webassembly.github.io/spec/core/text/instructions.ht...
| Existenceblinks wrote:
| Not tooling. I wrote 8086 assembly before so I remember the
| process of learning data segment / register / byte allocation
| / all kind of interrupt. I would choose a word "applied
| webassembly" (like applied physics) for knowledge that it's
| lacking. c, c++, zig, rust, go, .net you said fall into
| "already application" category to me. It's no point of
| webassembly like no point of assembly when we write those
| languages.
| necovek wrote:
| Zig is not mentioned until the section "Programming languages"
| (including not being mentioned in the original title): please fix
| the title so as not to put too much focus on that.
| Beldin wrote:
| Even worse: not all of them are moved!
| TakeBlaster16 wrote:
| Zig is the new HN clickbait, taking over Rust's spot. That's a
| good sign for the language, honestly
| Ygg2 wrote:
| How long till we start complaining that Zig followers are
| cult like?
|
| Asking as Rustecean.
| [deleted]
| infamouscow wrote:
| I've noticed people that like writing code in Zig are fans
| the language and the people that like writing code in Rust
| center their identity around the language. The former leads
| to people saying they enjoy writing code in Zig, the later
| leads to religious zealotry and moral condemnation for
| using anything other than Rust.
| ameixaseca wrote:
| Not sure which lens you are using for coming to this
| conclusion. In my experience, most people writing Rust
| code have no "moral superiority" and treat Rust as a
| "better tool", not as a religion per se.
|
| However, what I've seen in the discourse of several
| programmers that claim to prefer Zig is the assumption
| that Rust is "not really that big of a deal". There's a
| constant minimization of the advancements both the
| ownership system and the safety approach provide, and a
| lack of recognition for the fact that the language is a
| "game changer" in the industry.
|
| Overall, this looks a lot like rationalization of an
| emotional choice, which for me is much more close to
| religious zealotry.
| kristoff_it wrote:
| > However, what I've seen in the discourse of several
| programmers that claim to prefer Zig is the assumption
| that Rust is "not really that big of a deal". There's a
| constant minimization of the advancements both the
| ownership system and the safety approach provide, and a
| lack of recognition for the fact that the language is a
| "game changer" in the industry.
|
| I think you have inadvertently worded this in a way that
| silently confirms what the parent poster was saying. But
| more generally, while I can't speak for the entirety of
| the Zig community, the people involved with Zig directly
| tend to be aware of Rust's strengths. The problem is that
| one of the reasons why Zig exists (and is having some
| level of success) is because some people just don't want
| to deal with abstraction-heavy code. Some people value
| simplicity over a complex language with a memory-safe
| subset.
|
| And the value of simplicity is not just a matter of
| aesthetics. Simplicity is a defense against bugs, because
| memory safety is not the end goal, correctness is.
|
| https://twitter.com/croloris/status/1568342336580755456
| davidjfelix wrote:
| Which language is the one where you make sweeping
| generalizations?
| hu3 wrote:
| It's funny you say that when a rustacean just posted
| below that it is irresponsible to use unsafe languages.
|
| Instead of focusing on tradeoffs they chose to call
| others irresponsible.
| tadfisher wrote:
| That comment does not mention Rust.
| TakeBlaster16 wrote:
| > It's funny you say that when [member of group] just
| [did something once]. It's not a sweeping generalization!
| They always do this!
| pcwalton wrote:
| It's perfectly reasonable to take the position that it's
| deeply problematic for a language aiming for wide use in
| 2022 to not be memory safe. There's no requirement that
| you "focus on tradeoffs", especially since real people
| get hurt by memory safety problems.
| kristoff_it wrote:
| I think you're actively hurting the project that you care
| about in your ineffective crusade, but hey, don't let me
| stop you.
| refulgentis wrote:
| Good sign for the language, bad sign for HN.
|
| I totally get it's nicer than C, I love it too, but it's
| completely irresponsible to push a language without a memory
| safety story, in 2022, this hard.
|
| From that relatively obvious conclusion it devolves into
| tedious nerdsnipes. Yes there are edge cases.
| pron wrote:
| Zig has a pretty good memory safety story -- and more
| generally, a correctness story -- it's just a different
| story from Rust's. I find it funny that fans of a language
| of a not-so-young-age that is struggling to find relevance
| and capture even 1% of the market are treating it as such
| an inevitability that it's irresponsible to talk about
| anything else. It's also detached from reality, as much of
| the software we all depend on is being written, in 2022, in
| languages without sound memory safety guarantees. There are
| various approaches being tried for how we should write low-
| level programs in the future, but there is no consensus yet
| on the best one.
| pcwalton wrote:
| > Zig has a pretty good memory safety story
|
| No, Zig is simply not memory safe. That's a property of a
| programming language that has a definition. Zig does not
| meet that definition.
|
| > I find it funny that fans of a language of a not-so-
| young-age that is struggling to find relevance and
| capture even 1% of the market are treating it as such an
| inevitability that it's irresponsible to talk about
| anything else.
|
| Leaving aside your weird description of a language
| powering software that serves billions of users as
| "struggling to find relevance", most software in 2022 is
| written in languages that are memory safe. Zig is quite
| the outlier here. It would in fact be very reasonable to
| survey the landscape of popular languages today and come
| to the conclusion that memory safety is an inevitability.
|
| > It's also detached from reality, as much of the
| software we all depend on is being written, in 2022, in
| languages without sound memory safety guarantees.
|
| Virtually all of that software is being developed in C or
| C++. The most compelling reason to use those languages is
| that they have a huge install base and a huge amount of
| code already written in them. This says nothing about
| whether a brand-new language should be memory safe.
|
| > There are various approaches being tried for how we
| should write low-level programs in the future, but there
| is no consensus yet on the best one.
|
| No, there actually is PL consensus that all new languages
| should be memory-safe, maybe aside from very low-level
| specialized languages, which Zig is not trying to be--Zig
| is trying to be a general purpose language.
| pron wrote:
| > No, Zig is simply not memory safe.
|
| I didn't claim that it is. I said it has a good memory
| safety story, i.e. mechanisms that soundly guarantee some
| kinds of memory safety, plus a design that helps write
| correct programs. Correctness in general, and memory
| safety in particular, are very central concerns in Zig's
| design, it's just that its story isn't one of sound
| guarantees across the board but, rather, some balanced
| mix of approaches -- some based on soundness, others
| based on facilitating comprehension and easier testing.
|
| > Most software in 2022 is written in languages that are
| memory safe. Zig is quite the outlier here.
|
| No, Zig is a low-level language, and the vast majority of
| low-level programs in 2022 are written in languages whose
| memory-safety story is worse than Zig's.
|
| > This says nothing about whether a brand-new language
| should be memory safe.
|
| That's right. We don't yet have an answer to that
| question, because we don't yet have sufficient experience
| with low-level languages that do have sound memory safety
| guarantees. I mean, it sure is better to have more
| guarantees if they come for free, but there's no such
| option in front of us just yet.
|
| > No, there actually is PL consensus that all new
| languages should be memory-safe
|
| No, there really isn't one when it comes to low-level
| languages (and the interest in Zig is proof that there is
| no consensus that it shouldn't exist). Rust is a low
| level language with sound memory safety guarantees, which
| comes at a price that makes it unappealing for some, and
| so various other approaches are being tried as well.
|
| You can't insist there's consensus when clearly there are
| people who disagree with you. That's the definition of a
| lack of consensus. I also think it is premature, to say
| the least, to declare an approach that is currently still
| far from proving a success as the only way.
| pcwalton wrote:
| > I didn't claim that it is. I said it has a good memory
| safety story, i.e. mechanisms that soundly guarantee some
| kinds of memory safety, as well as a design that makes it
| relatively easy to help write correct programs.
|
| Zig doesn't have mechanisms that soundly guarantee some
| kinds of memory safety. It's not spacially memory safe:
| extern unions, sentinel-terminated pointers, and multi-
| element pointers break it. At best, we think there's
| probably some subset of Zig that you could define that is
| spacially memory safe. (This isn't a particularly
| interesting property because it's trivially true for any
| language, by the way: C without pointers and without
| arrays is a subset of C that's memory safe, for instance,
| and also uninteresting.)
|
| > No, Zig is a low-level language, and the vast majority
| of low-level programs in 2022 are written in languages
| whose memory-safety story is worse than Zig's.
|
| Zig claims to be a general-purpose language, not just a
| low-level one. From [1]: "Zig is a general-purpose
| programming language and toolchain for maintaining
| robust, optimal, and reusable software."
|
| > I mean, it sure is better to have more guarantees if
| they come for free, but there's no such option in front
| of us just yet.
|
| It's better to have more guarantees if the benefit of the
| guarantees outweighs the cost, not if there is _no_ cost.
| For example, for many apps, the benefit of memory safety
| outweighs the cost of a garbage collector.
|
| > You can't insist there's consensus when clearly there
| are people who disagree with you. That's the definition
| of a lack of consensus.
|
| Consensus doesn't mean that nobody disagrees. It means
| that the opposite position is a fringe view.
|
| [1]: https://ziglang.org/documentation/master/
| pron wrote:
| > Zig doesn't have mechanisms that soundly guarantee some
| kinds of memory safety.
|
| It does.
|
| > It's not spacially memory safe: extern unions,
| sentinel-terminated pointers, and multi-element pointers
| break it.
|
| We've been through that. Those are syntactically
| delineated unsafe features for C/hardware interop. Rust
| has them, too.
|
| > This isn't a particularly interesting property because
| it's trivially true for any language
|
| That's right, but Zig is much closer to Rust than to C in
| that regard. It has clearly marked unsafe features for C
| or hardware interop, which aren't used in other
| situations and could be mechanically excluded -- just as
| in Rust.
|
| > Zig claims to be a general-purpose language, not just a
| low-level one.
|
| Surely you agree it's _also_ a low-level language?
|
| > It's better to have more guarantees if the benefit of
| the guarantees outweighs the cost, not if there is no
| cost.
|
| Yep, and we don't know if we're there in low level
| languages. So far it seems that some people find the cost
| of Rust acceptable and others do not. In other words,
| there's no consensus on what the acceptable cost is.
|
| > It means that the opposite position is a fringe view.
|
| So disagreeing that the only right design is that of a
| language that's struggling to get 1% of the market is a
| fringe view? That's like a Haskeller declaring that it is
| a fringe view to disagree that non-strict pure functional
| programming is the only right way to write programs. I
| think that Odin and JAI, two other low level languages in
| development, also don't go down the full memory-safety
| soundness path. Seems to me to be quite far from a fringe
| view.
|
| If people aren't buying what Rust is selling --
| regardless of how strongly some feel about the justice of
| its approach -- I think that those of us who care about
| correctness must explore alternatives, and Zig is
| certainly a fascinating alternative. It might well be the
| case that neither Rust nor Zig succeed in the market, but
| even in that case, both can certainly serve as
| inspiration for the languages that follow.
| pcwalton wrote:
| > We've been through that. Those are syntactically
| delineated unsafe features for C interop. Rust has them,
| too.
|
| And again we're assuming that the ones we went over in
| the previous thread are all there is. I found some more:
| @intToPtr, @bitCast, @alignCast. Some of those @
| functions are spatially-memory-safe, and some are not:
| the differences are not clearly called out.
|
| (I'm going to charitably assume that taking a pointer to
| an element in a dynamically-allocated array, and then
| shortening that array and dereferencing that pointer, is
| a temporal memory safety violation rather than a spatial
| one.)
|
| > That's right, but Zig is much closer to Rust than to C
| in that regard. It has clearly marked unsafe features for
| C interop.
|
| How are they clearly marked, when they're neither
| relegated to a separate section of the documentation nor
| behind a switch? As far as I can tell, the person who has
| gone through the most effort to isolate the spatial
| memory safe subset of Zig is me, in these HN threads.
|
| > So disagreeing that the design of a language that's
| struggling to get 1% of the market is the only right way
| is a fringe view now?
|
| Again, "struggling to get 1% of the market" is a weird
| way to describe a language that's serving billions of
| users right now.
| pron wrote:
| > And again we're assuming that the ones we went over in
| the previous thread are all there is.
|
| No one is assuming that. Like Rust, Zig has a set of
| unsafe operations that are well known to Zig programmers.
|
| > How are they clearly marked, when they're neither
| relegated to a separate section of the documentation nor
| behind a switch?
|
| They are syntactically distinct from the safe features,
| and they might be hidden behind a switch when there's
| demand for such a feature.
|
| > As far as I can tell, the person who has gone through
| the most effort to isolate the spatial memory safe subset
| of Zig is me, in these HN threads.
|
| So not only is disagreeing with you a fringe opinion,
| you're now the most knowledgeable on Zig's safety, a
| subject that is of great interest to Zig programmers?
| Those who spend the two days required to learn Zig know
| which operations are unsafe.
|
| > Again, "struggling to get 1% of the market" is a weird
| way to describe a language that's serving billions of
| users right now.
|
| Haskell and Erlang are also "serving billions of users"
| in the same way. The fact is that at an age where almost
| all programming languages (Python might be the sole
| exception) were in the ballpark of their all-time peak
| popularity, only a tiny portion of developers choose
| Rust. Like Zig, Rust is a language whose future success
| is uncertain.
|
| Look, not everyone would like Zig, not everyone would
| like Rust, and for all we know it's quite possible that
| the main difference between the two approaches is that
| they appeal to different people. But trying to make
| Rust's design appear inevitable or uniquely legitimate
| for low-level languages when that language is doing
| poorly, or claiming to speak on behalf of a consensus
| where there clearly isn't one and several other languages
| targeting the same domain prefer a very different
| approach, make you sound detached from reality.
|
| I find it a questionable choice to design a new complex
| language when complex languages tend to do poorly in the
| market, or to attempt a language for low-level
| programming that tries to appear high level on the page
| after C++'s lacklustre success with that approach, but I
| recognise that not everyone has the same taste as me, and
| I wouldn't call my opinions a consensus.
| dom96 wrote:
| > Again, "struggling to get 1% of the market" is a weird
| way to describe a language that's serving billions of
| users right now.
|
| Which language and which project is this referring to?
| strcat wrote:
| Android is heavily adopting Rust. They rewrote the
| Bluetooth stack, hardware keystore HAL, etc. in Rust and
| new components like virtualization are heavily using it.
| This is also behind the effort to get official Rust
| support in the Linux kernel. Android defines a stable
| kernel ABI for Linux LTS branches for GKIs (Generic
| Kernel Images). For example, 6th generation Pixels use
| the 5.10 LTS branch via a 5.10 GKI which can be updated
| independent of the device-specific kernel drivers. 7th
| generation Pixels will use the 5.15 LTS branch / GKIs and
| 6th generation ones have an experimental 5.15 LTS branch.
| They want to work towards having the SoC drivers and
| device drivers written against this stable API/ABI almost
| entirely written in Rust even if mainline Linux is slow
| to adopt it.
| refulgentis wrote:
| I actually have never tried Rust and probably never will,
| you lied when you implied I was a fan of the language.
| I'd probably hate it, in fact.
|
| The idea it's either "Rust or Zig" allows the poorly
| considered logical jump to Zig. I wouldn't use Rust
| because it's annoying too, but I also wouldn't choose Zig
| because I consider part of my professional responsibility
| to be using...literally any language that has memory
| safety.
| pron wrote:
| There is no "jump" to Zig, just a rejection of the claim
| that all low-level languages "in 2022" must be memory
| safe -- not just Zig, but also Odin and JAI aren't (I
| think). If you need to do low level programming, the fact
| is that in 2022 there is no consensus over whether you
| should do it in a memory safe language.
|
| If you think it's your responsibility to use only memory-
| safe languages, then if you had to do low-level
| programming, you'd have few option, and those options
| have their own downsides. That's just the reality of low
| level programming in 2022 -- it can often _only_ be done
| in non-memory-safe languages. I actually do quite a bit
| of low-level programming, and I consider it my
| professional responsibility to strive to do that in a
| language that is explicit and simple; there are no
| languages, to my knowledge, that meet my requirement and
| are also memory-safe, so I must compromise on something
| because I live in the real world.
| pcwalton wrote:
| > That's just the reality of low level programming in
| 2022 -- it can often only be done in non-memory-safe
| languages.
|
| That isn't true. You want to use a language that is more
| "explicit and simple". That's your prerogative, even if I
| disagree with it. But you do have a choice, and you are
| explicitly choosing to reject memory safety.
| pron wrote:
| No, you don't always have a choice, because C is the only
| language available (not counting Assembly) on some
| platforms, and even where Rust is available it is not
| always a reasonable option for a host of other reasons.
| skohan wrote:
| That's a rather extreme position.
| pcwalton wrote:
| It's not an extreme position. Most languages in wide use,
| and virtually all new languages, are memory safe. Zig is
| an extreme outlier in this regard.
| skohan wrote:
| That's extremely hyperbolic. Zig is a systems programming
| language with an explicit goal of operating at a low
| level of abstraction. Virtually all languages in its
| class are less memory safe than Zig.
| refulgentis wrote:
| "Virtually" is where your argument falls apart, and I
| want to be clear I'm not just dunking and moving on, I do
| understand the position that _not_ using a memory safe
| language is irresponsible is fairly new.
| skohan wrote:
| That position is not only new, it's also not the
| consensus. Zig explicitly chooses to make memory safety a
| non-goal of the language, with the argument that Rust-
| style memory safety is a costly tradeoff which is not
| always justified.
|
| Assuming that my argument has "fallen apart", or that you
| have "dunked" seems quite absurd given that you've taken
| an extreme position which many serious practitioners and
| academics would disagree with.
| pcwalton wrote:
| The point is that Zig's choice around memory safety makes
| its language design principles significantly outside the
| consensus around what PL design should be.
| skohan wrote:
| According to who? It's absolutely not the consensus that
| every programming language needs to prioritize safety.
|
| Rust is still very much an experiment in terms of systems
| programming. It has a tiny overall "market share" in
| terms of use in large production projects compared to
| C/C++ and it remains to be seen whether the particular
| set of tradeoffs chosen by the language will lead to long
| term sustainable success.
|
| Zig takes another approach and is also a worthy
| experiment.
| pcwalton wrote:
| Rust is serving billions of users right now. It's far
| past the "experiment" stage and has proven itself.
| skohan wrote:
| C/C++ have been used to implement the backbone of
| computing for 50 years. That is a proven technology.
|
| I'm not diminishing the success of Rust. It's been proven
| it can be used for serious projects.
|
| It's a bit of a reach to argue it's proven to be the best
| choice for all system programming use-cases going
| forward.
| refulgentis wrote:
| You make my brain hurt. You have these extremely long
| circuitous set of comments that hopstoch between
| insisting we're talking about Rust and that it's
| literally impossible to do the things you do in Zig in a
| memory safe language.
|
| It's especially frustrating because you've received a ton
| of charity and time from strangers, we understand 110%
| what you're thinking (I wish it was true! I've had an
| inordinate amount of work for 18 months now because it
| isn't) but you can't seem to wrap your mind around the
| idea that there isn't some niche where Zig is perfect and
| unassailable or the only alternative is rust. I don't
| think you have much experience in multiple languages,
| it's actually fairly easy to get something as fast in JS
| _as in C_.
| skohan wrote:
| With all due respect, your comments seem to imply a
| certain level of immaturity and it does not seem like you
| really know what you are talking about.
|
| It's possible in some cases that you can implement
| something in JavaScript which is competitive with a
| systems programming language, thanks to all the
| incredible optimization work which has gone into
| JavaScript engines, but the performance ceiling of a
| language like JS is _much much_ lower than that of system
| programming languages. For instance, if you are
| optimizing for memory cache performance C or Rust or Zig
| are going to have tools which just don 't exist in JS.
| There's a reason that HPC - one of the computing fields
| where profitability literally depends on speed - is all
| implemented in C and C++.
|
| And not that it matters but I've got plenty of experience
| with languages. I've been doing software engineering
| professionally for over a decade, and I've shipped
| professional projects in probably a half dozen languages
| or more including C, Rust, and Javascript. I've also done
| my fair share of programming in the systems domain,
| including computer graphics and games. I've also
| implemented programming languages of my own.
|
| > you can't seem to wrap your mind around the idea that
| there isn't some niche where Zig is perfect and
| unassailable or the only alternative is rust.
|
| I never said Zig fits a perfect niche. I said the theory
| of the language is valid, and it's a worthwhile
| contribution to the field. Zig, like all other languages,
| is an experiment. It's actually quite an interesting one
| with different goals than a lot of the other popular
| languages out there, and which is very appealing for the
| systems programming domain. I'm arguing against the idea
| that Zig is "irresponsible", which is an extreme
| position.
|
| I keep bringing up rust because of you guys insistence
| that Rust is a counter-example to the idea that a new
| systems programming language not necessarily be memory
| safe. For instance this comment:
|
| > We can't ignore the fact that Rust has shown that
| memory safety is not incompatible with low-level
| semantics.
|
| Seems to imply that Rust's existence unto itself is proof
| that every new systems programming language must be
| memory safe.
|
| C is the current standards bearer for systems
| programming. Everyone is trying to invent a "better C".
| Go and Nim are trying to do it with garbage collection.
| Rust is trying to do it with the borrow checker. Zim is
| trying to do it with ruthless simplicity and
| explicitness.
|
| All of these are experiments, and all of them are valid.
| 20 years from now we'll know a lot more about what works
| and what doesn't from each of these experiments, but it's
| too early to conclude that now.
| pcwalton wrote:
| Except Rust? We can't ignore the fact that Rust has shown
| that memory safety is not incompatible with low-level
| semantics. (Of course, Ada, Cyclone, CCured, etc. showed
| this much earlier than Rust.)
| skohan wrote:
| Zig has very different goals than Rust. The explicit
| theory of the language is that Rust's approach to memory
| safety creates costly tradeoffs which are not needed for
| all use-cases.
|
| It is very much not the consensus that memory safety is a
| requirement for any modern language. Asserting that it
| should be a requirement is an extreme position.
| brink wrote:
| So.. good for prototyping, like Ruby?
| quic5 wrote:
| I've continued to code on my game submitted to the last WASM-4
| jam for months and thoroughly enjoyed improving my messy game-
| jam code. So I'd disagree with the statement that Zig is only
| good for prototyping.
| necovek wrote:
| Other notable things from the game jam other than Zig being the
| most popular: it's mostly developers aged 15-24 (hopefully they
| split that up into 15-19 and 20-24 next time around), and mostly
| from Europe.
|
| WASM-4 seems to be a technically limited "console" (64kb of RAM,
| 160x160 console), so it's even more of a niche than just doing
| game dev for WASM.
| titzer wrote:
| It's great that young programmers are getting into these low-
| level things! In the early days of Wasm I was hoping we could
| put together a "wasm 4k demo" competition, but alas, funding
| these things is more complicated than it would appear. I'm glad
| this competition happened, and such cool results!
| Existenceblinks wrote:
| If I were a Zig advocate I would advertise [Z]ig as the
| programming of future starting from gen Z, new blood of
| developers.
| Cyberdog wrote:
| Generation Zig? I like it.
|
| Even though I'm technically a millennial... but if the next
| gen start using Zig instead of JavaScript for everything, I'm
| on board.
| Existenceblinks wrote:
| You could be a gen Zig developer. How cool is that. Yep,
| start cleaning up complexity mess that js ecosystem is
| expanding.
| Ygg2 wrote:
| And make your completely new mess.
|
| I doubt JS will stop being primary language in browsers
| in my lifetime.
| Existenceblinks wrote:
| You have chance to prevent it. It's not going to be
| perfect but use huge lesson learned from js ecosystem
| "mess" (I found this triggers some (many) js folks, it's
| quite ridiculous).
|
| Javascript "mess" in browsers could be reduced by
| dividing into two parts. DOM stuff, and pure language
| stuff. The first part can stay as is. Probably wrapped
| into thin API for new lang interop. The second part is a
| completely new lang that compile to wasm (ideal if vice-
| versa) so that backend could also send wasm to browser
| and be able to interact with DOM too.
|
| Next, backend js "mess" can be stopped because we have a
| better way for other languages to develop for the web.
| Ygg2 wrote:
| IMHO most software problem are social or caused by wider
| economic incentives.
|
| People come and go either because of life or work, and
| complexity piles up. I don't think there are any silver
| bullets.
|
| There is a reason Worse is Better. It's quicker to ship
| and spread.
| veltas wrote:
| Website broken for dark mode browsers. Text is light, background
| is white.
| Twisol wrote:
| Dark mode Firefox here, light text on dark background.
| LoveMortuus wrote:
| Microsoft Edge Android here: dark background, light font.
| Everything seems okay.
___________________________________________________________________
(page generated 2022-09-09 23:01 UTC)