Thank God for Zig
My “grand vision” for Rust
91–100 of 323 posts
Re: My “grand vision” for Rust
#92This may be too much advanced type theory for a useful language. You can go all the way to formal verification. This is not enough for that. Or you can stop at the point all memory error holes have been plugged. That's more useful. You can go way overboard with templates/macros/traits/generics. Remember C++ and Boost. I understand that Boost is now deprecated. I should work some more on my solution to the back-refere…
> This may be too much advanced type theory for a useful language.
I think a lot of things taken for granted these days were considered "too complicated" some time ago: think of how widespread pattern matching, closures, generics, or functional idioms in imperative languages are, and compare to e.g. Java 1.0.
My feeling is that the "acceptable level of complexity" for programming languages goes up over time, so probably stuff like effect types will be almost everywhere in another 10 years.
Re: My “grand vision” for Rust
#93Earlier quoted context omitted.
Compared to the other languages listed in this thread, it definitely is, and it has production systems unlike them. https://news.ycombinator.com/item?id=47259148
Ever heard of Apple, Facebook, Jane Street, HP?
I think they were saying haskell is a production language
Re: My “grand vision” for Rust
#94I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor.
I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing their code and especially inheriting "legacy" implementations. It's like having a conversation with someone who expresses simple thoughts with ornate vocabulary. Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile; Or simply put, I get tired and want to go home.
Rust's safety guardrails are valuable until the language becomes so complex that reading and reasoning about _business_ logic gets harder, not easier. It reminds me of the kid in "A Christmas Story" bundled so heavily in winter gear he cant put his arms down[0]. At some point, over-engineered safety becomes its own kind of risk even though it is technically safer in some regards. Sometimes you need to just implement a dang state machine and stop throwing complexity at poorly thought-through solutions. End old-man rant.
Re: My “grand vision” for Rust
#95Reposting my comment from Reddit, I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. That is how we end with other ecosystems doubling down in automatic memory management with a good enough ownership model for low level coding, e.g. Swift 6, OxCaml, Chapel, D, Linear Haskel, OCaml effects,... Where the goal is that those features are to be used by experts,…
> I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. I don't know if it is true or not, but my feeling is that Scala brought a lot of new ideas. But as I read somewhere, "Scala was written by compiler people, to write compilers", and I can understand that feeling. Kotlin came after Scala (I think?) and seems to have gotten a lot of inspiration from Scala.…
> But somehow Kotlin managed to stay "not too complex", unlike Scala.
It's not really true anymore, Kotlin has slowly absorbed most of the same features and ideas even though they're sometimes pretty half-baked, and it's even less principled than the current Scala ecosystem. JetBrains also wants to make Kotlin target every platform under the sun.
At this point, the only notable difference are HKTs and Scala's metaprogramming abilities. Kotlin stuck to a compiler plugin exposing a standard interface (kotlinx.serialization) for compile-time codegen. Scala can do things like deriving an HTTP client from an OpenAPI specification on the fly, by the LSP backend.
Re: My “grand vision” for Rust
#96Earlier quoted context omitted.
Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types. To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero addit…
Exactly, hence why people should stop talking about editions as if they sort out all Rust evolution problems, in your own words it doesn't allow changing type semantics
I think you're too stuck on the current implementation. Work is going into investigating how to evolve the standard library over editions. The "easiest" win would be to have a way to do edition-dependent re-exports of types.
Re: My “grand vision” for Rust
#97Earlier quoted context omitted.
> I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. I don't know if it is true or not, but my feeling is that Scala brought a lot of new ideas. But as I read somewhere, "Scala was written by compiler people, to write compilers", and I can understand that feeling. Kotlin came after Scala (I think?) and seems to have gotten a lot of inspiration from Scala.…
> But somehow Kotlin managed to stay "not too complex", unlike Scala. It's not really true anymore, Kotlin has slowly absorbed most of the same features and ideas even though they're sometimes pretty half-baked, and it's even less principled than the current Scala ecosystem. JetBrains also wants to make Kotlin target every platform under the sun. At this point, the only notable difference are HKTs and Scala's metapro…
> JetBrains also wants to make Kotlin target every platform under the sun
So did Scala long before. It's just that Kotlin got a lot more traction for different reasons.
Re: My “grand vision” for Rust
#98Earlier quoted context omitted.
What you're describing sounds more like a potential issue with editions if/when they allow breaking stdlib changes more than a problem with editions as they exist today, which is more what I took the original comment to be talking about.
Exactly because they don't allow it, they don't cover all scenarios regarding language evolution
OK, sure, but again what breaking changes editions do/don't currently allow is independent from what SkiFire13/I was responding to, which was the "requires full access to source code" bit.
Re: My “grand vision” for Rust
#99When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the kernel gets mutated. I believe the socket interface may have been intended to support queuing which is perhaps why it needed to be mutable. I might have needed a lower level api. I just mention this because I think it’s interesting as to how it should be typed when mutation is external to the app. I didn’t follow through on using Rust and this was long ago so I’m sure some details are wrong.
Re: My “grand vision” for Rust
#100Earlier quoted context omitted.
> But somehow Kotlin managed to stay "not too complex", unlike Scala. It's not really true anymore, Kotlin has slowly absorbed most of the same features and ideas even though they're sometimes pretty half-baked, and it's even less principled than the current Scala ecosystem. JetBrains also wants to make Kotlin target every platform under the sun. At this point, the only notable difference are HKTs and Scala's metapro…
> JetBrains also wants to make Kotlin target every platform under the sun So did Scala long before. It's just that Kotlin got a lot more traction for different reasons.
Not to the same extent. Scala.JS and Kotlin.JS are somewhat comparable, other targets not so much. There was no serious attempt at making Scala target mobile devices, even during the window of opportunity with Scala on Android.