16 ms·
Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports
by sinatra 11y ago
Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes.
EDIT: I must highlight the point about checking lot of boxes. In many discussions about features of programming languages, we get responses like, "language Y does that too. Why not choose that language?" Well, because we don't pick languages for one specific feature. We pick them for the combination of features.
- zelcon5 11y ago> generics Go makes it easy for third party applications to parse the language,so generics are possible with pre-processing/codegen; e.g., https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/
- bigdubs 11y agoThe more I dig into type coercion and interfaces the less I miss generics. Still not 100% there, but for day to day the things I used to use generics for have been replaced by alternates. I still wish I never had to write `interface{}` though. Debugging absolutely needs work though.
- xyproto 11y agoEven with the delve debugger?
- fleshweasel 11y agoIs "alternates" a euphemism for "code duplication?"
- Others 11y agoOr code generation?
- iofj 11y agoI'm getting furstrated by code generation. I have a big project with has 3 files with (only) generated code. It's essentially repeating the same 15 lines about 50 times with slightly different types. And yet I far prefer all of them over an interface{} solution. Works so much better. But the files are just so ugly, and changing them is rather hard. Worst of it all, I've been thinking about generating other pieces of the code. For instance, I hate the http handlers and structure surrounding them being the same thing all the time. Http handlers = decode and basic argument validation, then authentication and CSRF protection, and then conversion (to be done ad-hoc because no types in http parameters), some using strconv, some using json encoding, all with "error handling" (essentially if error then bailout 502), followed by calling the actual method. All of them are the same (save for small bugs due to me not paying attention). I'm thinking of replacing it with generated code.
- iends 11y agoHave you looked at http://goa.design/ http://goa.design/ which kinda describes what you are talking about a bit (for REST apis).
- grey-area 11y agoWhat are you using generated code with lots of types for out of interest? I haven't felt the need as yet but would like to try it out. Re handlers, you really don't have to use the http handler. I use one which accepts a context, and returns an error (for rendering), which simplifies the boilerplate somewhat as errors are rendered by the router. I'd look into using your own interfaces before generating standard http handlers. The other thing to bear in mind is that if you try to make things all implicit rather than explicit in order to avoid repetition, it's very easy to be unaware of what's happening behind the scenes (auto-auth, or auto-render as in rails), and get stuck when you want to do something off the beaten path. I rather like Go's more verbose but very explicit style. It's a trade-off. Auth, CSRF, parameter parsing should definitely be in a separate pkg you're using, not repeated each time IMO, so there should be minimal boilerplate for those. Using text template is a really nice way to generate http handlers if you typically set up resources in a similar way, so I'd definitely recommend trying that out. I haven't looked into go generate as that came out after I started this approach. The approach I take is to generate actions with all the normal code in them as scaffold (for CRUD actions) - so for each one auth, then setup, then business logic, then render, and then edit those as necessary, as often as an app grows each action diverges from the standard (say it doesn't do auth, or processes parameters differently etc). This is easy, explicit, and very clear when returning to code after 6 months at the cost of some verbosity.
- chc 11y agoWhat is an alternate? I've never heard of that and Googling tells me nothing.
- pklausler 11y ago"is opinionated"? What does that mean in the context of a computer programming language?
- golergka 11y agoOne way to do things, not ten. Opposite example: implementations of OOP in Lisp and JS.
- pklausler 11y agoI'm not sure that I understand your definition of the term "opinionated". Is Haskell opinionated? Is Fortran?
- jgalt212 11y agoI take opinionated to mean one obvious way to do things. Python and Go are opinionated. Ruby and Perl are not. But RoR is very opinionated.
- antod 11y ago> I take opinionated to mean one obvious way to do things. Python and Go are opinionated. IMO Python wants to be opinionated (in your 'one obvious way' definition), and it actually was 10-15yrs ago when Perl was the comparison, but ongoing progress has eroded that a lot - especially across the stdlib :) But yeah Go and RoR are probably two of the most opinionated technologies I can think of.
- melted 11y agoDoesn't attempt to please everyone. Case in point: no OOP or inheritance and no FP. Minimal syntactic sugar.
- zdkl 11y agoNot to start a flamewar or anything, but what about clojure (or any lisp for that matter, I just like the CLJ ecosystem) doesn't vibe with your 'minimal syntactic sugar' and other requirements?
- meddlepal 11y agoJava SE and a fat jar... checks all the boxes and has generics and superior tooling. I still don't get the Go love.
- taf2 11y agoGo starts very fast compared to jvm. Go compiles into a binary that does not require a jvm to be installed... Go does not require an IDE to develop in... Go is also less verbose
- cgh 11y ago1. Not an issue for web services, which is what the OP was referring to. 2. See #1. 3. Neither does Java, although of course it can be helpful. 4. Error handling is certainly not less verbose. None of the above overcome the lack of tooling, libraries and generics, at least for me.
- fomojola 11y agoJava doesn't require an IDE either: emacs/Ant/Maven is all I've ever used. Barring specialized platform-specific toolsets (like Android Studio) you don't NEED anything else (you might WANT something else, but that's a separate issue...)
- xiaoma 11y agoemacs is an IDE wrapped inside half an OS
- Cyph0n 11y agoWhoops, seems like you pissed some people off :D
- AnimalMuppet 11y agoDon't forget the psychotherapist!
- znpy 11y ago
- voidlogic 11y ago>so is debugging Have you used delve? https://github.com/derekparker/delve https://github.com/derekparker/delve
- stirner 11y agoThis is very similar to my experience. There are some very obvious flaws that have been analyzed to death, but I find myself returning to Go despite them. The native binaries and extremely simple cross-compilation are the features that I really miss with other languages.
- fpoling 11y agoGo tools support code generators. So just use those for advanced data structures. As auto-generated it can support more features than even an advanced generics could provide. For me the big minus of Go is that it is memory unsafe language when it runs with GOMAXPROCS>1 (default since 1.5). It is not that bad like in C as opportunities for bugs are not common, still this is an issue as consequences of such bugs is arbitrary code execution. Another problem is lack of union types leading to poor code practice when those are emulated through (foo, err) or similar return types.
- pcwalton 11y ago> As auto-generated it can support more features than even an advanced generics could provide. No, it can't. There are patterns that no monomorphization strategy (including code generation) can express. For example: func MakeList<T>(x T) List<T> { ... } func Foo<T>(x T) { if ... { Foo(MakeList(x)) } } This is a contrived example, but this shows up from time to time in functional data structures.
- fpoling 11y agoCode generation can do type erasure starting, for example from List<List<SomeConcreteType>>.
- _pmf_ 11y ago> C derived What is that even supposed to mean? The semantics and memory model are nothing like C and the syntax even less so. > generates a single Just link against static libraries; it's literally a single switch. > supports concurrency very well Better than C; much, much worse than C# and I'd argue even worse than Java with j.u.concurrent (want channels? use j.u.concurrent.BlockingLinkedQueue)
- fithisux 11y agoGolang is my favorite. Started on 2010 and use it without hesitation.
- jug 11y agoGo feels similar to where Microsoft eventually wants to be with .NET Core and their native compilation. Other than that competitor, I don't think Go has too many others in the same niche. Maybe D? I love the combo of native code + high level language + single binary in a language that also tackles parallelism. It's as if the Go language designers took a good hard look at Python and went "This is what's wrong with it", taking its greatest weaknesses like dependencies/packaging and the GIL, turning these around 180 degrees, instead becoming main advantages of their new language. Of course, it's not an interpreted language so the comparison isn't perfect, but Go ticks a lot of boxes for me as well that Python perhaps never will due to design.
- coldtea 11y ago>Go feels similar to where Microsoft eventually wants to be with .NET Core and their native compilation. Only in that it will end in a native binary. In any other sense Go is worlds behind.
- Shorel 11y agoD lang seems to be another obvious candidate here.