39 ms·

From ESR's conclusion is this: > For comparison, I switched from Rust to Go and, in the same amount of time I had spent stuggling [sic] to make even a <100 LOC

From ESR's conclusion is this: > For comparison, I switched from Rust to Go and, in the same amount of time I had spent stuggling [sic] to make even a <100 LOC partial implementation work, was able to write and test the entire exterior of an IRC server - all the socket-fu and concurrency handling - leaving only the IRC-protocol state machine to be done. I don't think this is an unusual experience. I'd consider myself a journeyman programmer with 16 years of experience and probably a dozen languages under my belt. Learning Go was unique: after 3 days I felt productive; After 2 weeks I sort of looked around and said "is this it?" Go gets out of your way for the most part, and performs as advertised. For a lot of programmers, for a lot of projects, that's exactly what you want. I've attempted to learn Rust a few times, and it always feel like I'm moving uphill. Rust is awesome for a number of problem spaces, so I'm not knocking it. And Go _isn't_ awesome in a lot of ways (vendoring, I'm looking at you). But it feels like there are a lot of core, language-level things Rust needs to improve to attract more non-genius developers.

vvanders 10y ago
The thing with Rust is it doesn't let you get anything wrong. It's both a strength and weakness. There's a million edge cases that you can just ignore in many modern languages. A large part of the reason Javascript has taken off is it's ability to "get out of your way", however you pay for that in the long tail of issues and undefined things. Many projects in software are trying to prove out a concept, and in those cases is makes sense to move fast and find out if the core thing you're doing works. However in problem domains that are well understood or have strict performance/memory requirements Rust really shines. I think there's a strong argument that this is a subset of software(and probably not the majority) however I feel that unless you're taking a project to 100%(remember the last 10% takes 90% of your schedule) ESR's comparison isn't fair.
- MichaelGG 10y ago
  Whereas in C you can introduce subtle errors that might take forever to trigger, or silently corrupt things. Go still allows data races. Rust eliminates this. So, I guess you can "ignore" stuff in other languages and feel like it's working, with less guarantees it is actually right. Most of the things you need to do in C, Rust just codifies and enforces.
- tatterdemalion 10y ago
  Quick iteration on concepts is actually helped by not having to do extensive testing & maintenance work to keep your system from 500ing, which a static type system can help you do. The fact that dynamic languages don't care about your bugs is actually a hindrance. What dynamic languages have as an advantage is that they allow you to more readily change your system as your understanding of the requirements change. This is where static type systems have traditionally been very weak - they create roadblocks for evolutionary change. What would be great is a type system which catches your bugs but doesn't block you from evolving. I actually think Rust's use of type class polymorphism ("traits") goes a long way toward that goal, once you learn it.
  - woah 10y ago
    Flow does this. Never used Typescript but I assume it's similar. Flow really shines though because the typing is totally optional and has almost no impact on the JS patterns that you want to use.
jondot 10y ago
20 years journeyman here. If I could write my experience I would write what you did word by word about my feelings with Go and Rust. And I've tried many times - you nailed it. As an aside, I keep seeing people don't "get" this, and it is painfully unclear to me - why?. Perhaps the pool of people with 15-20 years that are still doing programming is very small, so they make very tiny noise.
- kaoD 10y ago
  >15 years programming here, from VB6 to JS including C(++/#), PHP, Java, Scala, many Lisps... I "get" what you mean, I just want to give my perspective: When I tried Go I just didn't get what it had to offer. It felt like the wheel, reinvented. I was like "That's it?". I can see how that's appealing but, for me, Rust is a stepping stone on what we should expect from programming languages of the future. A new language with a new paradigm is going to take longer to feel productive in, especially when the tooling and libraries aren't quite there yet. I can see how that's not good for someone who wants results now. Rust's ecosystem is very much in its infancy. I expect 2017 to be a great year in terms of both language ergonomics (e.g. see Rust Language Server) as well as stabilization/standardization of very important things like how to do concurrent I/O. If your niche is distributed computing (e.g. I/O bound servers), yes, Rust is currently not going to satisfy you. I think comparing Rust and Go is not fair for neither of them and, even if both are advertised as "systems languages" they are actually very different beasts filling their unique niches.
  - weberc2 10y ago
    I'm excited for Rust to improve. I keep wanting to use it, but I don't have any projects that need to be faster than I can make them with Go (and frequently with less effort than the naive Rust impl). If Rust's ergonomics improve enough (tooling, std lib, and core language), I might be able to justify it. Fingers crossed!
- ekidd 10y ago
  > Perhaps the pool of people with 15-20 years that are still doing programming is very small I'm at 20 years of paid, professional coding, and 30+ if you count my Apple IIe/gs days and fooling around with C++ as an undergrad. It took me about a week or two to make friends with the borrow checker, and mostly those were self-inflicted wounds from trying to write aggressive zero-copy code. I think that Rust works very well for certain coding styles, but the learning curve is much higher for other coding styles. If you've been scarred by C++ and you're used to treating variables as mostly immutable, the learning curve is pretty reasonable. But if you work in a style with a lot of mutability and you've never wrested with "const char *" versus "std::string" in C++ (which both exist for a good reason in C++), there's more to learn. So I could legitimately see it go either way. My handy litmus test: Do you utterly despise C++, or do you have a complicated love-hate relationship with it? If you fall in the latter group, you may fall in love with Rust on the first try. If you've never even used C++ enough to have an opinion, then it's possible you might not care about high-performance static languages and the prices they pay to go fast, and so Rust's trade-offs might not even be interesting to you.
twic 10y ago
With the mix of affection and disdain one traditionally feels for a younger brother, i refer to Go as "systems PHP". It may not be a sophisticated language; it may not produce beautiful code; it may, arguably, even have inexcusable flaws. But it is astoundingly easy to learn to the point where someone can be productive with it. This is a terrifically powerful, and very unusual, advantage for a language to have. Master programmers won't be choosing it as their tool of choice. It won't be used to attack the craft's hardest problems. But it allows a huge number of people to write programs they otherwise would not have been able to write, and, conversely, a huge number of programs to be written which otherwise would not have been written. There's something rather "quantity has a quality all its own" about it. As with PHP, this is something of a mixed blessing, but it certainly puts a dent in the world.
- wmf 10y ago
  Master programmers won't be choosing it as their tool of choice. It won't be used to attack the craft's hardest problems. I see almost the opposite, with many new distributed systems being written in Go.
  - ekidd 10y ago
    I use a lot of this distributed systems tooling on a day-to-day basis: Docker, Kubernetes, Vault, Pachyderm, etc., etc. It's all brilliant and innovative software and I'm glad to have it. But every time I need to dig down into the source code, I quickly realize why Docker falls over all the time with weird bugs, and why Vault's high-availability backend for etcd falls over once per week, and why Kubernetes is capable of inspiring such epic love-hate relationships. There's a ton of code in Docker where nil can sneak in, and where the types of certain data structures are harder to determine than they should be. Sometimes nil represents "none", and sometimes the empty string does. There's a bit of multithreaded stuff in Vault's etcd backend (or was) that doesn't understand the corner cases inherent in concurrency. I'm totally convinced that these new distributed tools are awesome and a boon to our industry. I just wish that somebody had a long conversation with a good type checker and thread safety checker at critical moments during the implementation process. This may be a classic case of the "New Jersey approach": https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html Software that's sufficiently innovative and which works will be forgiven odd corner cases and bugs.
tatterdemalion 10y ago
Do you have any specific examples of 'core, language-level things Rust needs to improve'? One of the most important goals of the 2017 roadmap is making the language more accessible, any actionable feedback is welcome.
- civility 10y ago
  Are you only asking the person you replied to? I have some topics I think indicate shortcomings in the language itself, but when I've brought these to the attention of core Rust developers in other threads of discussion the result hasn't been fruitful.
  - kibwen 10y ago
    Which topics, and which threads of discussion?
    - civility 10y ago
      I've had several discussions with you over the last couple years. I create throw away accounts on Hacker News, Stack Exchange, Reddit, Slashdot, Rust Users, and so on because I value my privacy. I don't want to tie my throw away accounts together, so I won't include links. My experiences discussing anything Rust related with you has generally gone like this: I list several things I think are problems. You refute a small nit in only one of them and neglect the rest of the message. Giving the impression that you've successfully refuted everything I've said, you tag on the stick-your-tongue-out smiley :P I've had other discussions with other core Rust developers. As should be expected, the conversations go differently for each.
      - kibwen 10y ago
        Feel free to link them to remind me of the arguments that I'm neglecting. :P
        civility 10y ago
agumonkey 10y ago
I'm not seasoned at all; but trying Go a day made me, more than productive, creative. I started to combine channels freeform and enjoy new ideas every minute, almost no cruft, almost no dead ends ... that's a rare thing. They did circle the concurrency pretty neatly in a nice usable interface.
zbobet2012 10y ago
> And Go _isn't_ awesome in a lot of ways (vendoring, I'm looking at you It's worth noting here there is a large, active team from the open source community working on fixing vendoring and package management right now. I believe the target is the Go 1.9 timeframe (end of Q2ish this year).
leshow 10y ago
I find that somewhat surprising. Are the dozen languages under your belt essentially variations of the same OO paradigms? I am mostly a javascript programmer, and a beginner at haskell, and I found Rust difficult not not that difficult.
tetha 10y ago
A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world. Go is an easy, fast, and very parallel language. Go is exactly what google needs, in all regards. It makes sense why Go exists, it makes sense why google is creating a way to migrate from python2 to go. Go is easier than hard C and Go is fast. Rust is the safe follow-up of C, but more familiar than Haskell, Caml and such. It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. But once rust runs, it works and there's a very very good chance it won't break. And that's also the reason why we'll probably build firewalls and hardened OS in derivatives of Haskell and Rust, and we'll build Google 2 and Facebook 2 in Go. And in my book, that's a good thing.
- tatterdemalion 10y ago
  > It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. I could not disagree more! Rust is a great joy to program in. I would rather program in Rust than any other language. Rust is challenging for many people to learn. That is very different.
  - zbobet2012 10y ago
    Language design is about trade-offs: The borrow checker and ownership model is a huge tradeoff. Even those very experienced in it still fight it from time to time. Go made a different trade, they chose GC. And GC _is_ easier. But it has computational overhead (well today anyway). Consider the cascading implications. Rust has a trait for Copy vs. Move types. This means every type has an implicit, and unknown behavior, on certain assignments: let v2 = v; println!("v is: {}", v); You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. But it is a trade-off. Go as a language must have a GC. It will never be suitable for certain tasks as a result. Go also has less compile time checking. This means faster compiles, quicker dev cycles but less compile time safety. Go chose easier here again. These trade-offs are what make rust seem "difficult" in comparison to go. I don't know if you can ever "fix" them.
zzzcpan 10y ago
> to attract more non-genius developers It's not like that, it's not hard to need geniuses, it's just too different for most people. And different takes time to learn. Which is definitely a design flaw for a language aiming for some adoption. I don't think they can improve it at this point, but they can provide a lot of value where other languages are weak.
qznc 10y ago
Your comment and others on Rust here sound a lot like people learning Haskell. There is a similar frustration with fighting the type system and weird concepts (Monads). I believe lazyness is the biggest problem with Haskell and Rust is eager, so Rust should be more successful than Haskell. The Go comments sound a lot like Java in the early days. Easy language. Quick to get started. Easy to get lots of programmers. If desperate, just train them. Today Java is not so simple anymore, because the Pros wanted more features (eg Generics). I believe Rust will get Generics at some point. Typesafe containers are too useful.
- kornish 10y ago
  I think you mean "I believe Go will get generics." Rust already has generics: https://doc.rust-lang.org/beta/book/generics.html https://doc.rust-lang.org/beta/book/generics.html. I certainly hope the Go authors can find an implementation of generics with a set of tradeoffs that appeal to them. Typesafe containers certainly are extremely useful.
  - civility 10y ago
    I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet: https://news.ycombinator.com/item?id=9622417 I agree, the value in generics/templates is in not cutting and pasting an algorithm or container to handle multiple types safely. A true macro system (and Rust's is pretty good one to model after) also solves this problem, and I wonder if Go would ever consider adding such a thing. It seems like a safer approach.
    - qznc 10y ago
      Did they consider the OCaml approach of "generic modules"? I would combine it with C++-style instantiation. By having it on the module level instead of functions/structs, you should be able to avoid the linker bloat. Are there OCaml users in the Go community? Also, there is the hybrid method between C++ and Java, which C# implements: Instantiation for value types and type erasure for reference types.
thewhitetulip 10y ago
This is the same experience I had with Go, I come from a Python background, I learned how to write webapps in Go and now am comfortable writing programs in Go. I don't find the lack of generics to be an issue. This is an interesting thing I realized after I read the postmartem report of why "rethinkdb failed". Users want something they can get and build apps with quickly, rather than something feature perfect four years after they want to build apps. Go essentially answered the question, "I want to write a webapp, don't want to use Python or RoR, what do I use?". It is because of the easy to understand syntax and the powerful stdlib they were able to answer that question. The language is amazing. I don't have any idea about Rust, so won't comment on that.
rifung 10y ago
> I've attempted to learn Rust a few times, and it always feel like I'm moving uphill. Isn't this also because it's actually quite a bit different from other languages? I think how difficult something is to learn is largely dependent on how similar it is to something you already know. I can see how from a business standpoint, being able to start coding is great, but I also feel a bit sad when I see people not really giving a language a real chance, especially when a week or two may not be all that significant in the long run, whereas choosing a technology is potentially pretty significant long term.

vvanders 10y ago

The thing with Rust is it doesn't let you get anything wrong. It's both a strength and weakness. There's a million edge cases that you can just ignore in many modern languages. A large part of the reason Javascript has taken off is it's ability to "get out of your way", however you pay for that in the long tail of issues and undefined things. Many projects in software are trying to prove out a concept, and in those cases is makes sense to move fast and find out if the core thing you're doing works. However in problem domains that are well understood or have strict performance/memory requirements Rust really shines. I think there's a strong argument that this is a subset of software(and probably not the majority) however I feel that unless you're taking a project to 100%(remember the last 10% takes 90% of your schedule) ESR's comparison isn't fair.

MichaelGG 10y ago
Whereas in C you can introduce subtle errors that might take forever to trigger, or silently corrupt things. Go still allows data races. Rust eliminates this. So, I guess you can "ignore" stuff in other languages and feel like it's working, with less guarantees it is actually right. Most of the things you need to do in C, Rust just codifies and enforces.
tatterdemalion 10y ago
Quick iteration on concepts is actually helped by not having to do extensive testing & maintenance work to keep your system from 500ing, which a static type system can help you do. The fact that dynamic languages don't care about your bugs is actually a hindrance. What dynamic languages have as an advantage is that they allow you to more readily change your system as your understanding of the requirements change. This is where static type systems have traditionally been very weak - they create roadblocks for evolutionary change. What would be great is a type system which catches your bugs but doesn't block you from evolving. I actually think Rust's use of type class polymorphism ("traits") goes a long way toward that goal, once you learn it.
- woah 10y ago
  Flow does this. Never used Typescript but I assume it's similar. Flow really shines though because the typing is totally optional and has almost no impact on the JS patterns that you want to use.

jondot 10y ago

20 years journeyman here. If I could write my experience I would write what you did word by word about my feelings with Go and Rust. And I've tried many times - you nailed it. As an aside, I keep seeing people don't "get" this, and it is painfully unclear to me - why?. Perhaps the pool of people with 15-20 years that are still doing programming is very small, so they make very tiny noise.

kaoD 10y ago
>15 years programming here, from VB6 to JS including C(++/#), PHP, Java, Scala, many Lisps... I "get" what you mean, I just want to give my perspective: When I tried Go I just didn't get what it had to offer. It felt like the wheel, reinvented. I was like "That's it?". I can see how that's appealing but, for me, Rust is a stepping stone on what we should expect from programming languages of the future. A new language with a new paradigm is going to take longer to feel productive in, especially when the tooling and libraries aren't quite there yet. I can see how that's not good for someone who wants results now. Rust's ecosystem is very much in its infancy. I expect 2017 to be a great year in terms of both language ergonomics (e.g. see Rust Language Server) as well as stabilization/standardization of very important things like how to do concurrent I/O. If your niche is distributed computing (e.g. I/O bound servers), yes, Rust is currently not going to satisfy you. I think comparing Rust and Go is not fair for neither of them and, even if both are advertised as "systems languages" they are actually very different beasts filling their unique niches.
- weberc2 10y ago
  I'm excited for Rust to improve. I keep wanting to use it, but I don't have any projects that need to be faster than I can make them with Go (and frequently with less effort than the naive Rust impl). If Rust's ergonomics improve enough (tooling, std lib, and core language), I might be able to justify it. Fingers crossed!
ekidd 10y ago
> Perhaps the pool of people with 15-20 years that are still doing programming is very small I'm at 20 years of paid, professional coding, and 30+ if you count my Apple IIe/gs days and fooling around with C++ as an undergrad. It took me about a week or two to make friends with the borrow checker, and mostly those were self-inflicted wounds from trying to write aggressive zero-copy code. I think that Rust works very well for certain coding styles, but the learning curve is much higher for other coding styles. If you've been scarred by C++ and you're used to treating variables as mostly immutable, the learning curve is pretty reasonable. But if you work in a style with a lot of mutability and you've never wrested with "const char *" versus "std::string" in C++ (which both exist for a good reason in C++), there's more to learn. So I could legitimately see it go either way. My handy litmus test: Do you utterly despise C++, or do you have a complicated love-hate relationship with it? If you fall in the latter group, you may fall in love with Rust on the first try. If you've never even used C++ enough to have an opinion, then it's possible you might not care about high-performance static languages and the prices they pay to go fast, and so Rust's trade-offs might not even be interesting to you.

twic 10y ago

With the mix of affection and disdain one traditionally feels for a younger brother, i refer to Go as "systems PHP". It may not be a sophisticated language; it may not produce beautiful code; it may, arguably, even have inexcusable flaws. But it is astoundingly easy to learn to the point where someone can be productive with it. This is a terrifically powerful, and very unusual, advantage for a language to have. Master programmers won't be choosing it as their tool of choice. It won't be used to attack the craft's hardest problems. But it allows a huge number of people to write programs they otherwise would not have been able to write, and, conversely, a huge number of programs to be written which otherwise would not have been written. There's something rather "quantity has a quality all its own" about it. As with PHP, this is something of a mixed blessing, but it certainly puts a dent in the world.

wmf 10y ago
Master programmers won't be choosing it as their tool of choice. It won't be used to attack the craft's hardest problems. I see almost the opposite, with many new distributed systems being written in Go.
- ekidd 10y ago
  I use a lot of this distributed systems tooling on a day-to-day basis: Docker, Kubernetes, Vault, Pachyderm, etc., etc. It's all brilliant and innovative software and I'm glad to have it. But every time I need to dig down into the source code, I quickly realize why Docker falls over all the time with weird bugs, and why Vault's high-availability backend for etcd falls over once per week, and why Kubernetes is capable of inspiring such epic love-hate relationships. There's a ton of code in Docker where nil can sneak in, and where the types of certain data structures are harder to determine than they should be. Sometimes nil represents "none", and sometimes the empty string does. There's a bit of multithreaded stuff in Vault's etcd backend (or was) that doesn't understand the corner cases inherent in concurrency. I'm totally convinced that these new distributed tools are awesome and a boon to our industry. I just wish that somebody had a long conversation with a good type checker and thread safety checker at critical moments during the implementation process. This may be a classic case of the "New Jersey approach": https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html Software that's sufficiently innovative and which works will be forgiven odd corner cases and bugs.

tatterdemalion 10y ago

Do you have any specific examples of 'core, language-level things Rust needs to improve'? One of the most important goals of the 2017 roadmap is making the language more accessible, any actionable feedback is welcome.

civility 10y ago
Are you only asking the person you replied to? I have some topics I think indicate shortcomings in the language itself, but when I've brought these to the attention of core Rust developers in other threads of discussion the result hasn't been fruitful.
- kibwen 10y ago
  Which topics, and which threads of discussion?
  - civility 10y ago
    I've had several discussions with you over the last couple years. I create throw away accounts on Hacker News, Stack Exchange, Reddit, Slashdot, Rust Users, and so on because I value my privacy. I don't want to tie my throw away accounts together, so I won't include links. My experiences discussing anything Rust related with you has generally gone like this: I list several things I think are problems. You refute a small nit in only one of them and neglect the rest of the message. Giving the impression that you've successfully refuted everything I've said, you tag on the stick-your-tongue-out smiley :P I've had other discussions with other core Rust developers. As should be expected, the conversations go differently for each.
    - kibwen 10y ago
      Feel free to link them to remind me of the arguments that I'm neglecting. :P
      - civility 10y ago

agumonkey 10y ago

I'm not seasoned at all; but trying Go a day made me, more than productive, creative. I started to combine channels freeform and enjoy new ideas every minute, almost no cruft, almost no dead ends ... that's a rare thing. They did circle the concurrency pretty neatly in a nice usable interface.

zbobet2012 10y ago

> And Go _isn't_ awesome in a lot of ways (vendoring, I'm looking at you It's worth noting here there is a large, active team from the open source community working on fixing vendoring and package management right now. I believe the target is the Go 1.9 timeframe (end of Q2ish this year).

leshow 10y ago

I find that somewhat surprising. Are the dozen languages under your belt essentially variations of the same OO paradigms? I am mostly a javascript programmer, and a beginner at haskell, and I found Rust difficult not not that difficult.

tetha 10y ago

A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world. Go is an easy, fast, and very parallel language. Go is exactly what google needs, in all regards. It makes sense why Go exists, it makes sense why google is creating a way to migrate from python2 to go. Go is easier than hard C and Go is fast. Rust is the safe follow-up of C, but more familiar than Haskell, Caml and such. It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. But once rust runs, it works and there's a very very good chance it won't break. And that's also the reason why we'll probably build firewalls and hardened OS in derivatives of Haskell and Rust, and we'll build Google 2 and Facebook 2 in Go. And in my book, that's a good thing.

tatterdemalion 10y ago
> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. I could not disagree more! Rust is a great joy to program in. I would rather program in Rust than any other language. Rust is challenging for many people to learn. That is very different.
- zbobet2012 10y ago
  Language design is about trade-offs: The borrow checker and ownership model is a huge tradeoff. Even those very experienced in it still fight it from time to time. Go made a different trade, they chose GC. And GC _is_ easier. But it has computational overhead (well today anyway). Consider the cascading implications. Rust has a trait for Copy vs. Move types. This means every type has an implicit, and unknown behavior, on certain assignments: let v2 = v; println!("v is: {}", v); You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. But it is a trade-off. Go as a language must have a GC. It will never be suitable for certain tasks as a result. Go also has less compile time checking. This means faster compiles, quicker dev cycles but less compile time safety. Go chose easier here again. These trade-offs are what make rust seem "difficult" in comparison to go. I don't know if you can ever "fix" them.

zzzcpan 10y ago

> to attract more non-genius developers It's not like that, it's not hard to need geniuses, it's just too different for most people. And different takes time to learn. Which is definitely a design flaw for a language aiming for some adoption. I don't think they can improve it at this point, but they can provide a lot of value where other languages are weak.

qznc 10y ago

Your comment and others on Rust here sound a lot like people learning Haskell. There is a similar frustration with fighting the type system and weird concepts (Monads). I believe lazyness is the biggest problem with Haskell and Rust is eager, so Rust should be more successful than Haskell. The Go comments sound a lot like Java in the early days. Easy language. Quick to get started. Easy to get lots of programmers. If desperate, just train them. Today Java is not so simple anymore, because the Pros wanted more features (eg Generics). I believe Rust will get Generics at some point. Typesafe containers are too useful.

kornish 10y ago
I think you mean "I believe Go will get generics." Rust already has generics: https://doc.rust-lang.org/beta/book/generics.html https://doc.rust-lang.org/beta/book/generics.html. I certainly hope the Go authors can find an implementation of generics with a set of tradeoffs that appeal to them. Typesafe containers certainly are extremely useful.
- civility 10y ago
  I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet: https://news.ycombinator.com/item?id=9622417 I agree, the value in generics/templates is in not cutting and pasting an algorithm or container to handle multiple types safely. A true macro system (and Rust's is pretty good one to model after) also solves this problem, and I wonder if Go would ever consider adding such a thing. It seems like a safer approach.
  - qznc 10y ago
    Did they consider the OCaml approach of "generic modules"? I would combine it with C++-style instantiation. By having it on the module level instead of functions/structs, you should be able to avoid the linker bloat. Are there OCaml users in the Go community? Also, there is the hybrid method between C++ and Java, which C# implements: Instantiation for value types and type erasure for reference types.

thewhitetulip 10y ago

This is the same experience I had with Go, I come from a Python background, I learned how to write webapps in Go and now am comfortable writing programs in Go. I don't find the lack of generics to be an issue. This is an interesting thing I realized after I read the postmartem report of why "rethinkdb failed". Users want something they can get and build apps with quickly, rather than something feature perfect four years after they want to build apps. Go essentially answered the question, "I want to write a webapp, don't want to use Python or RoR, what do I use?". It is because of the easy to understand syntax and the powerful stdlib they were able to answer that question. The language is amazing. I don't have any idea about Rust, so won't comment on that.

rifung 10y ago

> I've attempted to learn Rust a few times, and it always feel like I'm moving uphill. Isn't this also because it's actually quite a bit different from other languages? I think how difficult something is to learn is largely dependent on how similar it is to something you already know. I can see how from a business standpoint, being able to start coding is great, but I also feel a bit sad when I see people not really giving a language a real chance, especially when a week or two may not be all that significant in the long run, whereas choosing a technology is potentially pretty significant long term.