Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type resolution redesign, with language changes to taste

ziglang.org

Post reply on HN
Print view View original

261–270 of 284 posts

Re: Type resolution redesign, with language changes to taste

#261

Post by thezipcreator »

CyberDildonics wrote: post #253
thezipcreator wrote: post #241

Earlier quoted context omitted.

I'm not sure why you shouldn't make your compiler accept CRs (weird design decision), but fixing it on the user-side isn't exactly hard either. I don't know an editor that doesn't have an option for using LF vs CRLF. The unused variable warning is legitimately really annoying though and has me inserting `_ = x;` all over the place and then forgetting to delete it, which is imo way worse than just... having it be a wa…

I don't know an editor that doesn't have an option for using LF vs CRLF. And I don't know any other languages that don't parse a carriage return. The point is that it was intentionally done to antagonize windows even though they put out a windows version. Some people defend this by saying that it's easy to turn off, some people defend it by saying windows users should be antagonized. No zig people ever said this was…

> And I don't know any other languages that don't parse a carriage return.

fair enough.

Re: Type resolution redesign, with language changes to taste

#262

Post by geon »

lionkor wrote: post #105
geon wrote: post #90

Earlier quoted context omitted.

Comparing Rust to C++ feels strange to me. It’s like people do it just because Zig is very comparable to C. So the more complex Rust must be like something else that is also complex, right? And C++ is complex, so… But that is a bit nonsensical. Rust isn’t very close to C++ at all.

I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++". For example, high performance servers (voltlane.net), programming languages ( https://github.com/HF-Foundation , https://github.com/lionkor/mcl-rs , and one private one), webservers (beampaint.com) and lots of other domains. Rust is cl…

> Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

That's like saying php is close to haskell because they both have garbage collection.

Re: Type resolution redesign, with language changes to taste

#263

Post by dnautics »

simonask wrote: post #247
dnautics wrote: post #183

Earlier quoted context omitted.

negative. For example bounds checking is turned on by default in Zig, which prevents classes of overflow safety errors.

I don't think you've necessarily understood the scope and impact of the borrow checker. Bounds checking is just a sane default (hygiene), not a game changer.

I mean, I'm the author of this?

https://github.com/ityonemo/clr

so yes, I understand that it's important. It doesn't need to be in the compiler though? I think it's likely the case that you also don't need to have annotations littering the language.

Re: Type resolution redesign, with language changes to taste

#264

Post by troad »

Tadpole9181 wrote: post #215
portly wrote: post #210

Earlier quoted context omitted.

I can share mine. I am not sure if this connects with you because maybe you are more experienced. I'm DevOps writing boring Python microservices for €. I have no CS background and never did systems programming. However, writing Python always bothered me because there are so many layers between you and what's happening on the metal. For me, Django is the peak example of this, to me it feels almost like doing no code.…

I'm sure it's not what you meant, but the argument "it makes me slower at my job and deliver less stable solutions, but I feel cool doing it" is not exactly a compelling endorsement.

I can't see anything in OP's post where he says any of that. Everything you said seems like an incredibly ungenerous reading of what he wrote.

Zig is a systems programming language. Moving from Python to Zig is a step down the tech stack, which brings with it exposure to underlying concepts and limitations that matter when writing any software, and which is especially valuable for a self-taught dev.

Re: Type resolution redesign, with language changes to taste

#265

Post by simonask »

dnautics wrote: post #263
simonask wrote: post #247

Earlier quoted context omitted.

I don't think you've necessarily understood the scope and impact of the borrow checker. Bounds checking is just a sane default (hygiene), not a game changer.

I mean, I'm the author of this? https://github.com/ityonemo/clr so yes, I understand that it's important. It doesn't need to be in the compiler though? I think it's likely the case that you also don't need to have annotations littering the language.

I wish you good luck! Successive attempts to achieve similar levels of analysis without annotations have failed in the C++ space, but I look forward to reading your results.

Re: Type resolution redesign, with language changes to taste

#266

Post by dennypenta »

lerno wrote: post #179
jackhalford wrote: post #114

Earlier quoted context omitted.

> Secondly, it should perhaps be a concern for Zig, now at 10 years old, to still produce solidly breaking code every half year. Not at all, if the team needs 30 more years they should take it. > However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0. Funny you see it as bleak when most of the community sees it as the most excitin…

> Not at all, if the team needs 30 more years they should take it. Yes, I understand that is the opinion in the Zig community. As an outsider, it seems odd to me to pick a language that I constantly need to maintain. >> However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0. > Funny you see it as bleak when most of the community s…

> In the case of C3, breaking changes only happen once a year with stdlib going through the general process of deprecating functions long before removing them.

zig release happens once a year, either a breaking change. I don't really get how you tried defended yourself, do you think it's any "different"?

Re: Type resolution redesign, with language changes to taste

#267

Post by Tadpole9181 »

troad wrote: post #264
Tadpole9181 wrote: post #215

Earlier quoted context omitted.

I'm sure it's not what you meant, but the argument "it makes me slower at my job and deliver less stable solutions, but I feel cool doing it" is not exactly a compelling endorsement.

I can't see anything in OP's post where he says any of that. Everything you said seems like an incredibly ungenerous reading of what he wrote. Zig is a systems programming language. Moving from Python to Zig is a step down the tech stack, which brings with it exposure to underlying concepts and limitations that matter when writing any software, and which is especially valuable for a self-taught dev.

He wrote an XML parsing stack on hours instead of doing his job because doing it was, and I quote, "yawn".

Re: Type resolution redesign, with language changes to taste

#268

Post by Ygg2 »

9rx wrote: post #260
Ygg2 wrote: post #252

Earlier quoted context omitted.

> The primary common ground is that their functions have encapsulation You omitted Smalltalk. Most people would agree that SmallTalk is object-oriented. But that kinda ruins the common ground thesis. > Language evolves, certainly. It is fine for "object-oriented" to mean something else today. pjmlp definition is very fuzzy. It judges object-orientedness based on a few criteria, like inheritance, encapsulation, polymo…

> You omitted Smalltalk. Exactly. It isn't functional. It doesn't use functions. It uses message passing instead. That is exactly why the term "object-oriented" was originally coined for Smalltalk. It didn't fit within the use of "imperative" and "functional" that preceded it. > But that kinda ruins the common ground thesis. That is the thesis: That Smalltalk is neither imperative nor functional. That is why it was g…

> That is exactly why the term "object-oriented" was originally coined for Smalltalk.

Sure but your definition doesn't cover it. If language for which the term was coined, it's a bit meaningless, ain't it.

Problem with making encapsulation and polymorphism essential to OOP definition, is that it then starts garbling up functional languages like Haskell and imperative like C.

I can see them being necessary but not enough to classify something as OOP.

> And when you look you'll soon find out that there is no commonality here.

Perhaps, but broadly speaking people agree that C++ and Java are OOP, but for example C isn't.

Same way when people say and give me a fruit (as in fruits and vegetables), you'd be looked oddly if you gave a cucumber, rather than an apple.

Same way can be thought of OOP. The common definition is basically covers Message-passing-languages, and inheritance/prototype based languages.

Re: Type resolution redesign, with language changes to taste

#269

Post by igouy »

Ygg2 wrote: post #268
9rx wrote: post #260

Earlier quoted context omitted.

> You omitted Smalltalk. Exactly. It isn't functional. It doesn't use functions. It uses message passing instead. That is exactly why the term "object-oriented" was originally coined for Smalltalk. It didn't fit within the use of "imperative" and "functional" that preceded it. > But that kinda ruins the common ground thesis. That is the thesis: That Smalltalk is neither imperative nor functional. That is why it was g…

> That is exactly why the term "object-oriented" was originally coined for Smalltalk. Sure but your definition doesn't cover it. If language for which the term was coined, it's a bit meaningless, ain't it. Problem with making encapsulation and polymorphism essential to OOP definition, is that it then starts garbling up functional languages like Haskell and imperative like C. I can see them being necessary but not eno…

Fruit = { Apple, Cucumber, … }

Veg = { Cucumber, … }

Fruit As In = Fruit − Veg

Re: Type resolution redesign, with language changes to taste

#270

Post by dnautics »

simonask wrote: post #265
dnautics wrote: post #263

Earlier quoted context omitted.

I mean, I'm the author of this? https://github.com/ityonemo/clr so yes, I understand that it's important. It doesn't need to be in the compiler though? I think it's likely the case that you also don't need to have annotations littering the language.

I wish you good luck! Successive attempts to achieve similar levels of analysis without annotations have failed in the C++ space, but I look forward to reading your results.

yeah afaik you cant easily intercept c++ at a meaningful IR in the same way as you can zig. Zig's AIR is almost perfect for this kind of thing.
Post reply on HN