Commentary on Friction in Language Design

The commentary the comment is based on: github.com/ziglang/zig/issues...
Website: odin-lang.org
Email: [e-mail]
GitHub: github.com/odin-lang/Odin
Patreon: / gingerbill
Twitter: / thegingerbill
KZbin: / gingergames

[@soupertonic3579]

liking the smash button

[@jonaskoelker]

I always thought the smash "button" was metaphorical, concretely being a rightward swiping gesture. Having found someone, it's been a while since I searched for someone I'd smash to like.

[@Pariatech]

I'm currently rewriting a game I made in Zig to Odin. And I can say I'm enjoying the process very much. So far the features I enjoy the most in Odin is the enumerated array, the ease to make a structure of array and the using keyword. Those features got me strongly considering continuing the project in the language. Thank you and keep up the good work Bill!

[@andrewdunbar828]

Your and Andrew's thoughts on programming languages are always worth listening to. I wish there were comparable voices speaking for Rust and Swift, they're all languages I like. It's very interesting to see them all (and others) explore the space of this "new" generation of languages each with their different philosophies but also with quite a bit in common.

[@bonisamuel1]

Great video as aways! My experience with odin is that I don't even notice the language most of the time, I just focus on the program, and that is great! When I programmed in zig, I had to think about the language friction all of the time, that is why I stop using it. But that is my experience, both languages are great, and is great to have options.

[@ManuelBTC21]

This is so obvious to me, it's to the point that I wonder if Andy knows he's wrong, but for some reason is trying to limit adoption at this point.

[@androth1502]

@@ManuelBTC21 i think he's trying to take the half way point to rust. friction in rust is about the highest level of friction that i've seen in any language. zig seems to be aiming for providing the same level of security as rust, but with less friction. also, i don't think friction will impact adoption, it will just attract a different sort of programmer. most of the people using odin are likely in the jon blow school of thought. so they will be attracted to languages that just work and won't get in the way.

[@DMitsukirules]

@@androth1502 I just don't see what, for example, variables_having_to_be_named_this_way in rust does for safety. There are so many examples of friction in rust that just flat out don't do anything that it becomes a real pain to use before you even get to annotating the lifetimes of things or having to deal with situations where you can prove something safe but the compiler can't.

[@yeongjukang7300]

I really like your language philosophy. Thank you for a good video!

[@DMitsukirules]

The best way I can put it is, Odin is opinionated in ways that don't really hamper writing code, even if you might be forced to occasionally be verbose (casting is a perfect example. Slightly "annoying", but I just have to be verbose) Zig is annoying in ways that make me so unproductive I patch the annoying part out of the compiler, and the justification just seems ridiculous. You aren't going to need it? I am going to need it, in literally 5 seconds, but now I'm wasting more time pretending I'm not going to need it and flip flopping back and forth because your compiler "feature." Odin code is just as easy to read as zig code. I never had to patch the compiler to be productive. The philosophy seems really like "loose where it doesn't matter and strict where a real case can be made for the strictness" Perfect example to me is semicolons. I personally use them, but it really doesn't matter so I like how it was designed to work either way. Then there are other examples of things I can think of that can be inferred, for example around parapoly, that HAVE to be explicit. My first thought doing them was "this can be automatically inferred by the compiler, can't it?" Then I realized "this isn't automatically inferred by the compiler so whoever is looking at this always explicitly knows what is happening, which is fine." Thanks for making these decisions where they matter and not becoming a bracket location or variable_names_need_underscores tyrant.

[@godDIEmanLIVE]

More of this please.

[@AinurEru]

Zig has always been explicit about prioritising the experience of users of the output software over the experience of develops, whenever those 2 pull in opposing directions. Andrew states that on many occasions. So is more favouring people sitting on the chair even at the expense of the person making the chair.

[@GingerGames]

But I don't think those are at odds whatsoever, not even opposites. The developer makes software for the user. Zig has ideas about how to develop better software regardless of the developer but that may or may not be true is practice whatsoever. It's a hypothesis which I have yet to see evidence for either way. If you think it's a good or bad idea either way, that's great! I love that programmers can choose between tools now for what the programmer wants and needs.

[@AinurEru]

@@GingerGames I'm personally agnostic about the link between language features and software quality, I think it's an open question. Andrew seems to believe that there are clear ways of "buying" an increase in software quality at the "cost" of induced development friction through language features - i.e: Zig's error handling machinery necessitating explicit handling of error cases, or how enum switching has to be exhustive for it to compile, etc.

[@platin2148]

I don’t want the guiding. Languages that do this are basically like driving with a bicycle with support wheels but you are already a down hill driver. For me Zig contains too many attributes and such languages seem to be noisy.

[@SimGunther]

There's a fascinating study where gamers were most frustrated with "freedom of choice" being taken away even IF the game pushed them towards the very best choice. One way to combat that frustration while still giving them the best "intended experience" is to nudge the player towards those great experiences through good game design. I'm in the camp where you make the language design "free-form" like a sort of C/C++ and you analyze programs for the most error prone things a developer can do before redesigning the language to nudge someone towards making the "most correct way" to solve the problem the "most convenient way" to solve it :)

[@10bokaj]

Yes, you have made a great language.

[@alurma]

thanks

[@xxMKtooStronk__]

Yo Ginger! I'm having a big struggle trying to install yo Odin language on my computer and get it working. Can you make a separate video dedicated exclusevly to how to install Odin and prepare it in Visual Studio Code?

[@lilyscarlet2584]

dont use visual studio code its a crappy web app.

[@julkiewicz]

7:20 Oh, wow, so if I understand correctly since the default type is the platform-sized integer, that in your opinion is the best choice for iterators etc. on most platforms? Is there really no performance loss due to that? For like 99.9% of cases of iterating / indexing i32 seems to be just fine? I'm genuinely asking, I definitely myself don't have sufficient low-level knowledge of which opcodes run at what speeds and of how register allocation in a compiler works to be able to have an opinion.

[@GingerGames]

On amd64, ADDQ will be faster than ADDL. Try it if you don't believe me.

[@julkiewicz]

@@GingerGames Actually, on a second thought it makes perfect sense. I remember learning that short and byte etc. are slower to work with on 32-bit arch. So it makes perfect sense that on a 64-bit arch it's the fastest to work with 64-bit types. For whatever reason seems less intuitive for me

[@torarinvik4920]

Friction is almost like the basis of many of the functional languages. They take away all of the tools that make it easy to write incorrect software, and therefore it takes quite a lot more time to write a FP program. Haskell is probably the most famous, but for instance in F# you have to declare the order of how your modules are compiled so that you are guaranteed not to get circular dependencies. Actually a pretty awesome feature that other languages should have. I think all static languages should have a lot of friction, no implicit conversions for me! The only languages that shouldn't have friction and safety in mind are the scripting languages where the goal is to get something working fast with as little effort as possible like Ruby and Python.

[@lucasjames8281]

Friction? Like the language server that doesn’t work on vscode on Linux

[@GonziHere]

Shadowing isn't an issue in and of itself and the way Rust uses it is actually great... username = getUser(); username = username.name; (obviously convoluted). I like that pattern a lot, because it prevents you from creating user and username, even though you won't use "user" anywhere else.

[@platin2148]

Feels like a macro sort of thing. Prefer to not have this defined like that. Better have a keyword called alias..

[@porky1118]

But that's a weird example. The first variable called "username" is not an username in this case. Is this meant to be a joke? However, this is how I would do something like this in Rust: let username = { let user = get_user(); user.name }; A real use case of shadowing is for refactoring. Something like this: let x = x as u8; let y = &mut y; let z = *z; Or if you want to restrict mutability: let mut x = x; modify(&mut x); let x = x; Or to convert some representation for a value into something else: let value = map.get(&value);

[@GonziHere]

​@@porky1118 You are right, I couldn't remember the typical usecase, but I was thinking about the type changes, so function readIntFromConsole(){ var number = console.readline(); number = parseInt(number); return number; } it's obvious in that type of scenario.

[@Tekay37]

For me the worst friction is the one that comes up when refactor something. I have that in Odin as well sometimes. Mostly when it comes to calculations between different types, let's say an int, a c.int, and an f32. Without friction, and refactor friendly would be if I could just wrap the whole term with a cast ( f32( a + b * c) ). Instead, Odin forces me to use it on every variable that is not the result type ( f32(a) + b * f32(c) ). I'm not quite sure where that is supposed to nudge me. Towards always using the same type in the first place, maybe?

[@Narblo]

I think is more so you document what is going on with your calculation, you are first doing 2 conversions and then multiplying instead of multiplying the f32 and the int as an f32 (note that as f32 is not the same as converting it to f32, the first just use the same bits to represent the int value AS an f32 which is completly wrong)

[@Tekay37]

@@Narblo Well, but if I wrap a formula inside such a cast, why wouldn't it be reasonable to cast every part of that formula to that? so, ( f32(a + b*c) ) would mean ( f32(a) + f32(b) * f32(c) ).

[@TetraluxOnPC]

​@@Tekay37 I think that may make it impossible to do 'f32(a) + f32(int(b) + int(c))' without resorting to temporaries.

[@leddoo]

i'd say it violates the principle of least surprise. changes to variable types higher up in the code can change behavior lower down, without causing type errors (by introducing casts).