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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

181–190 of 318 posts

Re: Seven years of Go

#181

Post by _ph_ »

tedunangst wrote: post #83
tptacek wrote: post #61

Earlier quoted context omitted.

Even writing Postgres functions, you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) over and over again. People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it.

I'll argue this point. It takes me 30 seconds to write a SQL query. It's not hard. On the flip side, I don't end up running queries that haul megabytes of data in just to peek at one column. SQL is already much higher level than assembly. Piling on more abstraction just increases the likelihood that the code is doing extraneous work.

Fully agree. ORMs save you typing if you just need to wrap a table, but for complex multi-table queries I have seen really bad performance as a result. I rather prefer to capture my queries in a view, and then wrapping that is so trivial, that I don't need an ORM.

Re: Seven years of Go

#182

Post by swift »

aikah wrote: post #168
stcredzero wrote: post #138

Earlier quoted context omitted.

Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. Classic. All languages stink, somewhere. The classic programmer Dunning-Kruger mistake: evaluating one language without self-awareness of all of the (probably unconscious) cost/benefit optimizations that mostly apply to the other language. This is like Smalltalkers and C++ programmers in the 90's arguing ab…

> If you're such a poor programmer, No need for personal attacks. > then just find a different language. What a warm an welcoming community the Go community is /s C++ doesn't have reflection, because it doesn't need it. But somehow Go needs it ? Reflection is a cop-out, especially in a language that has a simplistic type system. And don't get me started on struct tags. If you cant see the obvious issue with all these…

Gotta tell ya, criticizing Go for lacking generics, which Go supporters argue are unnecessary, while simultaneously arguing that C++ doesn't have reflection because it "doesn't need it" is ironic in the extreme.

Re: Seven years of Go

#183

Post by Matthias247 »

aikah wrote: post #172
Matthias247 wrote: post #110

Earlier quoted context omitted.

IMHO Go is a good choice for lots of system daemons and commandline tools. If networking is involved it shines even more. > 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere? You could apply this criticism to nearly all languags, as there are currently only very few that are used for native GUIs: C and C++, because the operating systems and native toolkits are written in t…

Python has strong support for Gnome libraries, therefore GTK+ through GObject introspection. Go type system is too rigid to allow a tool like GObject introspection to interact with Go code. So no, this criticism doesn't apply to nearly all languages.

Might be true that Python has some advantages in wrapping GTK+ or even QT. But the parent mentioned "proper penetration of the GUI market". And I think also for Python the amount of GUI applications is quite low.

Re: Seven years of Go

#184

Post by weberc2 »

pcwalton wrote: post #176
weberc2 wrote: post #156

Earlier quoted context omitted.

> No, there's a lot more. See my reply to your sibling comment. Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety? > Why is being better than a language from 1978 our sole criterion? I have no idea. Thankfully no one made any such argument. > Shouldn't we try to make our software as reliable as possible? No, we should make it sufficiently reliable. For example,…

> Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety? Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc. > By the by, I like Rust, I just think it's not well-suited for most applications. I'm going t…

> Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc

Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's.

> I'm going to push back on this too ... our core infrastructure ... libraries have outsized importance.

Granted, but that's not "pushing back" on my point, because important though those libraries may be, they still don't constitute a majority of applications.

> This assumes that C is OK for safety critical applications. It's not. The status quo is bad. The bar should be much higher.

Agreed. Rust is better than Go for safety critical applications--note that I never tried to argue the opposite--only that Go is better than the status quo, terrible though it may be.

Re: Seven years of Go

#185

Post by _ph_ »

wyager wrote: post #89
gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

> what it does couldn't possibly be done in e.g. Python What can you do in Go that you can't do in other languages? I can't think of anything. The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives, but you also lose a lot of expressive power.

Of course there is almost nothing, which you cannot possibly do in any other language. The question is, at which effort and the resulting program quality. Go gives you strict (vs C) static type checking. Its local type inferencing saves you a lot of typing (as in keyboard) and makes the code concise and thus readable. It has a proper package system and very fast compile times (for larger projects way faster than C and C++). It has a rather rich standard library, it has a great GC which gets even better in 1.8 (100 microsecond stop times).

Re: Seven years of Go

#186

Post by misiti3780 »

sqrt wrote: post #55
drej wrote: post #47

My 2c: Go is incredibly convenient for non-programmers. I don't make a living writing software, I make a living answering quantitative questions, using computers. I use Python for most tasks, but when I need extra performance and/or portability, I grab Go every single time. The main appeal is the quality standard library that covers most things I get in contact with. I could get immersed in it right away, because I d…

> I've built tiny servers, parsed plethora of file formats, calculated maths, wrote data, (de)compressed stuff, encrypted things, ... If you've written code to do all those things, I think you'd be justified in calling yourself a programmer, even if software isn't your main gig. :)

just curious, why write file parsers in go rather than say, python

i would think python would be easier.

Re: Seven years of Go

#187

Post by weberc2 »

fizzbatter wrote: post #144
pcwalton wrote: post #129

Earlier quoted context omitted.

> Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. No, there's a lot more. See my reply to your sibling comment. > I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C. This argument doesn't make any sense to me. Why is being better than a language fr…

> Besides, Go is not any safer than C when it comes to data races. I care about those a lot too. Agreed. It may be safer in the realm of "oops i forgot to free memory", but i've had more panics than i could count in Go.

More importantly, it's safer in terms of using only valid memory.

Re: Seven years of Go

#188

Post by AsyncAwait »

chmike wrote: post #139
AsyncAwait wrote: post #106

Earlier quoted context omitted.

> strikes the right balance for me between productivity and safety. Would be curious to hear what "safety" you're referring to, is it just that it has a basic static type system, (which is constantly being undermined by interface{} and reflection), or is there more to it? Genuinely curious.

Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking. I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.

> compared to C it is safer. I never saw a segmentation fault

Well, yeah, it has a GC so it kind of gets that "automatically", I was thinking more about the type system side of things. And compared to C almost anything is indeed safer.

> I prefer go to python or javascipt. It's far too easy to make errors in them.

That's fair, but these are both dynamic languages, so almost anything with any level of static typing beats them in this regard, I was interested if Go does anything beyond that.

Not to say these are not fair points, but nothing a whole host of other languages haven't provided before Go.

Re: Seven years of Go

#189

Post by takeda »

chmike wrote: post #139
AsyncAwait wrote: post #106

Earlier quoted context omitted.

> strikes the right balance for me between productivity and safety. Would be curious to hear what "safety" you're referring to, is it just that it has a basic static type system, (which is constantly being undermined by interface{} and reflection), or is there more to it? Genuinely curious.

Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking. I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.

Comparing Go to C is like comparing C to assembly. You get segfaults because C is lower level and allows you to do things that are nearly impossible to do in higher level languages.

Better comparison is to compare Go to Java, also doesn't segfault, because it doesn't let you.

Re: Seven years of Go

#190

Post by weberc2 »

pjmlp wrote: post #107
weberc2 wrote: post #98

Earlier quoted context omitted.

Efficient concurrent programming. I'm not aware of any cross-platform C/C++ or Python libraries that give you async I/O + multi-threaded coroutines. Such a library exists for the Java ecosystem (quasar), but IIRC, it's enabled by clever bytecode tricks, so it's not built with vanilla Java. Further, you still have to take care not to use any libraries that are incompatible with this concurrency model (e.g., anything t…

C++17 gives you async/await, coroutines and parallel algorithms.

Right, but this is still a far cry from Go's runtime/scheduler. In particular, the Go runtime completely handles threading and async I/O for me. I'm not sure what C++17 coroutines look like, but I don't even have to explicitly yield (which is the case in other C++ coroutine libraries).
Post reply on HN