Proposal: Algol should have dependent types.
Proposal: Go should have generics
291–300 of 439 posts
Re: Proposal: Go should have generics
#292Earlier quoted context omitted.
No, it's the opposite. It would appeal to people who built large Go codebases and eventually realised that they were tied to a toolchain that was years behind the state of the art. A Go for the JVM would immediately give Go developers much better optimising compilers, high quality cross platform IDE-integrated debugging and profiling, much stronger garbage collectors, ability to access the large quantity of Java libr…
Go GC since 1.6 openly claims In my experience Java brings a mindset that there must be some complex way to solving a problem so lets find out that.
sievebrain - Did you read the full issue? This is an edge case - a program running on a 40 core machine that the developers were trying to keep to a 5MB heap. And yes, the answer was "use more RAM", but by "more" they mean "40MB". Not like gigabytes or anything.
There's always going to be edge cases in any GC/compiler/etc ... you just can't account for every case. I suppose with java's infinite knobs, you might be able to... but then you have to tune the GC. In Go, there's just one knob (a slider, really, more CPU vs. more RAM), and 98% of the time you'll never need to touch it. I had honestly forgotten it exists, and I work on a large Go project daily at work.
Re: Proposal: Go should have generics
#293Earlier quoted context omitted.
Well he answered me as if he understood me, so I am going to go ahead with that assumption. This thread is not at all difficult to follow. Anyone who uses rescue should be shot on sight--it takes a masochist to introduce panic as a stack unwind mechanism intended to be caught. The process should stop. I have never seen rescue used in the wild, so it seems as if the only thing this has in common with exceptions is sta…
A big problem with both Rust and Go is that the marketing says there are no exceptions, and because we all know exceptions are bad/slow/hard to understand that the languages are superior. I strongly object to this idea because from an implementation POV both Go and Rust are 90% there for all the complexities that exceptions cause but now nobody is aware of it. (This is also why I'm a huge proponent of Results in Rust…
Well, as I said earlier, stack unwinding does not imply that the stack unwinding is NORMAL; I'm fine with it in exceptional cases.
Defer has its own quirks that irritate me but I wouldn't call them exceptional so much as dynamic RAII.... or something.
Either way, if the languages allow me to avoid tracking down every possible http connection exception I need to trap to avoid bringing down my process I'd say it's a net win.
Re: Proposal: Go should have generics
#294Earlier quoted context omitted.
> you are not "sorting" new kind of "types" every day You'd be surprised.
I am writing a chemoinformatics database, so for my practical use, these are a lot of lines of codes with pretty involved algorithms and I am practically not annoyed by the lack of generics. For the ones down-voting me, have you coded something in Go, big enough to be a real in production project, where at the end the lack of generics is a real issue (performance because using interfaces or maintenance because copy/p…
I wrote some big things in Go and didn't find the lack of generics particularly problematic. Different languages are good for different things-- Go is good for building things that are relatively concrete. For something like a symbolic math package or a scripting language you might want a different language that makes different tradeoffs.
Re: Proposal: Go should have generics
#295Earlier quoted context omitted.
but having all those things go would become another C++ with a different syntax. I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations. However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries. Exceptions would be probably se…
> but having all those things go would become another C++ with a different syntax. Haskell and CL have "all those things" and they are not "C++ with a different syntax". I don't know why people repeat these cliches... It's not like a language can't have many features and be designed well at the same time. It just takes preparation and effort instead of ad-hoc additions (like with C++).
I'd argue either are just as bad as C++ if you actually use all those features, just like NOT using all those features turns your C++ readable.
I'd also argue that Haskell does NOT support all the features directly but implements them through the language, which is a Good Thing.
I consider CL a mess, so I probably shouldn't comment on it.
Re: Proposal: Go should have generics
#296Earlier quoted context omitted.
You forgot that most of golangers are ex-php programmers and students with no experience. Just look at what they're talking about: they think generics are the opposite of simplicity and can make performance and compilation time worse. Meanwhile, Nim has generics with other useful features and has faster compilation time along with better optimization. If google would put 'goto' into go golangers would still use it an…
> You forgot that most of golangers are ex-php programmers and students with no experience. How hopelessly smug and incorrect.
Just look at the "conversion" blogs, most of the writers are php and python devs. And if you look closer you'll see that most of these bloggers are around 20 and they don't tolerate such complex things like generics...
Re: Proposal: Go should have generics
#297Sitting in a lecture by Kernighan rn and he says GO will NOT be implementing generics
Re: Proposal: Go should have generics
#298If you google "brutally practical" you will get "uninspired hack". Either that or the whole thing is simply pre-alpha
Re: Proposal: Go should have generics
#299Earlier quoted context omitted.
The lesson Go seems to have learned is that, since C++ and Java burned their fingers, clearly fire is too dangerous for humans. The thing that makes it painfully obvious to me that Rob Pike hasn't bothered to learn anything from the PL community is that Go has nil. That just shouldn't happen in a modern language.
> The lesson Go seems to have learned is that, since C++ and Java burned their fingers, clearly fire is too dangerous for humans. I think that's a little bit unfair, since Go introduces many powerful ideas not (traditionally) available in Java or C++: namely first class concurrency and functional primitives. Its handling of typing, the ability to define types not necessarily based on structs, the excellent design of…
https://golang.org/doc/faq#nil_error is not an excellent design. It's a serious bug that converting nil to an interface sets the type field to a meaningless value (nil doesn't have a type!) and ridiculous that the interface doesn't compare equal to nil (if it's not nil, what does it point to?)
Re: Proposal: Go should have generics
#300Could anyone here tell me why, in practice, it isn't possible to write generic algorithms such as sorting or Red/Black T using interfaces only in GO ? It seems like having interfaces such as "comparable, equatable,etc" should work in theory.
I've read somewhere that it was memory usage related, but i've got trouble picturing why (maybe an example would help)