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

181–190 of 284 posts

Re: Type resolution redesign, with language changes to taste

#181

Post by pjmlp »

nindalf wrote: post #174
pjmlp wrote: post #57

Earlier quoted context omitted.

Why isn't rustc using Cranelift then?

Same reason Android and Chrome and git and Linux weren't written in Rust when they started. Rust didn't exist. All of these projects integrate Rust now, after being single language projects for the longest time. It's notable that the projects you mentioned mostly don't need to deal with adversarial user input, while the projects I mentioned do. That's one area that Rust shines in.

Rust presence in Android is minimal, and not officially supported for userspace.

Android team is quite clear that Java, Kotlin, C and C++ are the official languages for app developers.

Chrome even has less Rust than Firefox.

Linux has some baby adoption, and it isn't without drama, even with Microsoft and Google pushing for it.

Re: Type resolution redesign, with language changes to taste

#182

Post by pjmlp »

flohofwoe wrote: post #168
pjmlp wrote: post #98

Earlier quoted context omitted.

CUDA, SYSCL, HLSL evolution roadmap, and Khronos future for Vulkan beg to differ with your opinion.

> 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.

Re: Type resolution redesign, with language changes to taste

#183

Post by dnautics »

simonask wrote: post #140
dnautics wrote: post #128

Earlier quoted context omitted.

actually that's not true at all. Zig offers you some more safety than C. And it also affords you a compiler architecture and stdlib that is so well designed you could probably bolt on memory safety relatively easily as a 3rd party static checker https://github.com/ityonemo/clr

"More safety than C" is an incredibly low bar. These are hygiene features, which is great, but Rust offers a paradigm shift. It's an entirely different ballpark.

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

Re: Type resolution redesign, with language changes to taste

#184

Post by _bohm »

lerno wrote: post #172
_bohm wrote: post #158

Earlier quoted context omitted.

A pretty obvious explanation as to why Odin has more games written in it is that the language is somewhat explicitly marketed towards that use-case, even going as far to have a vendor library collection that includes many popular game dev libraries.

I am using games, because they pop up more often (gamejams etc), but we can see the same if we'd look at utility apps. Do you want to broaden that to "Odin is more explicitly marked towards writing applications", but if so what would that say of Zig?

I would begin by questioning the premise. Do you have actual numbers on this? I’m not really aware of any widely adopted software that’s written in Odin. Can name multiple in the case of Zig

Re: Type resolution redesign, with language changes to taste

#185

Post by lerno »

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 some degree "chase the language"

This means that the ecosystem will skew toward very actively maintained libraries and away from "write once then leave it alone" libs. And this the trade-off is reasonable during early language design, but it's worth acknowledging that it has real consequences for ecosystem growth.

One should note that other newer languages have put significant effort into minimizing this churn, precisely to allow the latter type of ecosystem to also form. So it's kind of an experiment, and it will be interesting to see which approach ends up producing the larger ecosystem over time.

Re: Type resolution redesign, with language changes to taste

#188

Post by jlokier »

simonask wrote: post #137
king_geedorah wrote: post #134

The kernel32 -> Ntdll changes are the most interesting thing to me here. A lot of the rationale is applicable also to the linux userspace APIs, especially errors in return at the kernel-userspace boundary vs GetLastError/errno in kernel32/libc. Of course on linux the "problem" is that libc and the kernel API are intimately intertwined and the former mandates using errno. I wonder how the pattern made its way into win…

The errno/GetLastError() pattern is a remnant from a time before threads were a thing. You could have multiple processes, but they were largely scheduled collaboratively (rather than preemptively). In that world, things like global variables are perfectly fine. But then we got first preemptive scheduling and threads, then actual multicore CPUs, so global variables became really dangerous. Thread locals are the escape…

Indeed, and this change of philosophy shows up in the pthread (POSIX threads) API, which returns error values directly (as a negative integer) instead of setting the errno variable.

Re: Type resolution redesign, with language changes to taste

#189

Post by naasking »

mgoetzke wrote: post #109
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.

As someone who never liked writing anything C++ since 2000+ (did like it before) I cannot agree with this. C++ and Rust are not comparable in this sense at all. One can argue Rust is what C++ wanted to be maybe. But C++ as it is now is anything but clean and clear.

I think the comparison is fair, strictly in the sense that both Rust and C++ are designed around extensible programming via a sort of subtyping (C++ classes, Rust traits), and similar resource management patterns (ownership, RAII), where Zig and C do not have anything comparable.

Re: Type resolution redesign, with language changes to taste

#190

Post by nindalf »

pjmlp wrote: post #181
nindalf wrote: post #174

Earlier quoted context omitted.

Same reason Android and Chrome and git and Linux weren't written in Rust when they started. Rust didn't exist. All of these projects integrate Rust now, after being single language projects for the longest time. It's notable that the projects you mentioned mostly don't need to deal with adversarial user input, while the projects I mentioned do. That's one area that Rust shines in.

Rust presence in Android is minimal, and not officially supported for userspace. Android team is quite clear that Java, Kotlin, C and C++ are the official languages for app developers. Chrome even has less Rust than Firefox. Linux has some baby adoption, and it isn't without drama, even with Microsoft and Google pushing for it.

Rust will never be in Android user space, because it's not competing with Kotlin. Kotlin is already excellent there. Rust will replace the parts of Android written in C++ gradually. That was always the plan. It feels weird and cope-y to move the goalposts to say it's not a big deal unless Rust also replaces Kotlin.

Chrome only needs to replace the parts of their codebase that handle untrusted input with Rust to get substantial benefits. Like codec parsers. They don't need to rewrite everything, just the parts that need rewriting. The parts that are impossible to get right in C++, to the point where Chrome spins up separate processes to run that code.

Rust is the future for Android, and it will become an important of Chrome and Linux and git (starting 3.0). That's just the way it is.

Post reply on HN