Conversation

Patrick Walton
@pcwalton
The future I'd like us to get to is one in which memory-unsafe languages are treated like assembly language is today. We'll always need unsafe code, but it should be considered very niche. Most programmers won't need to know it, and writing it will require strong justification.
14
442
Patrick Walton
@pcwalton
Being memory-safe will ideally be seen as just a boring thing that every language obviously needs. A new language not being memory safe will be seen as a decision as strange as the decision to forgo structured programming in favor of labels and GOTO would be today.
6
119
Aria the Cat
@Gankra_
i mean, this is already true? we literally had like 30 years where C/C++ were the only ones doing their thing and everyone tried to make higher and higher level things?
1
7
Aria the Cat
@Gankra_
go's unsafety seems less like a design choice and more like just genuinely bad design (and no desire to improve). i truly don't get the pitch of zig's cohort though. doesn't make any sense to me.
3
8
Joseph Garvin
@joseph_h_garvin
I think there's something to Zig's generics. Being able to use types as regular function arguments so `LinkedList` is a function that takes a type T and returns a type (a linked list implementation that holds Ts) is elegant. I never liked the <> vs () arg passing inconsistency.
1
Brendan Zabarauskas
@brendanzab
I might be mistaken, but in Zig applying a type argument can fail if it results in ill-typed code. In this regard they are more like templates? This seems like a step backwards, and the opposite to what I'd want if I wanted the type and term language to be more consistent?
2