How to Use Abstraction to Kill Your API - Jonathan Marler - Software You Can Love Vancouver 2023

[@delphicdescant]

Unlearn the teachings of enterprise software development, you must. - Zig Yoda

[@rj7250a]

Average class name in enterprise Java software: abstractFactorySingletonInterfaceHandlerFactory.

[@hck1bloodday]

@@rj7250a you used factory two times, that's not DRY, the correct name should be abstractFactorySingletonInterfaceHandlerBuilderDecorator

[@nXqd]

it's true, I think with the grow and changes of software development, there are some practices that must be changed.

[@megamaser]

People see a pattern and they copy it without thinking about whether it's applicable or if they're using it in a way that's helpful.

[@kcvinu]

@@rj7250a Horrible!

[@martinweber988]

great talk and very refreshing to see a focus on efficiency in all aspects. Sweet.

[@AK-vx4dy]

Excelent presentation! Interesting and funy!

[@samuelschwager]

Finally a guy that could fix my printer :P

[@UliTroyo]

What a cool talk! I'll definitely be re-watching this at some point :)

[@ForeverZer0]

Zig is showing so much promise, and I can't wait to see where it goes in the future, It just might be the true successor to C for the modern era if it doesn't go the way of C++/Rust and go crazy adding too many features to the language. I have two peevs that I would love to see addressed at some point, both are minor: 1. Size of binaries 2. Inconsistent naming of language symbols: mix of Pascal-, camel-case, etc. (yes, this is very petty, but it irks me, and I see no legitimate reason for the inconsistencies)

[@notuxnobux]

Do you mean size of the zig binary or the size of binaries it produces? because with releaseSmall and debug symbol strip the binaries are smaller than even C with musl.

[@disquettepoppy]

The capitalization of the symbols is to convey information without conventions that would be even uglier, like hungarian notation. In that regards, it's consistent - for example Pascal case is for symbols that indicate types (with the basic types - bools, integers and floating point being the exception).

[@nicolasgrilly]

@@disquettepoppy Yes. I understand the idea is to keep TitleCase for types and snake_case for functions, variables, constants, fields, etc. I think one of the reasons for not keeping camelCase for functions is that there is no difference between camelCase and snake_case for one word identifiers.

[@etodemerzel2627]

Inconsistent naming? What are you referring to? The style guide (you can find it in the official documentation) says TitleCase for types, camelCase for functions and snake_case for everything else (including structs with 0 fields). What's inconsistent about that?

[@ForeverZer0]

@@etodemerzel2627 I am not talking about common naming conventions and code styles that are a good practice to (optionally) follow, but the symbols that built-in to the language itself. The list of built-in functions might shed some insights: What is the common rule being followed for a list that contains the following: @sizeOf, @TypeOf, @memset Something like @memset might have been kept as such for legacy reasons with its C analog, but then why not the same with @sizeOf or @alignOf. How does @Type, @TypeOff, or @Vector fit into this naming rule? It is possible for someone not be bothered by it, but this is objectively not consistent or based on a naming rule.

[@MahmoudAbduljawad]

Amazing talk! Learnt a lot.

[@CristianMolina]

Very cool talk, thanks

[@megamaser]

You won't get much done without abstraction. But you also won't get much done if all you do is build abstractions.

[@yash1152]

0:03 how are they all making the presentation on this pixel art form??

[@nXqd]

super cool, talk and very nice audience

[@aqezzz]

oh man, this is awesome. great work! i'm going to have to do some zig

[@simon4512]

Very interesting talk! But I feel like the title doesn't really match the content? Felt like it wasn't so much about abstraction (or over abstraction) as much as it was error handling, and just general C vs Zig comparison

[@stercorarius]

It was a shame for the D community to lose this guy

[@L0wPressure]

What’s the D, did I miss something?

[@gamcd]

@@L0wPressureDlang, C with more features and abstractions

[@nathanfranck5822]

A c++ alternative popular in the 2000s

[@L0wPressure]

@@nathanfranck5822 oh, got it, thanks!

[@NerdyWasTaken]

@@L0wPressure Language with 3 different compilers

[@MatheusCatarino]

Awesome!

[@employee9911]

Great talk!

[@CallousCoder]

Ooh nice! I can't wait!

[@acorad30]

Very interesting

[@felgenh399]

very cool!

[@trondenver5017]

Great talk

[@alexdubkov6998]

Wow, he has a beard, so we can trust Zig!

[@nanthilrodriguez]

What did this have to do with abstraction at all?

[@shrin210]

Zig has better abstraction implementation than C.

[@mehmetedex]

Zigx is really cool

[@anasouardini]

The most important point here is Zig>C.

[@markblacket8900]

more like >= C

[@Alexander_Sannikov]

it really is not exactly hard to find a language better than C in 2024. that's really not enough of a reason to replace it though.

[@yash1152]

22:00 will watch later.

[@yash1152]

30:00*

[@VoyivodaFTW1]

i knew it was gonna be doom! lmao

[@StefaNoneD]

Sure a good talk, but this scratching sound issue is really nasty! 🙁

[@ryanlancer86]

The only thing I do not like about zig is the mascot

[@anagram]

What!?! It's the best thing ever! You are being crazy

[@Cons-Cat]

Terrible take! Ziggy is adorable

[@etodemerzel2627]

Blasphemy

[@saiv46]

Unlike *some alternative* Linux mascot, Zig one is pretty and cool. Who doesn't love reptiles?

[@martinmartin6300]

The fact that you need to assign return values to variables in zig is a very bad design choice. It is really annoying.

[@rinumu2736]

It's made that way, so that if you want to ignore the return value, you have to be explicit about it by assigning to _. In C it's very easy to forget to check the return value of functions. Many people don't even know that e.g. printf has a return value (I know I didn't even though I opened it's manual page many times).

[@andrewbreidenbach8788]

@@rinumu2736 I personally prefer Nim's discard keyword and discardable pragma

[@pierreollivier1]

It's on purpose, because one of the goal of the language is to be explicit, if you can discard the values returned by a function how can you at a glance know which functions is suppose to return something. in my humble opinion everything related to typing code is a non issue when you know that most code lives and need to be maintained. Id' rather type the four character needed to discard a value rather than having to deal with the mental load of checking every function signature to see who returns what. On top of that zig has really good type inference, a lot of what you pay in typing more returns you save it on type you don't need to type over and over again. It also has the benefit that changing the type of a function signature, doesn't brake anything if the type is compatible with the logic of your code.

[@ivanstepanovftw]

@@rinumu2736 lets say you have variable "hueta" that is used to be logged to console and modified inside some logic code. When you comment this logic code, zig wants you to make hueta constant. So you change var to const. But if you comment debug log that uses this ~variable~ constant, zig asks you to use it like _ = hueta. Fine, zig wants you to add _= everywhere, but when you uncomment either debug code or logic code, zig asks you to remove _ = hueta. Why it is so hard to make unused variable be a warning? Why it asks you to change from variable to constant when i dont want to do this because i am commenting some code just to test things for 1 run?

[@Kapendev]

​@@rinumu2736 😱😰😱😰😱

[@gaius_enceladus]

Great talk!