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

171–180 of 265 posts

Re: Go 1.4 is released

#171

Post by JulianMorrison »

tormeh wrote: post #138
Morgawr wrote: post #135

Earlier quoted context omitted.

>imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and e…

Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.

Inheritance is almost always an anti-pattern. It's encapsulation-breaking, dependency-creating, brittle and limited.

Re: Go 1.4 is released

#172

Post by jrockway »

NateDad wrote: post #156
tormeh wrote: post #138

Earlier quoted context omitted.

Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.

There is almost never code that requires inheritance.

Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste.

"Give me an object like Foo, but with this one little thing changed."

Re: Go 1.4 is released

#173

Post by leaveyou »

teddyh wrote: post #126
leaveyou wrote: post #93

Earlier quoted context omitted.

I think you should do what you ask to be done. You fork Go under a new name, create a community with the same objectives as yours around it, be competitive and develop the language further and then reap the satisfaction. If there is a significant need for your ideas I'm sure the developers will join you (otherwise you will have the best proof that your idea is just not good enough for many others). Personally I'm ver…

You misunderstand me, please re-read what I wrote. Nowhere did I call for the forking of Go. On the contrary, I specifically wrote that it was unrealistic to even envision it , since it would not work as long as Google sponsored more into its development that I could do with the fork, and as long as Google was perceived as a more stable future sponsor of said development. What I wrote was that I, personally, would no…

Normally I don't reply in this kind of situations but I make an exception: 1 I think You misunderstand Go. 2 You complain about something you admit you don't know well. 3 You want the development to be more the way you want it without making any effort. My feeling is: Your internal feelings towards Go development are not relevant for many.

Re: Go 1.4 is released

#174

Post by kibwen »

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.
This is mistaken, as sharing immutable data between threads is trivially safe, and Rust's type system gives you the tools you need to prove that data is actually immutable (good luck sticking anything in an Arc if it contains an Rc (or any other non-Send type) anywhere within it). And sharing mutable data between threads can be safe if you get the locking right: Rust gets the locking right for you, so that you don't have to.

  > std::unique_ptr is a standard way to implement the same 
  > semantics as borrowed pointers in rust
No, std::unique_ptr is analogous to the Box smart pointer in Rust, except more onerous to use because move semantics are not the default in C++. C++ has no equivalent to Rust's borrowed references.

  > So being careful in C++ is easy today, can I say that 
  > C++ is safe?
Sure, if you're willing to throw out all C++ code written before C++11, and if you're willing to lower your standards of "safety" to "trivially, silently, and often surprisingly unsafe". :) I actually have a higher opinion of C++ than most developers you'll find (PHP too, but that's a different story...), but let's not pretend that safety is at all C++'s forte.

Re: Go 1.4 is released

#175

Post by SixSigma »

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.

> Android devs

there are plenty of non-Android devs, like me, that just don't want to go with Java and are not fussed about IDEs. I know full well there are plenty like me in the Go community.

Re: Go 1.4 is released

#176

Post by lazyjones »

_RPM wrote: post #5

Can someone give me a compelling reason to start programming in Go? My default language at the moment is C, or C++.

- garbage collection

- safe and easy programming (really!)

- no more shooting yourself in the knee with hard to debug problems

- lean but quite complete standard library

- native strings (proper unicode/utf-8 handling)

- very little boilerplate, sane defaults

- concurrency primitives (no tacked-on libraries)

- high performance - not far behind C/C++

- extremely easy and practical documentation features (via comments)

Re: Go 1.4 is released

#177

Post by NiloCK »

thechut wrote: post #166
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'm not sure how much more 'hockey stick' it can get. Android already has 85% market share.

alfiedotwtf was referring to the potential for hockey stick growth for go, not Android.

Re: Go 1.4 is released

#178

Post by bsaul »

dragonwriter wrote: post #162
bsaul wrote: post #85

Earlier quoted context omitted.

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.

Not sure where you got that feeling :

Android studio was just released a few weeks ago and became the official IDE for android. Xcode advocates building GUI using Wysiwyg tool. Swift has all the OOP features, and it also has an embedded "playground" mode, inside the IDE itself.

I don't think the trend is toward slim environments. There will always be people to say that doing things manually is better than having the computer do it, but it always surprises me when this thought comes from programmers themselves.

Note : i would actually love to have a great IDE for golang, with all kinds of refactoring, code analysis and autocompletion features ( lightIDE isn't one of them yet). I dont't think big IDEs are incompatible with elegant language, as swift+xcode or visual studio+C# show. To me the problem with Java is that there isn't a single framework that you could actually use if your only editor is emacs.

Re: Go 1.4 is released

#179

Post by melling »

lmm wrote: post #129
_RPM wrote: post #5

Can someone give me a compelling reason to start programming in Go? My default language at the moment is C, or C++.

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.

OCaml is been around for almost 2 decades. Something must be holding back its adoption. Microsoft's version F# seems to be doing better but developers aren't adopting it en masse.

Re: Go 1.4 is released

#180

Post by dragonwriter »

bsaul wrote: post #178
dragonwriter wrote: post #162

Earlier quoted context omitted.

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.

Not sure where you got that feeling : Android studio was just released a few weeks ago and became the official IDE for android. Xcode advocates building GUI using Wysiwyg tool. Swift has all the OOP features, and it also has an embedded "playground" mode, inside the IDE itself. I don't think the trend is toward slim environments. There will always be people to say that doing things manually is better than having the…

> There will always be people to say that doing things manually is better than having the computer do it

Languages that don't require a heavy IDE (particularly one including lots of tools for writing and rewriting code -- static analysis tools are a different issue) aren't "doing things manually instead of having the computer do it" -- interacting with the language itself is no more "manual" than interacting directly with the IDE. Its just aligning the write-language with the read-language. If I need a separate visual language to use to write code from the language I'm nominally working in, that both increases the overall mental complexity and indicates that there are weaknesses in the abstractions available in the nominal working language.

Post reply on HN