5 ms·

You are so right -- thats why in better languages like C# and Java you need an IDE to write half your code for you, and a multi-million line optimizing runtime

by jimmy1 8y ago

You are so right -- thats why in better languages like C# and Java you need an IDE to write half your code for you, and a multi-million line optimizing runtime to make it run fast.

crimsonalucard 8y ago
I find you sarcasm insulting. Every language has flaws and I never said C# or Java were better. I'm saying that the fact this exists points to something needed in the language. Besides the fact that generics is a up and coming feature in go 2 basically proves my point.
- weberc2 8y ago
  The project has several objectives--to bring a REPL for Go, to provide a macro system for Go, to facilitate experimentation with generics, etc. None of these are meaningfully served by "having generics".
  - crimsonalucard 8y ago
    Experimentation serves a purpose and that purpose is to see whether they can fill a gap missing in go.
    - weberc2 8y ago
      Yep, that's the point :)
meddlepal 8y ago
Comparing apples and oranges. Java and C# are verbose because of libraries and frameworks in the ecosystem not because the languages are inherently flawed. Not sure what your point about the runtimes is? We shouldn't use or build highly optimized runtimes? Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?
- bogomipz 8y ago
  >"Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?" Could you elaborate on what the shortcomings of the original runtime were? Might you have any link regarding this? Thanks.
  - weberc2 8y ago
    I think he's remarking about how the first version of anything is almost always suboptimal compared to later versions. I.e., it "sucked" compared to later versions, almost by definition.
  - jerf 8y ago
    The original runtime had far, far worse GC pauses. They concentrated on making sure they could make a good one later rather than getting a perfect one out the door immediately. There was also a series of crashing bugs of varying severity in the first couple of versions. Even then you had to go a bit out of your way to find one, but they're a lot harder to come by now. Nothing that surprising, really. If you look at Go's release note history: https://golang.org/doc/devel/release.html https://golang.org/doc/devel/release.html look towards the first few releases for the bugs they mention. For instance, here's a 1.1 fix: https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b57d741ed00f0b0cd https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b... One of the advantages of not mutating the language too much is that there aren't very many things like this in the last few releases. I would expect the first 2.0 release to have a few rough edges even in the first non-beta release.
- weberc2 8y ago
  You're conflating "optimized" with "optimizing". The observation is that Java and C# depend on a _very_ sophisticated runtime (including a JIT compiler) to perform comparably to Go which has a comparably simple runtime. I don't know that the point is a strong one; I'm just trying to clarify the conversation.
  - pjmlp 8y ago

by jimmy1 8y ago

You are so right -- thats why in better languages like C# and Java you need an IDE to write half your code for you, and a multi-million line optimizing runtime to make it run fast.

crimsonalucard 8y ago

I find you sarcasm insulting. Every language has flaws and I never said C# or Java were better. I'm saying that the fact this exists points to something needed in the language. Besides the fact that generics is a up and coming feature in go 2 basically proves my point.

weberc2 8y ago
The project has several objectives--to bring a REPL for Go, to provide a macro system for Go, to facilitate experimentation with generics, etc. None of these are meaningfully served by "having generics".
- crimsonalucard 8y ago
  Experimentation serves a purpose and that purpose is to see whether they can fill a gap missing in go.
  - weberc2 8y ago
    Yep, that's the point :)

meddlepal 8y ago

Comparing apples and oranges. Java and C# are verbose because of libraries and frameworks in the ecosystem not because the languages are inherently flawed. Not sure what your point about the runtimes is? We shouldn't use or build highly optimized runtimes? Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?

bogomipz 8y ago
>"Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?" Could you elaborate on what the shortcomings of the original runtime were? Might you have any link regarding this? Thanks.
- weberc2 8y ago
  I think he's remarking about how the first version of anything is almost always suboptimal compared to later versions. I.e., it "sucked" compared to later versions, almost by definition.
- jerf 8y ago
  The original runtime had far, far worse GC pauses. They concentrated on making sure they could make a good one later rather than getting a perfect one out the door immediately. There was also a series of crashing bugs of varying severity in the first couple of versions. Even then you had to go a bit out of your way to find one, but they're a lot harder to come by now. Nothing that surprising, really. If you look at Go's release note history: https://golang.org/doc/devel/release.html https://golang.org/doc/devel/release.html look towards the first few releases for the bugs they mention. For instance, here's a 1.1 fix: https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b57d741ed00f0b0cd https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b... One of the advantages of not mutating the language too much is that there aren't very many things like this in the last few releases. I would expect the first 2.0 release to have a few rough edges even in the first non-beta release.
weberc2 8y ago
You're conflating "optimized" with "optimizing". The observation is that Java and C# depend on a _very_ sophisticated runtime (including a JIT compiler) to perform comparably to Go which has a comparably simple runtime. I don't know that the point is a strong one; I'm just trying to clarify the conversation.
- pjmlp 8y ago