161–170 of 318 posts
Just wondering: Are people using Go as a target-language for compilation?
Earlier quoted context omitted.
You can also build enums by building a struct with a `Tag` field. This works well and generally has better performance characteristics than using interfaces.
That approach has its own problems, such as wasting memory (need to store any data for each tag value separately, rather than benefiting from overlapping storage ala Rust enums or C tagged unions), as well as losing type safety: one has to manually remember which (groups of) fields correspond to which tag values (although the Go loss of type safety is far better/more controlled than the one for C tagged unions). Usin…
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…
Go is the VB, or the PHP of service development. Lots of obvious and immediate shortcomings, but with just the right amount of niceties for its domain in a very easy to teach and deploy package.
has anybody evaluated building an api in Go vs Kotlin ? We are considering moving our financial tool api from python to either Go or JVM/Kotlin/JavaLombok+lambda . I really like Kotlin as a language.. but im really worried about the future. Jetbrains isnt Google.... I like Kotlin also because we are an app-based startup.. and we have been considering Kotlin on the app side as well. That would be a nice crossover of e…
Earlier quoted context omitted.
I'm not sure if this would work for you, but using something like Electron and having your go program output HTML/JS/CSS as your UI works really well with go (or have your go program output JSON or something to communicate with the front end) If you throw something like react on there, you'll have a pretty simple functional UI, but if you don't want that there's nothing wrong with HTML/CSS and as little JS as you can…
That sounds an interesting concept and useful for creating instantly-usable web apps but in effect isn't your Go app being relegated to a HTTP server? eg. how would I do callbacks without doing them as some request back to the Go "server" app? How would you create custom controls in this method? eg. if I wanted to do my own pie chart control/widget with popups etc. It sounds like a long way around in comparison to wh…
Well from the OS vendors themselves we had MFC/WTL/Windows Forms/WTL on Windows, BeOS GUI, Symbian UI, CSet++ on OS/2, PowerPlant on Mac.
Additionally there was Turbo Vision on MS-DOS, OWL, VCL for Windows, Motif++ on UNIX.
Earlier quoted context omitted.
This is a conscious decision. I believe the reasoning was readability. Ternary operators have a habit of being used in some really nasty nesting. https://golang.org/doc/faq#Does_Go_have_a_ternary_form
a = flag ? b : c is much more readable and concise than if flag { a = b } else { a = c } battling habits by making useful code inconvenient is just sad
a := c
if flag {
a = b
}Earlier quoted context omitted.
> Many of the "old" ways of thinking do not apply to Go Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen. When I say the language is broken, look at Go type system, then look at how Go reflection makes the languag…
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…
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 "features", in comparison of the lack of expressiveness of types AT COMPILE TIME then good for you.
Earlier quoted context omitted.
Precisely as I said, "The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives" 99% of projects don't need green threads. But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang. This isn't a very convincing argument for Go.
Erlang isn't necessarily better than Go in this regard. Since Erlang is interpreted and everything has to copied between processes, Go is bound to be faster than Erlang, especially when it comes to parallelism. Go is also statically typed, which in my experience makes it easier to avoid bugs in large teams. Erlang, however, is much better at distributed concurrency. There are few who suits this use case better. As in…
Earlier quoted context omitted.
I don't know how, but frankly i'd love to eliminate all simple panics. Nil pointers and channels seem two big culprits, offhand. Granted, i left out nil pointer/interface panics because it seems unrealistic given how difficult it was for Rust to get rid of nil pointers. I'm not sure Go 2.0 could do it and still be considered Go.
I agree; I want non-nillable types in Go. This despite the differences in Go that makes nil values more "valid" than they often are in other languages. I still faintly hold out hope. Unlike many of the complaints about Go that would require fundamental restructuring, C# showed that actually can be retrofitted onto a language without breaking it.