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

Last I checked Go doesn't have any memory placement semantics. That's a non-starter IMO for a systems programming language.

I like performance in my systems programming languages and you won't get that if you can't control where your memory lives.



> Last I checked Go doesn't have any memory placement semantics.

Many OSes like Oberon, Cedar, Topaz, SPIN among others were written in languages without direct support for it, so it is possible to write an OS without it.

The runtime package just needs to offer the services for it, just like many C functions are actually implemented in Assembly.


Theoretically they (or whomever writes an OS in Go) could extend the runtime to add something like `makestack(Type, size IntegerType) Type` to mimic alloca or add in a guarantee that `var b [100]byte` will be allocated on the stack.

(Right now I think it is, but I know there's a Go issue dealing with a function like this, and one of the comments was about potentially creating `a` on the heap and returning an invisible pointer instead of the actual 1e9 bytes.)

    func foo() (a [1e9]byte) { return a }


There's a lot more than that that you have to do. You can't even implement defer without allocation, just to name one example.


True, the amount of Assembly in a bare metal runtime in Go vs a runtime free version of Rust will be higher.

Still, there are quite a few scenarios that could be served by such implementation, instead of being implemented in C or C++.

As I mentioned in another thread, any embedded board computer similar to a Raspberry PI could most likely be easily targeted by such cross-compiler.




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

Search: