Hacker News new | past | comments | ask | show | jobs | submit login

Not the poster you're responding to, but practically every time someone wants to write code that mimics `map` or `filter` and gang is a 5-7 line function (at least). Something that would have been a 1 liner in languages like Java or C#. It gets tiring and distracting very quickly to jump around verbose implementations which amount to nothing more than standard streaming functions.

Another example is the lack of annotations for validations. In Java or C#, you'd annotate the function argument with something like `@Validated`, and it's taken care of. In golang, calling the validation code would have to be done manually each time that's another 3-4 lines (including error handling).

Yet another example is that golang lacks a construct similar to C#'s `Task`. You can't execute a function that returns a value asynchronously (if you care about that value) without creating a channel and passing it.

golang also lacks pattern matching and discriminated unions (aka algebraic data types). Java and C# are getting both (both have pattern matching, and ADTs are in the works as far as I'm aware).




Have to agree with you. I wished for sum types & pattern matching more than for generics.. but who knows what the future brings.


this is why I have moved to Rust. I worked in Go a number of years ago, but after becoming proficient in Scala, I've decided sum types and pattern matching are where the sweet spot is. The JVM has its own issues though and I'd like to have a performance-conscious language in my toolbelt that doesn't sacrifice expressivity. Hence: Rust.


RemindMe! 10 Years "Are we there yet?"


You got me excited about Java having pattern matching, but all I could find was a proposal.



Thats just for instanceof they're working on growing the capabilities in another JEP. Switch expressions are EXTREMELY powerful though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: