Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.4 is released

blog.golang.org

Post reply on HN
Print view View original

161–170 of 265 posts

Re: Go 1.4 is released

#161

Post by chaotic-good »

kibwen wrote: post #154
chaotic-good wrote: post #150

Earlier quoted context omitted.

It is common to use ARC and unsafe shared memory access in Rust. This defeats the purpose of this complexity. You can't isolate unsafe memory access. You rather write only memory safe code or end up with fully unsafe codebase where some nasty things (buffer overruns or segfaults) are possible. If somebody needs memory safety - managed languages with GC is the only real option.

> It is common to use ARC and unsafe shared memory access > in Rust This is false. `Arc` is not common, and when it is used, it is to enable safe shared memory access. > You can't isolate unsafe memory access This is also false. If you get memory unsafety outside of an `unsafe` block, it is a by definition a bug in the compiler.

> This is also false. If you get memory unsafety outside of an `unsafe` block, it is a by definition a bug in the compiler.

All `unsafe` memory access in Rust performed in separate address space? I'm asking because if it isn't - this can't be called `isolated`.

Re: Go 1.4 is released

#162

Post by dragonwriter »

bsaul wrote: post #85
alfiedotwtf wrote: post #6

Earlier quoted context omitted.

And now things just got interesting. I'll put my money on the availability of Go on Android being the catalyst for its future hockey stick growth.

I would be extremely surprised to see a language having no class, no inheritance and no good IDE become successfull in modern app development. Android devs are used to such a different type of programming, i don't expect them to accept banging their heads on so many walls for such little gains. Ps : my stand is the opposite for server side dev.

It nay not become popular among existing, heavily invested mobile devs, but they aren't the only devs who might target mobile. And the fashion of class-based OO and languages that require heavy IDEs seems to be increasingly less accepted as the one true way.

Re: Go 1.4 is released

#163

Post by omellet »

radicalbyte wrote: post #111
swah wrote: post #98

Earlier quoted context omitted.

Git is equally hostile to everyone! Long live Git. (Maybe the way to advance the poor Gui user interaction experience is to write frontends for it?)

If they're smart, Perforce will integrate their UI tools with Git. They have by far the best UI for a Git-style SCM.

Perforce is not Git-style, it's got a single central repository.

Re: Go 1.4 is released

#164

Post by lmm »

Dewie wrote: post #132
lmm wrote: post #129

Earlier quoted context omitted.

If garbage collection is acceptable, you'd learn more from trying OCaml - or even Haskell, if you want to really expand your comfort zone. I'm not saying don't learn Go eventually, but for the "second language" you should try something more different from C/C++ so you get more of an idea of the range of stuff out there.

Doesn't OCaml have bad support for concurrency, though? Concurrency is one of the features that people who look into Go are often after.

True concurrency as in concurrent computation yeah, it's a bit awkward. But if you just want async I/O (which covers a lot of cases - if you're rendering a web page based on a database query, being able to handle other requests while you're waiting for the database results is much more important than being able to do the actual HTML rendering in parallel) it's pretty good at that AIUI.

Re: Go 1.4 is released

#165

Post by chaotic-good »

Dewie wrote: post #153
chaotic-good wrote: post #150

Earlier quoted context omitted.

It is common to use ARC and unsafe shared memory access in Rust. This defeats the purpose of this complexity. You can't isolate unsafe memory access. You rather write only memory safe code or end up with fully unsafe codebase where some nasty things (buffer overruns or segfaults) are possible. If somebody needs memory safety - managed languages with GC is the only real option.

> It is common to use ARC What is unsafe about using atomic reference counting? > and unsafe shared memory access in Rust. That should be provided with a safe interface, or an unsafe interface if calling that code is not safe. As for it being common: I think they are working on minimizing the need for unsafe code. > This defeats the purpose of this complexity. Like having a VM implemented in C defeats the purpose of…

> What is unsafe about using atomic reference counting?

Nothing at all. But sharing objects between threads is unsafe.

> Like having a VM implemented in C defeats the purpose of the VM for that language being safe.

You can prove that VM code is memory safe? Good for you.

> Sure you can - owned and borrowed pointers in Rust are represented as raw pointers at runtime. It's a safe abstraction. And if there turns out to be a bug in that interface, and they aren't really safe, then that will have to be fixed promptly - unlike in C/++, where one would be forced to say "Well, that's your fault for not being careful".

And in C++ we have value and move semantics. Nobody uses pointer arithmetic to implement arrays and strings anymore. std::unique_ptr is a standard way to implement the same semantics as borrowed pointers in rust. Array access can be range checked if you want. So being careful in C++ is easy today, can I say that C++ is safe? :)

Re: Go 1.4 is released

#166

Post by thechut »

alfiedotwtf wrote: post #6
krat0sprakhar wrote: post #2

> The most notable new feature in this release is official support for Android. Using the support in the core and the libraries in the golang.org/x/mobile repository, it is now possible to write simple Android apps using only Go code. This is fantastic! Are there any example Android apps released by the Go team to help get started ?

And now things just got interesting. I'll put my money on the availability of Go on Android being the catalyst for its future hockey stick growth.

I'm not sure how much more 'hockey stick' it can get. Android already has 85% market share.

Re: Go 1.4 is released

#167

Post by rnhmjoj »

xrstf wrote: post #92

Damn, another project giving up on Mercurial and switching to Git. :-/ A few more major ones and basically nobody is using Mercurial anymore. How sad.

I have never use hg. I don't really see much difference. What do you like about it?

Re: Go 1.4 is released

#168

Post by Dewie »

chaotic-good wrote: post #165
Dewie wrote: post #153

Earlier quoted context omitted.

> It is common to use ARC What is unsafe about using atomic reference counting? > and unsafe shared memory access in Rust. That should be provided with a safe interface, or an unsafe interface if calling that code is not safe. As for it being common: I think they are working on minimizing the need for unsafe code. > This defeats the purpose of this complexity. Like having a VM implemented in C defeats the purpose of…

> What is unsafe about using atomic reference counting? Nothing at all. But sharing objects between threads is unsafe. > Like having a VM implemented in C defeats the purpose of the VM for that language being safe. You can prove that VM code is memory safe? Good for you. > Sure you can - owned and borrowed pointers in Rust are represented as raw pointers at runtime. It's a safe abstraction. And if there turns out to…

> Nothing at all. But sharing objects between threads is unsafe.

If sharing stuff between threads in Rust is unsafe, then that is a bug which you should report.

> You can prove that VM code is memory safe? Good for you.

Uh, that's my point... VM implementations are usually not proved to be safe, any more than unsafe code in Rust is proved to be safe.

> And in C++ we have value and move semantics.

Which aren't bulletproof - if you're not careful, they can be used in an unsafe way. Well, this is second-hand information, so take that for what you will. You could ask pcwalton about it if you want a truly informed opinion.

> So being careful in C++ is easy today, can I say that C++ is safe? :)

Sure you can. You can say, "My code is safe, because I only use feature X, Y, Z / because I avoid this and that...". While someone using Rust should be able to say "My library is safe, since I make no use of unsafe blocks".

Re: Go 1.4 is released

#169

Post by kibwen »

chaotic-good wrote: post #161
kibwen wrote: post #154

Earlier quoted context omitted.

> It is common to use ARC and unsafe shared memory access > in Rust This is false. `Arc` is not common, and when it is used, it is to enable safe shared memory access. > You can't isolate unsafe memory access This is also false. If you get memory unsafety outside of an `unsafe` block, it is a by definition a bug in the compiler.

> This is also false. If you get memory unsafety outside of an `unsafe` block, it is a by definition a bug in the compiler. All `unsafe` memory access in Rust performed in separate address space? I'm asking because if it isn't - this can't be called `isolated`.

Ah, I thought we were talking about isolation for code auditing purposes. If you're concerned about address space isolation, then this other statement is false:

  > If somebody needs memory safety - managed languages with 
  > GC is the only real option
If I'm in Java, I can call C code via JNI that does whatever garbage I want with the memory of the Java program. There's no isolation there; we are thwarted by the need for FFI. Likewise, `unsafe` in Rust is just a reified FFI: it allows you to do things that Rust doesn't allow you to do, but, crucially, `unsafe` blocks in Rust are still much safer than the C code that you'd otherwise be writing. Thus `unsafe` is a mechanism for making Rust programs safer than they otherwise would be, by avoiding the need to call into C.

Re: Go 1.4 is released

#170

Post by melling »

guelo wrote: post #76
bradfitz wrote: post #3

Earlier quoted context omitted.

https://github.com/golang/mobile/tree/master/example

As far as I can tell these samples are immediately bailing out of the Java framework and calling Go using JNI. Which means you don't get the niceties of the UI Framework. You could make OpenGL calls from the Go code like for a game or something. Maybe someone will come up with a Go game engine for Android.

Is there any way to integrate the Java framework? Even something tedious could be crowdsourced with enough help.
Post reply on HN