Google releases new programing language.

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?>

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:

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.

It supports ARM as well as x86.

:)

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.

This isn't without precedent. E.g. Prolog uses upper-case for variables and lower-case for atoms, Haskell uses upper-case for constructors, lower-case for variables (and symbols for infix operators).

Other languages may lack rules but have conventions, e.g. Java conventionally uses upper-case for class names, lower-case for everything else (variables, parameters, members, methods, packages), and this convention seems to be uniformly followed.

One advantage of using case is that it can make a language context-free rather than context-sensitive, as you can distinguish between different kinds of identifier without having to keep track of which identifiers are in scope and with which kind.

In these cases, it's slightly different in that you are talking about different parts of the language. A particularly bad thing about forcing a convention like this to determine public or private access is that it is something you will often want to change during the development of a program. It is far from uncommon that you want a particular variable to be private to a module, class, block or whatever, yet sometimes you want to "cheat" and peak at it during testing and debugging. With C, that means removing the "static" in the declaration, and adding an "extern" declaration in your temporary test/debug code. With a language like Pascal, it means adding it temporarily to your "interface" section. With Go, it means doing a search and replace to change the small letter into a capital letter - a far more intrusive and inconvenient operation.

Conventions are fine, and have can be very beneficial. But they are just conventions - if they are not appropriate for the code you are writing, you don't have to follow them. But even such capitalization conventions are enforced as rules, I still do not think it is an appropriate way to determine such an important aspect of the code. A clear and unambiguous keyword such as "public" is much better, IMHO (and this is all about personal opinion). It is much clearer to read, and easier to spot by eye or to search for with an editor.

That is certainly a benefit. But no language is context free - you are only making it slightly less context sensitive, and I can't see that it is worth the cost.

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?

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.

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

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.

Don't forget command line argument obfuscation. That seems to be very important. That, and include paths. Impenetrable.

Cheers,