Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google).

.NET isn't a language and Java and Go are both open (but with the main contributers being employees from the aforementioned corporations).

> All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

Layers of abstraction are there for convenience otherwise we'd also shortcut C++, C and even assembly and would be writing everything in machine code.

> Google already control your search, your browser, your phone, your email and in some cases your OS (Chrome) why would you want them to control you programming language as well? The idea boggles my mind.

I actually do get the Google paranoia. It's why I cut down on my dependence on them as well. But Go doesn't up-sell Google's services like Chome (which isn't an OS by the way - you must be thinking of ChromeOS), Android, Gmail and so on. And let's be honest, other popular languages have born out from businesses: C from AT&T, Borland lead the charge with Pascal, Microsoft had their version of BASIC bundled with many of the most popular micro PC's of the 80's. Need I go on?

> There is a reason go compilers are C and C++.

Yes, but it's not the reason you're thinking of. The problem was one of the chicken and the egg. It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language. C had the same problem when it was young too.

> I wish others felt as strongly about this as I do. If you want to control your future, then use C or C++ or some other ISO standardized language with lot's of free compilers available, do not use a corporate controlled programming language.

The reason people don't agree with you is because: a) C++ would be overkill for a web framework (which is one popular application) and b) half your points are based on misinformation.



> It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language.

Is Go not at this point yet? I only have casual knowledge of the language, but it sure sounds like it is capable of building itself.


I would have thought so (but I'm far from an expert on such matters). However you'd still have the issue of users wanting to download Go's build tools from source (as not everyone likes to install pre-compiled binaries on their systems) and not being able to compile the compiler.

Granted gcc could now be used. But then you're back to using a compiler built in C++ to build Go code.


Considering people are writing web servers and all sorts of other things in it, I'm sure it's suitable for writing a compiler. Technically all you really need is logic, some data structures, and low level file I/O. If you're going to spit out asm and let someone else deal with that, then all you need is normal file I/O.

It seems like Go is trying to capitalize on the momentum they have. Improvements to the language are still coming quickly. I'd be surprised if a self-hosting compiler isn't among their goals, but writing a new compiler without slowing down language progress in the current reference compiler is not easy.


Actually a language compiler is more complicated than a web server when speaking about the data-structures and the algorithms used and represents the best test that you can have for a programming language.

Also, you would want a compiler written in a high-level language (versus C) precisely because you want to speed up the development of new features.


Yes, it's more complicated, but it doesn't really have much in the way of demands on the language used for implementation. It may royally suck to do, but you can write a compiler with nothing more than logic, data structures, and file I/O. That was my point.

> Also, you would want a compiler written in a high-level language (versus C) precisely because you want to speed up the development of new features.

Sure, but you'll need to pull people away to do that and will either have to stop your C-based compiler effort or resign yourself to prolonging the Go-based compiler development by playing catchup. In the meantime you aren't really as productive as you could have been. Go seems like it's about to slow down on language-level changes, which is the perfect time to start working on a Go-based compiler.


Actually a language compiler is more complicated than a web server when speaking about the data-structures and the algorithms used

That would depend on how much of the web environment you want to reproduce and what language we're talking about. The original Oberon fit into some 5500 lines of code, if I'm not mistaken. That's sort of smaller than Apache httpd. It's even smaller than nginx and lighttpd. And we're still talking about pretty weak languages, have you seen some of the self-hosting metacompiler stuff? (META-II, TREE-META, OMeta etc.) Don't forget that the design of the reference Go implementation is actually pretty close to the Oberon tradition of making things simple.


In terms of lines of code, I'm sure that things like OMeta are pretty small, but that doesn't mean the implementation is not complicated. And I'm not that familiar with the *Meta stuff, but AFAIK that stuff is just the frontend, whereas on the backend (the logic for generating the machine code / bytecode) things can get messy and complicated.

Also, I'm sure that the Go implementation is right now simple, but every mainstream compiler quickly evolves towards doing more and more AOT optimizations, like for performance or for better error messages. Again, performance optimizations can get really complicated and messy.


Not quite yet, it still builds a small bootstrapping tool with C


See https://github.com/axw/llgo for a 3rd party implementation based on LLVM that's fairly far along.


I would say it is.

Sure you will need to use Assembly for a few runtime parts, but C is no different, if you look at ISO/ANSI C without language extensions.


It is possible to write a Go compiler in Go.

But the current compiler works, has a lot of testing and production use and isn't broken in any serious way. For a compiler, I'm not sure Go offers enough benefits over C/C++ to make it worth throwing away the existing code base and rewriting.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: