Introducing Gofix(blog.golang.org)

62 pointsby fogusvor 15 Jahren11 comments

blog.golang.org

http://blog.golang.org/2011/04/introducing-gofix.html

12 comments

vessenesvor 15 Jahren

The best part about this, and what's different than 2to3, is that they implement API changes in gofix first, and gofix is the tool that's used to change the main source tree.

I like that. That is really nice, and it sets a process in place which continues to keep cost of language API changes low, something that the language designers will love.

At this point in Internet history, a language that's newly created and evolving has a sort of tipping point problem -- if nobody uses it, it won't improve. On the other hand, if a few too many people start using it, then suddenly you are screwing people if you make changes.

gofix seems like it can help with that, and that's cool!

snprbob86vor 15 Jahren

Cool! Doesn't one of the Java IDEs (either IDEA or Eclipse?) have "public refactorings" (or something like that)? The idea goes something like this:

1) Enable recording of public refactorings

2) Apply a refactor which affects the public API

3) Refactorings are described in some big honking XML file

4) When you release a new version of your library, post it alongside that XML file

5) User downloads and executes the file against their codebase

lephtvor 15 Jahren

I can't help but feel that go is destined to become the NBL, at least in the world of enterprise development where static typing and OOP have become assumed if not necessary.

Aside from having the backing of Google, it provides C-like low-level access for systems programming, a clean syntax, static typic, a consistently evolving set of business-focused APIs, along with some of the conveniences normally associated with dynamic languages.

Obviously no language or set of libraries is designed with perfect foresight. But the painful aspects of popular languages like Java or C++ could probably be improved upon or even solved tomorrow given zero regard for backwards compatibility with legacy code. Go's relatively short legacy, combined with smart considerations for existing codebases (like gofix) mean that fundamental changes to the language or standard libs can be made in order to perfect the language. All while the language's limitations are being revealed in real world usage by the (presumably) demanding needs of users like Google and Go's early adopters.

I don't mean to sound like a fanboy, especially as someone who has mostly drank the dynamic typing Kool-Aid, but I can't wait to see what happens with go.

jffvor 15 Jahren

I've used gofix several times, it's quite useful. Now, if I didn't use the weekly snapshots instead of the release ones, I wouldn't have to use it as much, but that's the price of life on the bleeding edge :)

dchestvor 15 Jahren

I second this -- yesterday I gofixed some third-party packages without even reading their code and without waiting for the authors to update them.

ginkgovor 15 Jahren

If the python project had something like that, the current python 3 situation could maybe have been avoided.

vessenesvor 15 Jahren

The python 3 situation is really the python 2.4/2.5/2.6/2.7/3 situation. I'm not sure why or how it happened, but python is brutally fragmented in the real world across OS'es, in my experience.

almostvor 15 Jahren

Python has 2to3 which is the same kind of thing

Queue29vor 15 Jahren

There are a lot of things 2to3 can't fix, so the user has to go back and change things by hand anyway.

almostvor 15 Jahren

That appears to be true for gofix too and probably any tool of that kind...

rogpeppevor 15 Jahren

it's less of a problem for gofix because Go's static typing means it's easy to be much more precise about which methods and functions are actually being used.

[deleted]vor 15 Jahren