Google releases new programing language.

It's a matter of choice. I use a dozen different C compilers with almost as many target processors, plus several other programming languages. The last thing I need with a new compiler or new language is a new IDE to go with it.

There are three ways to work when programming:

1) You can use an IDE that came with your compiler + tools 2) You can use a generic IDE with whatever compiler and tools you want 3) You can use a simpler editor with command line tools

Using a compiler/toolchain specific IDE is fine if you do most of your work using it, or if it has a great deal of added value (such as a graphics design system for guis, or RAD tools, or whatever). It's also great if you want a simple "all-in-one" system and don't want to think about your tools. But typically, these IDEs are limited and inflexible, and every one is different - making your job a lot harder if you work with more than one toolchain or language.

Generic IDEs like Eclipse are a better choice for many uses. You get a powerful editor, project management, source code versioning control, build management, debugging, etc. Language-specific syntax highlighting, refactoring, etc., is done by plugins or syntax highlighting files. If your development process fits standard models neatly, you can use built-in build management, otherwise the IDE will call external "make" tools.

Some people (including me) prefer a simpler editor and use command-line tools such as explicitly running "make" commands. I find that gives me the fastest and most flexible development process, and gives me a fairly consistent environment for my different toolchains.

No sane toolchain vendor would make a new IDE unless they have very specific requirements, or overwhelmingly many special features. In commercial toolchain development, the trend is towards Eclipse for new IDEs - many vendors are even dropping their existing IDEs and moving to Eclipse in newer versions. You can expect that sooner or later an Eclipse plugin for "go" will turn up, as well as an emacs mode and, if the language becomes popular, plugins and syntax highlighter files for other common IDEs and editors.

A few of these features are programming language specific, but most are very general - and are providing by generic IDEs.

I am not saying you should not use, or want to use, an IDE for "go". I'm just saying that you should not expect a compiler toolchain vendor to provide a specific IDE - it is far from necessary for using the language, and would be a big waste of effort.

The deifference between a Public function and a private function is determined by the first character of the name. But when using UTF-8 how does it tell the difference for say Japanese names?

Antoon

IDE can mean two things. Integrated Development environment, and Integrated Debug Environment - many use the former to mean 'an editor'.

A syntax highlighting editor, is a very small amount of work, and the language should be able to be added to most good editors, quite easily.

However, good DEBUG is very different, and if someone wants a NEW language to take off, it had BETTER be easy to get up to speed on. Simple really.

Good debug is rather hard to simply bolt-on-later.

Look around at some of the smarter systems out there :

Microsoft have free tools, with very good (seamless)integration of key parts

• Syntax editor

• Data inspector, including find declaration

• Variable watch

• Breakpoints

Same with Lazarus - A wide choice of languages, all with usable systems. (not stone soup)

Data inspection and variable watch, are rather tightly linked to the language definition, and the compiler and object files itself.

So, that task really needs to be done by whoever wants the language to be widely used - if you want it done quickly, and right.

Sure, start with something that already works on another language, but there are enough new features in Go, that a lot of detail work is needed.

Of course, if their only target is the depths of research labs, and those happy with the command line....

-jg

What do you mean by and IDE, aka what functions does it need to have? Several editors do bracket matching, keyword highlighting, etc. Is that enough?>

< Counted today and 10 spam in inbox and 26,768 told where to go.>

Anyway,

Nope, not sure which one you are talking about, but I did purchase Borland's turbo pascal and turbo C as my last two IDEs. Not counting the visual C and viscual c++ that some one gave me to assist their efforts.

If you download the Go source code you can already find syntax highlighting scripts for vim, emacs and xcode in the /misc directory.

If you look at Go, you should look at Go! as well:

Protel Autotrax was written in Turbo Pascal or C or a combination of both IIRC.

Agreed. I responded to your post only because I thought your sentence below implied that the poster asked the "wrong" question and I happen to prefer the posters choice to yours.

That's my take on it too. What really impressed me was the great concurrency stuff.

--
    W
  . | ,. w ,   "Some people are alive only because
   \\|/  \\|/     it is illegal to kill them."    Perna condita delenda est
---^----^---------------------------------------------------------------

It supports ARM as well as x86.

--
    W
  . | ,. w ,   "Some people are alive only because
   \\|/  \\|/     it is illegal to kill them."    Perna condita delenda est
---^----^---------------------------------------------------------------

:)

Oh Dear, OOps....!

Guess they did not use the Google search engine, did they!! Red faces all round.

So, Sounds like 'Goo', or 'Goog', or 'ogle' might have to be 'new name' candidates - or they could simply throw some money at the problem...., but that would not go down as well with their target.

-jg

I noticed that as a minor point deeper inside the documentation - the front pages don't mention it.

Obviously Google have worked on compilers targeting the cpus they are interested in. But if it is going to be of interest to comp.arch.embedded, it there must be compilers targeting the cpus /we/ are interested in. x86 and amd64 barely register here, and pure ARM is not much better. If and when there are ports for ARM Thumb, Cortex, PPC, Coldfire, MIPs, AVR, 8051, msp430, etc., etc., then c.a.e. can get excited.

You'd have to ask someone who wants to program with Japanese function names.

I don't really see much benefit from being able to use non-ASCII characters in function or variable names. But then, I program in English (and even if I occasionally use Norwegian words in names, it's easy to transliterate for programming purposes). Where I do see utf-8 as potentially useful is in strings, and possibly in comments and inline source code documentation.

I'm not a fan of having something as small as the capitalization of a name affecting something as important as the visibility of a function.

You are being overly polite - I didn't /imply/ that he asked the wrong questions, I /said/ he asked the wrong questions! But on reading my own post, it was unreasonable of me to word it that strongly - rather, I should have said he could have asked /better/ questions, that are more likely to have positive answers and that discuss tools that are more useful to the language's target audience.

There's a gcc frontend for Go, so doesn't that cover Cortex, ARM Thumb, PPC, Coldfire, MIPS, AVR, SPARC, IBM z-series, H8, SH, MSP430, and so on?

--
Grant

Depends what you mean by 'cover'. If that means can create 'hello world', yes, but the serious weakness of a hop that includes gcc, is the debug info no longer reaches back to the users source code. Any polished debug environment needs source level Step, and full variable watch, in the native structures.

-jg

You're talking about editor features. An IDE provides (or should provide) project management, toolchain calling and debug support as well.

--
Gemaakt met Opera\'s revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)

The gcc front end is certainly a good start. gcc has numerous front-ends (C, C++, Fortran, Ada, Objective C, and various other out-of-tree languages), a middle-end, and a range of back-ends (something like 30+ in-treee). However, gcc is not nearly as modular as it appears - there are interconnections between front-end parts and back-end parts that mess things up. In particular, you can't just take the "go" front-end and configure and compile for the AVR back-end - it's quite possible that the "go" front-end makes demands of the back-end, such as insisting on it being 32-bit. As another example, avr-gcc is missing some features in its C++ support (though some would say that having only limited RTTI and exceptions support is a good thing...), partly because of missing front-end, back-end interaction.

Even when minimal requirements are met, there is then the quality of the code. Again as an easy example, the avr backend can generate quite reasonable 32-bit code - but if the front-end language insists on using

32-bit all the time, the final generated avr code will be terrible even if it is technically correct.

Then there are the libraries - although I believe that much of the "go" libraries is written in C, there are still porting issues.

So a gcc front-end for "go" is a big step towards portability, but there are still more steps ahead.

I think this is a bit mixed up. Having a gcc front-end means that you /can/ get debug information all the way through. I believe you are thinking of a a C pre-processor (like "cfront") that generates C code and is then compiled. If that were the case, using C as an intermediary language, then most debug information is typically lost.

Of course, having a gcc front-end does not guarantee that you do get good debug information - it depends on the quality of the debug information generated by the gcc "go" front-end, on how well that fits with gdb (or other elf debuggers), and how well the actual debugger software works.