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

Writing a Kubernetes CRD Controller in Rust

technosophos.com

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Writing a Kubernetes CRD Controller in Rust

#71

Post by throwaway894345 »

skohan wrote: post #70
throwaway894345 wrote: post #67

Earlier quoted context omitted.

> In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I think it depends on your domain. If you are working in a mission-critical space where every bit of static analysis saves hours or days of testing, then yeah, the more static analysis the better. If you’re building web systems software (things like Kub…

Yeah I agree - Rust does have more static checking than is strictly needed for many domains. But I think the reason for that is strictly orthogonal to type safety - rather it's because Rust's approach to memory management is a lot more demanding on the programmer than GC. Speaking only in terms of type systems, I think Rust's features - like algebraic types and explicit nullability - are strictly better than Go and m…

> But I think the reason for that is strictly orthogonal to type safety - rather it's because Rust's approach to memory management is a lot more demanding on the programmer than GC.

Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate. I don’t know that this can be considered “orthogonal to type safety” in a meaningful way.

> Speaking only in terms of type systems, I think Rust's features - like algebraic types and explicit nullability - are strictly better than Go and make it easier to write correct code. It just happens to be that this benefit is eclipsed by all the ceremony required to satisfy the borrow checker.

Yeah, I completely agree. Go with ADTs would be a significant improvement. I would really like to see someone write a language like this that is interoperable with Go (compiles to idiomatic Go to the extent possible).

> I actually think Swift as a language is plenty ready for general purpose programming. The problem is the tooling.

Hmm, well I hope it finds its feet. It certainly seems like it would be a welcome addition.

Re: Writing a Kubernetes CRD Controller in Rust

#72

Post by skohan »

throwaway894345 wrote: post #71
skohan wrote: post #70

Earlier quoted context omitted.

Yeah I agree - Rust does have more static checking than is strictly needed for many domains. But I think the reason for that is strictly orthogonal to type safety - rather it's because Rust's approach to memory management is a lot more demanding on the programmer than GC. Speaking only in terms of type systems, I think Rust's features - like algebraic types and explicit nullability - are strictly better than Go and m…

> But I think the reason for that is strictly orthogonal to type safety - rather it's because Rust's approach to memory management is a lot more demanding on the programmer than GC. Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate. I don’t know that this can be considered “orthogonal to type safety” in a meaningful way. > Speaking only in terms of type systems, I think Rust's featu…

> Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate.

Ok fair enough. I guess mentally I separate the ownership/lifetime system from the type system, but I suppose it's true that borrows, mutable borrows etc. are actually part of the type system.

Re: Writing a Kubernetes CRD Controller in Rust

#73

Post by throwaway894345 »

skohan wrote: post #72
throwaway894345 wrote: post #71

Earlier quoted context omitted.

> But I think the reason for that is strictly orthogonal to type safety - rather it's because Rust's approach to memory management is a lot more demanding on the programmer than GC. Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate. I don’t know that this can be considered “orthogonal to type safety” in a meaningful way. > Speaking only in terms of type systems, I think Rust's featu…

> Rust lacks a GC so it uses its type system (namely its borrow checker) to compensate. Ok fair enough. I guess mentally I separate the ownership/lifetime system from the type system, but I suppose it's true that borrows, mutable borrows etc. are actually part of the type system.

Yeah, it’s a bit pedantic, but I wanted to be precise for clarity.

Re: Writing a Kubernetes CRD Controller in Rust

#74

Post by yawaramin »

throwaway894345 wrote: post #68
yawaramin wrote: post #41

Earlier quoted context omitted.

I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).

I really wanted to like OCaml for the reasons you mentioned, but the ecosystem seems to be a mess with several “standard libraries”, mediocre tooling, and a dearth of libraries. Moreover, the language is still working to get its parallelism story out the door and Windows support is either lacking or non-existent (I forget which). The documentation is also rather poor, to the extent that I would often try to infer the…

Libraries, documentation, tooling--all fixable and all being worked on. Without mega-corp support, of course, so it will take more time. But even today it's absolutely usable for many scenarios.

Multicore--Node, Ruby, Python etc. all seem to be doing fine without it. Nevertheless, it's coming with OCaml 5--this year.

Windows--support has gotten better over the last few years but still being worked on.

Hostility--don't know what to tell you about that one--it's not my everyday experience. Sounds like a one-off.

Syntax and style guidelines--they are the way they are for a reason (no pun intended), and after a while when you understand the reason for each quirk, it just falls into place.

Table stakes features--many other languages out there, but IMHO the really table stakes features are being able to actually model your domain properly in a language. Which IMHO very few languages outside of OCaml get right. E.g. here's someone trying to propose abstract data types for Go without much luck: https://github.com/golang/go/issues/43123

Re: Writing a Kubernetes CRD Controller in Rust

#75

Post by yawaramin »

bbkane wrote: post #57
yawaramin wrote: post #41

Earlier quoted context omitted.

I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).

I haven't tried it, but I've heard OCaml has a much smaller community (fewer libraries and general knowledge) and a lack of tooling and corporate sponsorship- I know Jane Street works with it and they have their own version of a stdlib.

I encourage you to try it out to understand why the fuss.

Re: Writing a Kubernetes CRD Controller in Rust

#76

Post by dragonwriter »

yawaramin wrote: post #74
throwaway894345 wrote: post #68

Earlier quoted context omitted.

I really wanted to like OCaml for the reasons you mentioned, but the ecosystem seems to be a mess with several “standard libraries”, mediocre tooling, and a dearth of libraries. Moreover, the language is still working to get its parallelism story out the door and Windows support is either lacking or non-existent (I forget which). The documentation is also rather poor, to the extent that I would often try to infer the…

Libraries, documentation, tooling--all fixable and all being worked on. Without mega-corp support, of course, so it will take more time. But even today it's absolutely usable for many scenarios. Multicore--Node, Ruby, Python etc. all seem to be doing fine without it. Nevertheless, it's coming with OCaml 5--this year. Windows--support has gotten better over the last few years but still being worked on. Hostility--don'…

> Multicore--Node, Ruby, Python etc. all seem to be doing fine without it.

Ruby 3.0, released last month, has experimental parallel support via limited sharing “Ractors”.

Post reply on HN