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

191–200 of 284 posts

Re: Type resolution redesign, with language changes to taste

#191

Post by riidom »

lerno wrote: post #185

I just have to add another reflection: One thing that tends to be overlooked when discussing changes is the ecosystem effect of frequent changes. A language that breaks frequently doesn't just impose upgrade work on apps, but also discourages the creation of long-lived libraries and tools. Anything that sits between the language and the user (linters, bindings, frameworks, teaching material, tutorials etc) has to to…

An example for this is the Blender addon ecosystem. Blender moves very fast, breaking API changes every few versions. Now I am not an addon developer myself, but from github issues I follow, changes are fairly often trivial to do.

Yet, someone has to do them. Ideally it is the creator of the addon, sometimes it's the users who do it, when the addon is not maintained anymore (in case of trivial changes).

It kinda works that way, but it also is some kind of gamble for the user. When you see a new addon (and a new addon developer), you can't know if they gonna stick to it or not.

If you have to pay for the addon, it's more likely they maintain it, of course. But also not a guarantee.

Re: Type resolution redesign, with language changes to taste

#192

Post by throwaway27448 »

mikkupikku wrote: post #78
throwaway27448 wrote: post #44

Earlier quoted context omitted.

Claude CLI is not exactly a reference of usable software

It's plenty usable. Most of the problems with the claude TUI stem from it being a TUI (no way to query the terminal emulator's displayed character grid), so you have to maintain your own state and try to keep them in sync, which more than a few TUIs will fail at at least sometimes, hence the popularity of conventions like Ctrl+L to redraw.

I don't know what a TUI is (i'm guessing "terminal ui" as if the term CLI doesn't exist lmao) but yea, they could have put effort into their product and not forced people to use their atrocious ncurses interface which is like the worst of all worlds: text interface without the benefit of the shell, zero accessibility.

Re: Type resolution redesign, with language changes to taste

#193

Post by 9rx »

nindalf wrote: post #173
ryanxsim wrote: post #55

Earlier quoted context omitted.

I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking

Zig is what you want to write, because it gets out of the way. Rust is what you want your colleagues to write, to enforce good practices and minimise bugs. It's also what I want my past self to have written, because that guy is always doing things that make my present life harder.

I'd rather my colleagues (and past self) write Rocq.

Rust is what you use when you'd rather spend time doing sales and marketing for Rust than building software.

Re: Type resolution redesign, with language changes to taste

#194

Post by estebank »

pjmlp wrote: post #178
simonask wrote: post #139

Earlier quoted context omitted.

Rust uses LLVM because it's pretty great, not because you couldn't implement LLVM in Rust. Maybe cranelift will eventually surpass LLVM, but there isn't currently much reason to push for that.

Thus Rust cannot really replace C++ when its reference toolchain depends on it.

If you define success for Rust as "everything is written in Rust", then Rust will never be successful. The project also doesn't pursue success in those terms, so it is like complaining about how bad a salmon is at climbing trees.

Re: Type resolution redesign, with language changes to taste

#195

Post by 9rx »

7bit wrote: post #96
lionkor wrote: post #62

Earlier quoted context omitted.

Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.

Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.

Re: Type resolution redesign, with language changes to taste

#196

Post by mikkupikku »

throwaway27448 wrote: post #192
mikkupikku wrote: post #78

Earlier quoted context omitted.

It's plenty usable. Most of the problems with the claude TUI stem from it being a TUI (no way to query the terminal emulator's displayed character grid), so you have to maintain your own state and try to keep them in sync, which more than a few TUIs will fail at at least sometimes, hence the popularity of conventions like Ctrl+L to redraw.

I don't know what a TUI is (i'm guessing "terminal ui" as if the term CLI doesn't exist lmao) but yea, they could have put effort into their product and not forced people to use their atrocious ncurses interface which is like the worst of all worlds: text interface without the benefit of the shell, zero accessibility.

CLI refers more to non-interactive programs used through a shell, programs like grep or or indeed the `claude` program in non-interactive modes. TUIs (text user interfaces) refers to interactive programs implemented in a terminal interface, what you call ncurses interfaces (but usually aren't implemented using ncurses these days.) They're GUIs in text, so TUIs.

Anyway, their decision to implement a TUI was definitely not done out of laziness nor even pragmatism. It was a fashion choice. A deliberate choice to put their product in the same vibes-space as console jockey hotshot unix pros who spit out arcane one liners to get shit done. They very easily could have asked claude to write itself a proper GUI interface which completely avoids all the pitfalls of TUIs and simplifies a lot of things they went out of their way to make work in a TUI. Support for drag-and-drop for instance, isn't something you'll find in many TUIs but they have it. They put care into making this TUI, the problem is that TUIs are kind of shit, and they certainly know that. They did it this way anyway effectively for marketting reasons.

Re: Type resolution redesign, with language changes to taste

#197

Post by [deleted] »

pjmlp wrote: post #130
7bit wrote: post #96

Earlier quoted context omitted.

C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.

It certainly is according to the various CS definitions of type systems. Plenty of OOP architectures can be implemented 1:1 in Rust type system.

[deleted]

Re: Type resolution redesign, with language changes to taste

#198

Post by jmull »

cwillu wrote: post #133
sidkshatriya wrote: post #49

Earlier quoted context omitted.

I don't know why I was downvoted here. One day, I was experiencing weird compilation errors. Clearing the `ccache` C/C++ compiler cache helped get past the problem. Yes, I could have investigated in detail what was the issue and if ccache had a bug but sometimes you don't have the luxury of investigating everything your toolchain throws at you.

You don't use it, but you're offering unsolicited advice about it, and that advice is very generic. It's not even an argument that you're wrong, just that it's not contributing much and people think that other replies should come first.

Never mind that the previous poster’s insight about caches is correct.

Zig has had caching bugs/issues/limitations that could be worked around by clearing the cache. (Has had, and more that likely still has, and will have.)

Re: Type resolution redesign, with language changes to taste

#199

Post by 9rx »

pjmlp wrote: post #130
7bit wrote: post #96

Earlier quoted context omitted.

C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.

It certainly is according to the various CS definitions of type systems. Plenty of OOP architectures can be implemented 1:1 in Rust type system.

Yes, of course you can call objc_msgSend or equivalent in Rust just as you can in C. But you are pushing the object-oriented model into a library. It is not native to the language.

Re: Type resolution redesign, with language changes to taste

#200

Post by flohofwoe »

pjmlp wrote: post #182
flohofwoe wrote: post #168

Earlier quoted context omitted.

> HLSL evolution roadmap ...that's just because of the traditional-game-dev Stockholm syndrome towards C++ (but not too much C++ please!). > Khronos future for Vulkan As far as I'm aware Khronos is not planning to move the Vulkan API to C++ - and the 'modern C++' sample code which adds a C++ RAII wrapper on top of the Vulkan C API does more harm than good (especially since lifetime management for Vulkan object is a b…

See the talks around Vulkan ecosystem, and GPU shading languages from February. There is more than one sample using C++, now they make use of C++20, including modules if desired.

> now they make use of C++20, including modules if desired.

It's in line with many other shitty design decisions coming out of Khronos, so I'm not even surprised ;)

IMHO it's a pretty big problem when the spec is on an entirely different abstraction level than the sample code (those new samples also move significant code into 'helper classes', which means all the interesting stuff is hidden away).

Post reply on HN