Ah, funny you mention this!
It's still as broken as a "default build environment", since there is no version management there.
The whole vendor experiment seems a shy attempt at covering up the GOPATH "feature"
Then the default Go build environment is insufficient even for a toy project; does that describe better the issue at hand? Nonetheless it predates the success of the language.
I've used repo a bit, nice tool; but still: don't release a half-assed build environment because in your company you use a different tool. Sometimes it's better to not release a feature at all, instead of one that is incomplete/insufficient.
Totally agree with you. It doesn't change a thing the fact one of the core developers said that: keeping clean 'master' is not a solution to everything. What if I want to use version 2? Or version 2.1? Utter anachronistic nonsense...
I've seen people not updating 'master' of their git repository because of this...utterly ridiculous.
It makes new releases difficult to adopt and becomes soon detrimental to change in general.
The package managers which have been developed (Godep, gb, glide) are not of the quality you would expect to professionally use Go...I've found issues with all of them (I know they're in high flux, but still).
AC was referring to the fact you need to run all OpenGL code from same thread. Go's goroutines are not guaranteed to run on same thread (unless you do some black magic sorcerery).
Not sure there is anything to fix there...
Have you given a look recently to https://github.com/go-gl ?
The main issue here is that you need a specific goroutine to "sit" on a specific thread and process your OpenGL flow; it's already covered with some hacks, AFAIK.
Why was package versioning left out?
And are you guys still fond of this decision?
As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution.
Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived.
And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...
Into darkness sink all images;
God paints on the cavas of life once more.
Standing armored to fight with crest and shield,
Meanwhile the enemy blackens the field.
And the heards are dying of thirst below the blazing suns,
The ice cliff walls now flow into a little brook hissing
Into the earth, and you are fishing
Where there are no fish.
Then into the fiery abyss you dive
Where, trembling, you find that the dead are alive.
In a hell where they horribly change and swirl
As around Gorgo's head they unfurl.
Tortured, the broken eye
Stares down into hell's bubbling lye.
Your body, plowed through with the furrow of the worm,
Torn is the shell of your tower, once firm,
Struck down by a bolt of fire
As you drown in the hellish mire.
You to the surf, God calls
To the surf that breaks on His kingdom's massive walls
Where blocks that shine as the sun so fair
Shelter his original human pair.
Redeeming from His blood a new form and shape
An image that only God can create.
Into darkness sink all images,
God paints on the canvas of life.
Sensationalistic headline.
If you do this/seriously/, then show off a big sample of AI-generated games and let game developers and game players review them
Slashdot Mirror
You know slashdot is finished when this comment gets rated 'troll'. I feel you, ogdenk. Could not have said it better..
Ah, funny you mention this! It's still as broken as a "default build environment", since there is no version management there. The whole vendor experiment seems a shy attempt at covering up the GOPATH "feature"
By your ecstatic example I can see you never managed more than 1 or two package dependencies in your Go programming experience
Then the default Go build environment is insufficient even for a toy project; does that describe better the issue at hand? Nonetheless it predates the success of the language. I've used repo a bit, nice tool; but still: don't release a half-assed build environment because in your company you use a different tool. Sometimes it's better to not release a feature at all, instead of one that is incomplete/insufficient.
Totally agree with you. It doesn't change a thing the fact one of the core developers said that: keeping clean 'master' is not a solution to everything. What if I want to use version 2? Or version 2.1? Utter anachronistic nonsense...
Most people search for it as 'golang', but yeah - I get what you mean. Good question.
I've seen people not updating 'master' of their git repository because of this...utterly ridiculous. It makes new releases difficult to adopt and becomes soon detrimental to change in general. The package managers which have been developed (Godep, gb, glide) are not of the quality you would expect to professionally use Go...I've found issues with all of them (I know they're in high flux, but still).
AC was referring to the fact you need to run all OpenGL code from same thread. Go's goroutines are not guaranteed to run on same thread (unless you do some black magic sorcerery).
Ah! Thought the same :)
Not sure there is anything to fix there... Have you given a look recently to https://github.com/go-gl ? The main issue here is that you need a specific goroutine to "sit" on a specific thread and process your OpenGL flow; it's already covered with some hacks, AFAIK.
Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...
I think both of them. The quality here is on a deep nosedive..
I will reference this comment 5 years from now, with sales figure of "GoogleCam", just to make a point.
Into darkness sink all images;
God paints on the cavas of life once more.
Standing armored to fight with crest and shield,
Meanwhile the enemy blackens the field.
And the heards are dying of thirst below the blazing suns,
The ice cliff walls now flow into a little brook hissing
Into the earth, and you are fishing
Where there are no fish.
Then into the fiery abyss you dive
Where, trembling, you find that the dead are alive.
In a hell where they horribly change and swirl
As around Gorgo's head they unfurl.
Tortured, the broken eye
Stares down into hell's bubbling lye.
Your body, plowed through with the furrow of the worm,
Torn is the shell of your tower, once firm,
Struck down by a bolt of fire
As you drown in the hellish mire.
You to the surf, God calls
To the surf that breaks on His kingdom's massive walls
Where blocks that shine as the sun so fair
Shelter his original human pair.
Redeeming from His blood a new form and shape
An image that only God can create.
Into darkness sink all images,
God paints on the canvas of life.
Ernst Fuchs, Venice 1984
Exactly, and for those willing to read more: start from his former teacher Hermann Minkowski and his Minkowski space.
Dark matter..remembers me of ether.
Sensationalistic headline. If you do this /seriously/, then show off a big sample of AI-generated games and let game developers and game players review them
I kinda' missed these flame wars..