8 ms·

I 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 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. [0]: https://youtu.be/PKxsOlzuH0k?si=-88dxtyegTxIvOYI https://youtu.be/PKxsOlzuH0k?si=-88dxtyegTxIvOYI

QuaternionsBhop 7mo ago
> Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile; I didn't understand that you were making fun of verbosity until the word 'domicile'. I must be one of those insufferable people who expresses simple thoughts with ornate vocabulary... The article was comprehensible to me, and the additional function colorings sound like exciting constraints I can impose to prevent my future self from making mistakes rather than heavy winter gear. I guess I'm closer to the target audience?
baby 7mo ago
I really think that golang makes it easy to read code, rust makes it easy to write code. If Golang had sum types it would be a much nicer language to write complex applications with
- nine_k 7mo ago
  Golang makes easy-to-skim code, with all the `if err != nil` after every function call. Rust requires actual reading, like Typescript, only more detailed.
- haileys 7mo ago
  I find Go code mind numbing to read. There's just _so much of it_ that the parts of the code that should jump out at me for requiring greater attention get lost in the noise. Interfaces also make reading Go more difficult than it could be without LSP - there's no `impl Xyz for` to grep for.
  - usrnm 7mo ago
    It's the complete opposite for me. Rust code, especially async Rust code is just full of noise the only purpose of which is to make the borrow checker shut up
- 9rx 7mo ago
  Go does have sum types — but the syntax is awkward and a bit transparent, so many don't recognize it as being there, and those that do don't love using it.
  - School-Cotton 7mo ago
    Can you enlighten us to what you’re talking about instead of vagueposting like this? What’s the supposed way of simulating sum types in go?
    - 9rx 7mo ago
      I am not sure how would you would simulate them. With enums and structs, I suppose? However, it also has true sum types: type SumType interface { isSumType() } type A string func (A) isSumType() type B int func (B) isSumType() But as you can see the syntax leaves a lot to be desired and may not be all that obvious to those who are hung up thinking in other languages.
nemothekid 7mo ago
I've been on both sides of the fence here - I've bounced between two camps: 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. 2. A widely used, production, systems language that implements PL-theory up until the year ~2000. (Effects, as described in this article, was a research topic in 1999). I started with (1), but as I started to get more and more exposed to (2), you start looking back on times when you fought with the type system and how some of these PL-nerds have a point. I think my first foray into Higher-Kinded Types was trying to rewrite a dynamic python dispatch system into Rust while keeping types at compile time. The problem is, many of these PL-nerd concepts are rare and kind of hard to grok at first, and I can easily see them scaring people off from the language. However I think once you understand how they work, and the PL-nerds dumb down the language, I think most people will come around to them. Concepts like "sum types" and "monads", are IMO easy to understand concepts with dumb names, and even more complex standard definitions.
- kelipso 7mo ago
  Yeah, (non sarcastically) give those things dumb names like borrow checker and you'll get people swooning over it.
- Horusiath 7mo ago
  > 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. I was looking for something like that and eventually found Crystal (https://crystal-lang.org https://crystal-lang.org) as a closest match: LLVM compiled, strong static typing with explicit nulls and very good type inference, stackfull coroutines, channels etc.
  - brabel 7mo ago
    Crystal is a typed Ruby. The closer to Go language would probably be Odin.
    - mastermage 7mo ago
      Odin is more of an alternative C than Go. V is inspired by Go has like nearly the same syntax as Go and alot of Goodies. Like Error Types, Sum Types and more.
sam0x17 7mo ago
I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work in. Having language level support for something like this where I add an extra word to my function def and the compiler guarantees the above would be groundbreaking
- chirsz 7mo ago
  You can see: * no-panic: https://docs.rs/no-panic/latest/no_panic/ https://docs.rs/no-panic/latest/no_panic/ * Safe Rust has no undefined behavior: https://news.ycombinator.com/item?id=39564755 https://news.ycombinator.com/item?id=39564755
  - andriy_koval 7mo ago
    would be great to have no alloc too as op requested.
- rapnie 7mo ago
  Perhaps there are similarities to Scala, from my anecdotal observation. Coming from Java and doing the Scala coursera course years ago, it feels like arriving in a candy shop. All the wonderful language features are there, true power yours to wield. And then you bump into the code lines crafted by the experts, and they are line for line so 'smart' they take a real long time to figure out how the heck it all fits together. People say "Rust is more complex to onboard to, but it is worth it", but a lot of the onboarding hurdle is the extra complexity added in by experts being smart. And it may be a reason why a language doesn't get the adoption that the creators hoped for (Scala?). Rust does not have issues with popularity, and the high onboarding barrier, may have positive impact eventually where "Just rewrite it in Rust" is no more, and people only choose Rust where it is most appropriate. Use the right language for the tool. The complexity of Rust made me check out Gleam [0], a language designed for simplicity, ease of use, and developer experience. A wholly different design philosophy. But not less powerful, as a BEAM language that compiles to Erlang, but also compiles to Javascript if you want to do regular web stuff. [0] https://gleam.run https://gleam.run
olalonde 7mo ago
Can we get a version of Rust that swaps lifetimes and ownership for a GC and a JS-style event loop? I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker.
- pharrington 7mo ago
  https://ocaml.org/ https://ocaml.org/
  - zozbot234 7mo ago
    ReasonML if you want a slightly more Rustic syntax.
- widdershins 7mo ago
  https://gleam.run https://gleam.run
- secondcoming 7mo ago
  Then why are you using rust for these tasks?
  - olalonde 7mo ago
    I'm not.
- harpiaharpyja 7mo ago
  I mean, you're asking for a fundamentally different directing for the language with different tradeoffs? Why are you commenting on an article about Rust? Not everyone wants the same tradeoffs that you do.
- andriy_koval 7mo ago
  > I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker. you can use smart pointers everywhere and stop be bothered by borrow checker.
rob74 7mo ago
I experienced the same kind of fatigue when I read "there are three directions of development which I find particularly interesting: [three things I never heard about nor particularly want to get familiar with]" in the article. And later, when I read "Because though we’re not doing too bad, we’re no Ada/SPARK yet" I couldn't help thinking that there must be a reason why those languages never became mainstream, and if Rust gets more of these exciting esoteric features, it's probably headed the same way...
gignico 7mo ago
I think the misunderstanding here is that the article was not intended to users but to other language designers. As a user, using a feature such as pattern types will be natural if you know the rest of the language. Do you have a function that accepts an enum `MyEnum` but has an `unreachable!()` for some variant that you know is impossible to have at that point? Then you can accept a `MyEnum is MyEnum::Variant | MyEnum::OtherVariant` instead of `MyEnum` to tell which are the accepted variants, and the pattern match will not require that `unreachable!()` anymore. The fact someone does not know this is called "refinement types" does not limit their ability to use the feature effectively.
- thomasmg 7mo ago
  > the article was not intended to users but to other language designers. That might be true, but it shows the direction that Rust is talking: put in the kitchen sink, just like C++ and Scala did. And _that_ is very much important for users.
  - gignico 7mo ago
    I'm not sure it shows that. Even basic features of Rust we take from granted come from concepts common users do not need to understand. Borrowing of lifetime draws from affine types, but nobody cares when writing Rust code. If in 2012 you read a similar article explaining borrow checking in academic terms you would have thought Rust would be unusably hard, which is not. Also I do not think that adding features is always bad to the point of comparing with Scala. Most of the things the article mentions will be almost invisible to users. For example, the `!Forget` thing it mentions will just end up with users getting new errors for things that before would have caused memory leaks. What a disgrace! Then, pattern types allow you to remove panics from code, which is super helpful in many critical contexts where Rust is used in production, even in the Linux kernel once they will bump the language version so far.
    - zozbot234 7mo ago
      > If in 2012 you read a similar article explaining borrow checking in academic terms you would have thought Rust would be unusably hard, which is not. Ironically, Rust was unusably hard prior to the late-2018 edition. So now your academic article has to explain both the baseline borrow checker and non-lexical lifetimes, a vast increase in complexity.
ajxs 7mo ago
At the risk of sounding like a language zealot, have you ever looked at Ada? It was explicitly designed to be very readable, and for use in safety-critical systems. Ada isn't perfect in all the ways Rust isn't, and it might not be the right choice for your system, but if you're writing systems software it's worth a look. If you're writing a web backend on the other hand, it's not worth a look at all.
- 9rx 7mo ago
  Unless you are going back to CGI, web backends are systems.
tormeh 7mo ago
Nothing can really save you from architecture astronauts, except possibly Go, but I hear there are people templating Go with preprocessors, so who knows. This is a human problem. On the other hand I hear you. The moment Rust gets proper async traits an entire world of hexagonal pain will open up for the victims of the astronauts. So it will get even worse, basically. I think if we could solve the problem of bored smart people sabotaging projects it'd be amazing.
63stack 7mo ago
I don't think this is an old man rant, I think you made a reasonable argument. Rust is certainly at risk of becoming just as complex as c++. I would love to introduce more rust at work, but I dread that someone is going to ask about for<'a>, use<'a>, differences between impl X vs Box<dyn X>, or Pin/Unpin, and I don't have proper answers either.
- andriy_koval 7mo ago
  > but I dread that someone is going to ask about for<'a>, use<'a>, differences between impl X vs Box<dyn X>, or Pin/Unpin, and I don't have proper answers either. its an issue in "someone", all those answers can be received in under 1min from AI.
devnullbrain 7mo ago
A state machine is a perfect example of a case where you would benefit from linear types. Some things just need precise terminology so humans can communicate about them to humans without ambiguity. It doesn't mean they're inherently complex: the article provides simple definitions. It's the same for most engineering, science and language. One of the most valuable skills I've learned in my career is to differentiate between expressions, statements, items, etc. - how often have you heard that the hardest problem in software development is coordinating with other developers? If you learn proper terminology, you can say exactly what you mean. Simple language doesn't mean more clear. I wasn't born knowing Rust, I had to learn it. So I'm always surprised by complaints about Rust being too complex directed at the many unremarkable people who have undergone this process without issues. What does it say, really? That you're not as good as them at learning things? In what other context do software people on the internet so freely share self-doubt? I also wonder about their career plans for the future. LLMs are already capable of understanding these concepts. The tide is rising.
kibwen 7mo ago
> I genuinely struggled to follow the concepts in this article I read the HN comments before I read the OP, which made me worry that the post was going to be some hifalutin type wonkiness. But instead the post is basically completely milquetoast, ordinary and accessible. I'm no type theorist--I cannot tell you what a monad is--and I confess that I don't understand how anyone could be intimidated by this article.
- Folcon 7mo ago
  I think you're underestimating your competency Things like effects aren't obvious to people, at least based on my experience of trying to teach it to people
  - wasabi991011 7mo ago
    I don't agree, the article isn't going deep into effects. The intro where they describe effects as essentially being "function colors" (referring to another article fairly often linked in hackernews) plus give lots of concrete examples (async, const, try) seems like more than enough to be obvious to the readers.
dilawar 7mo ago
> 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. At a new job, I am writing my first microservice in golang. Used to be a Rust/C++ (kernel) and Python/PHP/JS dev (fullstack). Rust is allowed by team is heavily invested in go already.. I don't think I'll be able to convince them to learn rust! Lol
harpiaharpyja 7mo ago
Look, included in the concepts the article discusses are features that people have been wanting for a very long time. Like, the ability to have multiple mut references to a struct as long as you access disjoint fields? That's amazing!!! A redo of Pin that actually composes with the rest of the language? That's pretty awesome too. I think you're getting tied up because the the author is describing these features in a very formal way. But someone has to think about these things, especially if they are going to implement them. Ultimately, these are features that will make Rust's safety features (which really, are Rust's reason for existing) more ergonomic and easier to use. That's the opposite of what you fear.
deleted 7mo ago
[deleted]
keybored 7mo ago
Rust is complex enough as-is. There is definitely a learning curve. But these top-comments sometimes paint with a broad brush. As in this case. > 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. Two paragraphs in and nothing concrete yet. We can contrast with the article. Let’s just consider the Effects section. It describes four examples: functions that 1) don’t unwind, 2) guaranteed termination, 3) are deterministic 4) do not “call host APIs”, which is “IO” somehow? (this last one seems a bit off) The first point is about not panicking (keyword panic given). Point two is about not looping forever, for example. Point three can be contrasted with non-determinism. Is that jargony? A fancy-pants term for something simpler? The fourth point seems a bit, I don’t know, could be rewritten. All of these at least attempt to describe concrete things that you get out of an “effects system”. > 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. This is just a parade of the usual adjectives with an unexplained analogy thrown in (how will these additions cripple Rust usage?). “So complex”, “over-engineered safety”, “complexity” (again), “poorly thought-throught solutions”. TFA is about concrete things. OP here is a bunch of adjectives. And a bunch of words about complexity and not understanding would be fine if TFA did not have any understandable, practical parts. But as we’ve gone over it does... People see Rust. Then they see a comment reacting to nondescript complexity. The rest is history. A good anti-complexity comment would address something concrete like Async Rust. And there are plenty of such comments to vote on.
nine_k 7mo ago
As I was getting into computers as a teenager, a teacher warned me that the area is such that I would have to learn new things constantly, without end. I said, fine, what's not to like? But I now realize that as people grow, their desire to learn new things sometimes fades, and an illusion of "already knowing enough" may set in. Don't trust that illusion. We still have to learn new things every day. (And new fancy words for simple concepts is the easy part.)

QuaternionsBhop 7mo ago

> Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile; I didn't understand that you were making fun of verbosity until the word 'domicile'. I must be one of those insufferable people who expresses simple thoughts with ornate vocabulary... The article was comprehensible to me, and the additional function colorings sound like exciting constraints I can impose to prevent my future self from making mistakes rather than heavy winter gear. I guess I'm closer to the target audience?

baby 7mo ago

I really think that golang makes it easy to read code, rust makes it easy to write code. If Golang had sum types it would be a much nicer language to write complex applications with

nine_k 7mo ago
Golang makes easy-to-skim code, with all the `if err != nil` after every function call. Rust requires actual reading, like Typescript, only more detailed.
haileys 7mo ago
I find Go code mind numbing to read. There's just _so much of it_ that the parts of the code that should jump out at me for requiring greater attention get lost in the noise. Interfaces also make reading Go more difficult than it could be without LSP - there's no `impl Xyz for` to grep for.
- usrnm 7mo ago
  It's the complete opposite for me. Rust code, especially async Rust code is just full of noise the only purpose of which is to make the borrow checker shut up
9rx 7mo ago
Go does have sum types — but the syntax is awkward and a bit transparent, so many don't recognize it as being there, and those that do don't love using it.
- School-Cotton 7mo ago
  Can you enlighten us to what you’re talking about instead of vagueposting like this? What’s the supposed way of simulating sum types in go?
  - 9rx 7mo ago
    I am not sure how would you would simulate them. With enums and structs, I suppose? However, it also has true sum types: type SumType interface { isSumType() } type A string func (A) isSumType() type B int func (B) isSumType() But as you can see the syntax leaves a lot to be desired and may not be all that obvious to those who are hung up thinking in other languages.

nemothekid 7mo ago

I've been on both sides of the fence here - I've bounced between two camps: 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. 2. A widely used, production, systems language that implements PL-theory up until the year ~2000. (Effects, as described in this article, was a research topic in 1999). I started with (1), but as I started to get more and more exposed to (2), you start looking back on times when you fought with the type system and how some of these PL-nerds have a point. I think my first foray into Higher-Kinded Types was trying to rewrite a dynamic python dispatch system into Rust while keeping types at compile time. The problem is, many of these PL-nerd concepts are rare and kind of hard to grok at first, and I can easily see them scaring people off from the language. However I think once you understand how they work, and the PL-nerds dumb down the language, I think most people will come around to them. Concepts like "sum types" and "monads", are IMO easy to understand concepts with dumb names, and even more complex standard definitions.

kelipso 7mo ago
Yeah, (non sarcastically) give those things dumb names like borrow checker and you'll get people swooning over it.
Horusiath 7mo ago
> 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. I was looking for something like that and eventually found Crystal (https://crystal-lang.org https://crystal-lang.org) as a closest match: LLVM compiled, strong static typing with explicit nulls and very good type inference, stackfull coroutines, channels etc.
- brabel 7mo ago
  Crystal is a typed Ruby. The closer to Go language would probably be Odin.
  - mastermage 7mo ago
    Odin is more of an alternative C than Go. V is inspired by Go has like nearly the same syntax as Go and alot of Goodies. Like Error Types, Sum Types and more.

sam0x17 7mo ago

I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work in. Having language level support for something like this where I add an extra word to my function def and the compiler guarantees the above would be groundbreaking

chirsz 7mo ago
You can see: * no-panic: https://docs.rs/no-panic/latest/no_panic/ https://docs.rs/no-panic/latest/no_panic/ * Safe Rust has no undefined behavior: https://news.ycombinator.com/item?id=39564755 https://news.ycombinator.com/item?id=39564755
- andriy_koval 7mo ago
  would be great to have no alloc too as op requested.
rapnie 7mo ago
Perhaps there are similarities to Scala, from my anecdotal observation. Coming from Java and doing the Scala coursera course years ago, it feels like arriving in a candy shop. All the wonderful language features are there, true power yours to wield. And then you bump into the code lines crafted by the experts, and they are line for line so 'smart' they take a real long time to figure out how the heck it all fits together. People say "Rust is more complex to onboard to, but it is worth it", but a lot of the onboarding hurdle is the extra complexity added in by experts being smart. And it may be a reason why a language doesn't get the adoption that the creators hoped for (Scala?). Rust does not have issues with popularity, and the high onboarding barrier, may have positive impact eventually where "Just rewrite it in Rust" is no more, and people only choose Rust where it is most appropriate. Use the right language for the tool. The complexity of Rust made me check out Gleam [0], a language designed for simplicity, ease of use, and developer experience. A wholly different design philosophy. But not less powerful, as a BEAM language that compiles to Erlang, but also compiles to Javascript if you want to do regular web stuff. [0] https://gleam.run https://gleam.run

olalonde 7mo ago

Can we get a version of Rust that swaps lifetimes and ownership for a GC and a JS-style event loop? I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker.

pharrington 7mo ago
https://ocaml.org/ https://ocaml.org/
- zozbot234 7mo ago
  ReasonML if you want a slightly more Rustic syntax.
widdershins 7mo ago
https://gleam.run https://gleam.run
secondcoming 7mo ago
Then why are you using rust for these tasks?
- olalonde 7mo ago
  I'm not.
harpiaharpyja 7mo ago
I mean, you're asking for a fundamentally different directing for the language with different tradeoffs? Why are you commenting on an article about Rust? Not everyone wants the same tradeoffs that you do.
andriy_koval 7mo ago
> I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker. you can use smart pointers everywhere and stop be bothered by borrow checker.

rob74 7mo ago

I experienced the same kind of fatigue when I read "there are three directions of development which I find particularly interesting: [three things I never heard about nor particularly want to get familiar with]" in the article. And later, when I read "Because though we’re not doing too bad, we’re no Ada/SPARK yet" I couldn't help thinking that there must be a reason why those languages never became mainstream, and if Rust gets more of these exciting esoteric features, it's probably headed the same way...

gignico 7mo ago

I think the misunderstanding here is that the article was not intended to users but to other language designers. As a user, using a feature such as pattern types will be natural if you know the rest of the language. Do you have a function that accepts an enum `MyEnum` but has an `unreachable!()` for some variant that you know is impossible to have at that point? Then you can accept a `MyEnum is MyEnum::Variant | MyEnum::OtherVariant` instead of `MyEnum` to tell which are the accepted variants, and the pattern match will not require that `unreachable!()` anymore. The fact someone does not know this is called "refinement types" does not limit their ability to use the feature effectively.

thomasmg 7mo ago
> the article was not intended to users but to other language designers. That might be true, but it shows the direction that Rust is talking: put in the kitchen sink, just like C++ and Scala did. And _that_ is very much important for users.
- gignico 7mo ago
  I'm not sure it shows that. Even basic features of Rust we take from granted come from concepts common users do not need to understand. Borrowing of lifetime draws from affine types, but nobody cares when writing Rust code. If in 2012 you read a similar article explaining borrow checking in academic terms you would have thought Rust would be unusably hard, which is not. Also I do not think that adding features is always bad to the point of comparing with Scala. Most of the things the article mentions will be almost invisible to users. For example, the `!Forget` thing it mentions will just end up with users getting new errors for things that before would have caused memory leaks. What a disgrace! Then, pattern types allow you to remove panics from code, which is super helpful in many critical contexts where Rust is used in production, even in the Linux kernel once they will bump the language version so far.
  - zozbot234 7mo ago
    > If in 2012 you read a similar article explaining borrow checking in academic terms you would have thought Rust would be unusably hard, which is not. Ironically, Rust was unusably hard prior to the late-2018 edition. So now your academic article has to explain both the baseline borrow checker and non-lexical lifetimes, a vast increase in complexity.

ajxs 7mo ago

At the risk of sounding like a language zealot, have you ever looked at Ada? It was explicitly designed to be very readable, and for use in safety-critical systems. Ada isn't perfect in all the ways Rust isn't, and it might not be the right choice for your system, but if you're writing systems software it's worth a look. If you're writing a web backend on the other hand, it's not worth a look at all.

9rx 7mo ago
Unless you are going back to CGI, web backends are systems.

tormeh 7mo ago

Nothing can really save you from architecture astronauts, except possibly Go, but I hear there are people templating Go with preprocessors, so who knows. This is a human problem. On the other hand I hear you. The moment Rust gets proper async traits an entire world of hexagonal pain will open up for the victims of the astronauts. So it will get even worse, basically. I think if we could solve the problem of bored smart people sabotaging projects it'd be amazing.

63stack 7mo ago

I don't think this is an old man rant, I think you made a reasonable argument. Rust is certainly at risk of becoming just as complex as c++. I would love to introduce more rust at work, but I dread that someone is going to ask about for<'a>, use<'a>, differences between impl X vs Box<dyn X>, or Pin/Unpin, and I don't have proper answers either.

andriy_koval 7mo ago
> but I dread that someone is going to ask about for<'a>, use<'a>, differences between impl X vs Box<dyn X>, or Pin/Unpin, and I don't have proper answers either. its an issue in "someone", all those answers can be received in under 1min from AI.

devnullbrain 7mo ago

A state machine is a perfect example of a case where you would benefit from linear types. Some things just need precise terminology so humans can communicate about them to humans without ambiguity. It doesn't mean they're inherently complex: the article provides simple definitions. It's the same for most engineering, science and language. One of the most valuable skills I've learned in my career is to differentiate between expressions, statements, items, etc. - how often have you heard that the hardest problem in software development is coordinating with other developers? If you learn proper terminology, you can say exactly what you mean. Simple language doesn't mean more clear. I wasn't born knowing Rust, I had to learn it. So I'm always surprised by complaints about Rust being too complex directed at the many unremarkable people who have undergone this process without issues. What does it say, really? That you're not as good as them at learning things? In what other context do software people on the internet so freely share self-doubt? I also wonder about their career plans for the future. LLMs are already capable of understanding these concepts. The tide is rising.

kibwen 7mo ago

> I genuinely struggled to follow the concepts in this article I read the HN comments before I read the OP, which made me worry that the post was going to be some hifalutin type wonkiness. But instead the post is basically completely milquetoast, ordinary and accessible. I'm no type theorist--I cannot tell you what a monad is--and I confess that I don't understand how anyone could be intimidated by this article.

Folcon 7mo ago
I think you're underestimating your competency Things like effects aren't obvious to people, at least based on my experience of trying to teach it to people
- wasabi991011 7mo ago
  I don't agree, the article isn't going deep into effects. The intro where they describe effects as essentially being "function colors" (referring to another article fairly often linked in hackernews) plus give lots of concrete examples (async, const, try) seems like more than enough to be obvious to the readers.

dilawar 7mo ago

> 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. At a new job, I am writing my first microservice in golang. Used to be a Rust/C++ (kernel) and Python/PHP/JS dev (fullstack). Rust is allowed by team is heavily invested in go already.. I don't think I'll be able to convince them to learn rust! Lol

harpiaharpyja 7mo ago

Look, included in the concepts the article discusses are features that people have been wanting for a very long time. Like, the ability to have multiple mut references to a struct as long as you access disjoint fields? That's amazing!!! A redo of Pin that actually composes with the rest of the language? That's pretty awesome too. I think you're getting tied up because the the author is describing these features in a very formal way. But someone has to think about these things, especially if they are going to implement them. Ultimately, these are features that will make Rust's safety features (which really, are Rust's reason for existing) more ergonomic and easier to use. That's the opposite of what you fear.

deleted 7mo ago

[deleted]

keybored 7mo ago

Rust is complex enough as-is. There is definitely a learning curve. But these top-comments sometimes paint with a broad brush. As in this case. > 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. Two paragraphs in and nothing concrete yet. We can contrast with the article. Let’s just consider the Effects section. It describes four examples: functions that 1) don’t unwind, 2) guaranteed termination, 3) are deterministic 4) do not “call host APIs”, which is “IO” somehow? (this last one seems a bit off) The first point is about not panicking (keyword panic given). Point two is about not looping forever, for example. Point three can be contrasted with non-determinism. Is that jargony? A fancy-pants term for something simpler? The fourth point seems a bit, I don’t know, could be rewritten. All of these at least attempt to describe concrete things that you get out of an “effects system”. > 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. This is just a parade of the usual adjectives with an unexplained analogy thrown in (how will these additions cripple Rust usage?). “So complex”, “over-engineered safety”, “complexity” (again), “poorly thought-throught solutions”. TFA is about concrete things. OP here is a bunch of adjectives. And a bunch of words about complexity and not understanding would be fine if TFA did not have any understandable, practical parts. But as we’ve gone over it does... People see Rust. Then they see a comment reacting to nondescript complexity. The rest is history. A good anti-complexity comment would address something concrete like Async Rust. And there are plenty of such comments to vote on.

nine_k 7mo ago

As I was getting into computers as a teenager, a teacher warned me that the area is such that I would have to learn new things constantly, without end. I said, fine, what's not to like? But I now realize that as people grow, their desire to learn new things sometimes fades, and an illusion of "already knowing enough" may set in. Don't trust that illusion. We still have to learn new things every day. (And new fancy words for simple concepts is the easy part.)