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

Grappling with Go

blog.ntpsec.org

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Grappling with Go

#111

Post by weberc2 »

MichaelGG wrote: post #101
codygman wrote: post #90

Earlier quoted context omitted.

> Go doesn't go beyond Java level safety Go doesn't reach Java level safety because of a lack of generics.

Well it's still memory safe though, right? You'll just get a runtime error, not memory corruption.

Mostly. Java puts a lock on every single object in a multithreaded context; Go doesn't do this as a performance tradeoff, so two goroutines manipulating a pointer simultaneously will likely corrupt it. FWIW, I've been using Go for 4 years and I've not yet seen a memory corruption.

Re: Grappling with Go

#112

Post by bborud »

sanjayts wrote: post #110
bborud wrote: post #98

I've changed my main language for doing work only a handful of times and it usually takes a few years of doing side-projects in a new language before I switch. For instance it took about 7-8 years before I switched to Java (and then only after establishing a programming style that doesn't rely on frameworks at all). The language wasn't hard to learn, but it took a while for the JVM and the standard library to get to…

Sorry if you saw this coming but do you really not miss generics and exceptions? I like Go given that it's a lean language and the compiles down to a self contained binary which doesn't consume gobs of CPU or memory and is pretty quick to start-up and run. Perfect language for writing command line tools and one-off network clients. But I dread the feeling of writing repetitive error handling code and copy-pasta to ge…

I haven't wrapped my head around how I want to do error handling in Go yet, so it is a bit early to say. I think I really need to write more code that deals with abstraction layers before I can have a useful opinion on the matter. Not that I'm too worried about not having figured out that bit yet since error handling took me a while in all other languages as well. (I think my first approach was to use panic() where I used exceptions in Java. But that doesn't really tell you anything very useful unless you also know how I use exceptions in Java :-))

I don't mind a bit of boilerplate as long as it produces understandable code. Writing boilerplate can be automated. Reading and understanding code can't.

I do understand where you are coming from though. Perhaps we're getting a bit spoilt as programmers in feeling that error handling should be ... more elegant for a language designed within the last decade? :-)

I think the same goes for generics, though I have a hunch that I'm not going to miss it. And I'm not sure why, but that's how it feels now. Whenever I do design classes that are genericized in Java I do so sparingly. This is mostly to ensure that the code is easy to reason about. I'm not fond of "clever" uses of generics because while it may feel satisfactory to have things click together in a beautifully complex manner, it can make code hard to read.

Re: Grappling with Go

#113

Post by saywatnow »

pjmlp wrote: post #58
saywatnow wrote: post #16

DNS lookup stalls as motivating concurrency .. messy, complicated code with known bugs .. seriously? It's not that hard to call getaddrinfo() in a thread and feed results back (atomically) over a pipe. No shared memory or mutexes needed. Looking at Android as a representative of "embedded" also seems a bit fallacious. The lowest-end android device I can buy has a lot more ram, storage and clocks than an average home…

> Looking at Android as a representative of "embedded" also seems a bit fallacious. The lowest-end android device I can buy has a lot more ram, storage and clocks than an average home router. Well you can look at ARM Cortex-M3 running MicroEJ instead. http://www.microej.com/resources/supported-platforms/

I don't understand the relevance?

Re: Grappling with Go

#114

Post by outworlder »

problems wrote: post #63
nicoburns wrote: post #23

Earlier quoted context omitted.

The question of Go or Rust for something like web services is not as clear cut in my opinion. I have JavaScript/PHP background, and have recently learnt Rust for just this use case. Rust is slightly more complex (but really not that much, nothing close to as bad as C++), but also offers more correctness guarantees. Both are good choices, hence these discussions.

> but really not that much, nothing close to as bad as C++ C++ dev here. Rust's borrow checking system is crazy and even after a week of trying I couldn't understand it in a way that I could reliably use the language. In C++ everything is fairly straight forward and well documented, in Rust it feels like I'm inserting random symbols in hopes that something will compile. The syntax is verbose and ugly, maybe not as ba…

> In C++ everything is fairly straight forward and well documented

Wow! C++ is full of undocumented and documented, but non-obvious, behavior. I guess that speaks volumes about your experience with C++: given enough time, anything is straightforward.

Rust has a steep learning curve (I'm still climbing it), but it is nowhere even close to C++. C++ gives you a false sense of security, in the sense that code will often compile, but be obviously wrong (for someone knowledgeable). The Rust compiler will not stop complaining until you correct your program.

It's even worse for beginners. Rust learners will get frustrated because their programs are not compiling. C++ learners will get frustrated because their programs will segfault. Often because of some obscure issue, such as someone who forgot to implement copy constructors or assignment operators. I've been there, these issues are completely non-trivial to debug.

I would rather have a compiler yelling at me, but that's me.

Also, since you mentioned that you've been trying for a week: do you think a novice C++ programmer would be able to actually do anything coherent in C++ after a week? Heck, I don't think that's enough time to even go through the spec!

Re: Grappling with Go

#115

Post by pjmlp »

saywatnow wrote: post #113
pjmlp wrote: post #58

Earlier quoted context omitted.

> Looking at Android as a representative of "embedded" also seems a bit fallacious. The lowest-end android device I can buy has a lot more ram, storage and clocks than an average home router. Well you can look at ARM Cortex-M3 running MicroEJ instead. http://www.microej.com/resources/supported-platforms/

I don't understand the relevance?

MicroEJ OS, a Java based OS for micro-controlers like the ARM Cortex-M3, with 128 MB NAND FLASH + 512 kB internal for storage and 32 MB SDRAM + 96 KB internal for program data, running at 12 MHz is far away from the average Android device configuration, yet can still run a mix of Java/C stack.

Re: Grappling with Go

#116

Post by saywatnow »

pjmlp wrote: post #115
saywatnow wrote: post #113

Earlier quoted context omitted.

I don't understand the relevance?

MicroEJ OS, a Java based OS for micro-controlers like the ARM Cortex-M3, with 128 MB NAND FLASH + 512 kB internal for storage and 32 MB SDRAM + 96 KB internal for program data, running at 12 MHz is far away from the average Android device configuration, yet can still run a mix of Java/C stack.

OP: go has an interest in suiting embedded because Android.

Me: Android doesn't need to meet constraints anywhere near a home router (which needs to run ntpd)

You: there's a proprietary Java-based OS for Cortex-M3

.. still don't get it. Are you trying to sell me something?

Re: Grappling with Go

#117

Post by pjmlp »

saywatnow wrote: post #116
pjmlp wrote: post #115

Earlier quoted context omitted.

MicroEJ OS, a Java based OS for micro-controlers like the ARM Cortex-M3, with 128 MB NAND FLASH + 512 kB internal for storage and 32 MB SDRAM + 96 KB internal for program data, running at 12 MHz is far away from the average Android device configuration, yet can still run a mix of Java/C stack.

OP: go has an interest in suiting embedded because Android. Me: Android doesn't need to meet constraints anywhere near a home router (which needs to run ntpd) You: there's a proprietary Java-based OS for Cortex-M3 .. still don't get it. Are you trying to sell me something?

That there are Android like OSes that run in hardware less powerful than home routers.

Re: Grappling with Go

#118

Post by saywatnow »

pjmlp wrote: post #117
saywatnow wrote: post #116

Earlier quoted context omitted.

OP: go has an interest in suiting embedded because Android. Me: Android doesn't need to meet constraints anywhere near a home router (which needs to run ntpd) You: there's a proprietary Java-based OS for Cortex-M3 .. still don't get it. Are you trying to sell me something?

That there are Android like OSes that run in hardware less powerful than home routers.

The relevance of Android here is that Go has a reason to target it. Not that it's a Java/C hybrid.
Post reply on HN