141–150 of 243 posts
I still feel there's space for a middle ground language. One that: * compiles (ie no interpreter/VM required) * is statically typed and has generics * has exceptions or option types * doesn't have a borrow checker * isn't purely functional but has map, filter, pattern matching, etc * has reasonable traction Is there anything like this?
Why do you see that a negative though?
When comparing how Go changes with how C++ changes, one gets renewed appreciation for how good of a job the C++ designers are doing. The more Go evolves, the more clear it gets that it has a very poorly designed foundation. I say that as someone who's coded and reviewed a lot of Go code. Maybe they should not have skipped 40 years of language theory when first creating it. It wasn't obvious in the beginning, but now.…
> It wasn't obvious in the beginning, but now... Was it not obvious at the beginning that this was a bad idea? What was the state of programming languages where consciously tossing out progress was considered not on, its face, insane?
But yes, if the goal was to grow then it's a bad place to start from.
I still feel there's space for a middle ground language. One that: * compiles (ie no interpreter/VM required) * is statically typed and has generics * has exceptions or option types * doesn't have a borrow checker * isn't purely functional but has map, filter, pattern matching, etc * has reasonable traction Is there anything like this?
Earlier quoted context omitted.
> It's literally not a problem at all. It's just one bit of information to remember in your head Your assertions do not make that a reality. > But with Go formatting it's even simpler - you literally never think about it. True, because you quickly learn to use something else.
> Your assertions do not make that a reality What reality? I write Go almost daily for 9 years and was running Golang meetups in two countries for years. I think I have pretty good grasp of what actual problem real people have with dates in Go. Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem. This problem exists only in HN comments of people used to other approaches.
When comparing how Go changes with how C++ changes, one gets renewed appreciation for how good of a job the C++ designers are doing. The more Go evolves, the more clear it gets that it has a very poorly designed foundation. I say that as someone who's coded and reviewed a lot of Go code. Maybe they should not have skipped 40 years of language theory when first creating it. It wasn't obvious in the beginning, but now.…
> When comparing how Go changes with how C++ changes, one gets renewed appreciation for how good of a job the C++ designers are doing. We must live in a different world...
At worst you have to write small adapters because there's no equivalent of smatch for string_view, etc...
But compare this to Go, where contexts, error wrapping, generics, uh... error wrapping again (this multierror thing), horrible conditional build hacks, etc...
C++ is a big and complex language. But it's consistent. Go is a small simple language with lots of ill-fitting extensions added as core language features and standard library bolted all around it.
In other words: any language can be critiqued, and it often helps by showing that a deficiency is not unavoidable, by showing how another language has avoided it.
Earlier quoted context omitted.
> What do you dislike about them [implicit interfaces]? Implicitly implemented interfaces can lead to problems where you're "implementing" an interface because your methods happen to be named the same, but the functionality doesn't adhere to the contract the interface is supposed to represent. Not every contract can be described by the type system, especially not by a type system as limited as Go's. Method names like…
You call it an "enormous weakening of contract safety", I call it an issue I've never once had happen in practice. Sometimes you can't spell out that your type implements a certain interface, because it's not a type controlled by you. Moreover, this completely kills the use-case of "define your own small interface with the subset that you actually require, instead of accepting the whole thing", which is a big part of…
Dynamically inferred interfaces only help there if function names and arguments happen to exactly match those of the interface. So if, for example, a method is called ‘Run’ rather than ‘Execute’, or you have ‘Run(string, int)’ and ‘Run(int, string)’ methods, that won’t work.
Some languages that require explicit interfaces (and, I think, most modern ones) allow you to specify that mapping at run time, and also allow you to retroactively make all code (including third party code) that implements FatInterface implement your SmallInterface that’s a subset of it.
Golang chooses to not require programmers to do such work and, I think, hopes programmers will keep names and argument type order identical for common methods, so that those problems occur less often. I don’t think that will work in large code bases, but then, I don’t have experience with large golang code bases.
Earlier quoted context omitted.
I’m glad it’s not just me who is perplexed at some of the decisions made with golang. This was a golden opportunity to implement some typical form of exception handling. Instead you have to bundle your errors together and then unwrap them (often using multiple methods to handle the cases of both a single error and a bundle of errors) and then still implement even more logic to walk the tree you made?
Exception handling sucks, stop asking for it. Did you worked in Java? Did you worked with async and exceptions?
If I want to read a json file, I have to have a named variable for the file, one for the byte string, and finally one for the parsed object (the only thing I care about).
Then for each statement I have to check if an error happened and return it if it did.
Whereas in something like Haskell I could use a Maybe and compose the functions to only forward the value at each step if it was present. Then at the end I would have a Maybe with the final value, which I could then return to the caller.
Golang makes the most common thing to do as verbose as the least common thing.
I still feel there's space for a middle ground language. One that: * compiles (ie no interpreter/VM required) * is statically typed and has generics * has exceptions or option types * doesn't have a borrow checker * isn't purely functional but has map, filter, pattern matching, etc * has reasonable traction Is there anything like this?
> a borrow checker Why do you see that a negative though?
Overall it provides guarantees I don't need for what I want to write so doesn't justify the additional cognitive overhead.
Earlier quoted context omitted.
You don't need an IDE to do that. More or les anything that can hook up with the Go language server will do the job.
So somehow needing a language server to work around language design flaws is alright for Go then.