9 ms·
Maybe the same applies to building a RESTful API and choosing Go instead of js :)
by RapperWhoMadeIt 5y ago
Maybe the same applies to building a RESTful API and choosing Go instead of js :)
- jpgvm 5y agoYou will get slightly better people but still the wrong people. JS is almost never the right tool for the job, Go is occasionally the right tool for the job, mainly if you need to write something that moves bytes from one fd to another without much in the way of business logic. TBH if you are building something boring you should just use Spring w/Java or Kotlin. This will attract pragmatists that ship code that works in ways that anyone else that works with these tools will instantly understand also. In a way it attracts mediocrity but in the good way where you get nice standard code that can be maintained cheaply for a long time and it's easy to hire for the skillset. If you are prototyping extremely quickly then maybe Ruby on Rails might be the right tool for the job (and thus attract the right kind of people). Go attracts mediocrity and not in a good way, it also actively repels the "right " people if you want to hire for highest intellectual horsepower for a given budget. In the same category as Haskell you also have OCaml, the Lisps (Clojure in particular) and Erlang all of which will yield you lots of the "right" people. None of these people will be cheap but none of the good people that write the other languages are cheap either, however there is a strong correlation between interest and proficiency in these languages and high intellectual horsepower - hence "right" in this context.
- tharne 5y agoThis can cut both ways. Yes, if you choose Haskell, a Lisp, or something like Erlang, you can get smarter/better devs. But the flip side of that is that the types of people who tend to gravitate toward those languages are often more interested in programming for it's own sake and not the domain they're working in. So you get things like people burning hours writing their own libraries and endless tinkering with programming minutiae instead of getting sh* done. On the other hand, a mediocre programmer who taught themselves Python, may not be winning any programming competitions, but will often have significant domain expertise and a bias toward getting things done. You need to ask yourself whether or not the stuff you're working on really demands the absolute best programmers (it very rarely does). If it does, go with the Erlang/Haskell/Lisp crew, otherwise go with the Python/JS/Go crew.
- jpgvm 5y agoThis is where I differ. I think the Python/JS/Go crew gets you stuff that is built poorly and becomes expensive to maintain. I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, their tools aren't constantly changing so for the most part they only need to spend time actually doing work. No fighting with package managers, no updating the latest framework and solving backwards incompatibilities for weeks, no random runtime bugs and shitty native extensions that cause said runtime bugs or memory leaks outside of runtime level heap accounting, etc. Boring tech is the way to go for 99% of problems and to me JS/Go/Python don't qualify because they break too much and require too many workarounds for too many problems. I want my programmers to be thinking about how to solve my business problem, not problems with their tools.
- mbesto 5y ago> I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, I don't think thats what the parent meant. They meant esoteric functional programming languages vs mainstream OOP ones. You're saying the same thing.
- jpgvm 5y agoI was clarifying I consider them to be separate categories. Java/.NET cultures are distinctly different to Go/JS/Python despite both categories being mainstream. The former is old, boring and sticks to what works. They are both slow moving, have large established frameworks for each applicable domain, prioritize backwards compatibility, have highly evolved IDEs that support both the language but also the dominant frameworks etc. The latter are easy to learn, emphasize the easy creation of new applications and libraries, move quickly/rapidly adopt new language and runtime features, don't generally care much for backwards compatibility in the library ecosystem, have many competing frameworks and libraries for everything. etc. They are just very very different and as a result produce very different codebases that have very different tradeoffs in hiring, maintainence costs, development velocity, pivotability etc. Sometimes those languages are the right tool for the job but IMO mostly in cases where you aren't sure what that job is. If you already know what you want to build and how to build it then the "boring" tech stack is generally the way to go in my experience.
- unfocussed_mike 5y ago> If you are prototyping extremely quickly then maybe Ruby on Rails might be the right tool for the job (and thus attract the right kind of people). I am puzzled by this because my early experience of Ruby On Rails (and I mean early -- 2005) is that every Rails developer I encountered knew much less than they were letting on. > Go attracts mediocrity and not in a good way, it also actively repels the "right " people if you want to hire for highest intellectual horsepower for a given budget. I really think this needs backing up with at the very least a juicy horror story! I'm not convinced by this at all.
- jpgvm 5y agoFor context I worked with Go extensively for about 5 years. I tried very hard to like it because I have immense respect for folks on the core team. I even wrote some pretty good code in it. However a few things became very clear to me over time. 1. Go is -not- a general purpose language. It lacks expressiveness necessary for this purpose which leads to overly hard to follow and refactor business logic, repetitive and error-prone (hah) error handling. Poor/inconsistent null handling. Highly variable quality standard library (some stuff is amazing like it's HTTP and TLS stacks). This leads it to be very good at one thing and one thing only, network servers, preferably operating at the protocol level. I think if you want to write a custom DNS, TFTP, or other simple network protocol and you cbf using Rust then Go is a great choice. 2. Go is easily picked up but very hard to master and the reward for mastery is much lower than languages that have similar learning curves. I would say I got very close to mastery but gave up short of the goal. Some things that come to mind here are handling of channels especially in select statements is much more nuanced than most would imagine, hell channels in general are -very- subtle. Subtle is never a word I want to hear when talking about a tech that I'm expected to support and mentor juniors to use. 3. Go leads to masses of very poor quality code that becomes extremely expensive to refactor, in large part due to language design decisions. However it's also a follow on effect of the above point but that applies equally to Python, JS, Ruby etc. What makes Go unique in this regard is that it is already a very verbose language but goes further to have a poor module system and structural typing system that makes code inflexible. 4. The ecosystem lacks high quality frameworks ala Spring that can be used to build applications in such a way that knowledge of structure and style are portable across codebases/companies/etc. Go (like JS) favours a smaller composable library approach which lends itself much better to highly experienced developers than beginners that really do need the help because they are yet to develop good taste. Unfortunately Go mainly caters to beginners so this is a fundamental impedance mismatch between the ecosystem and the users. 5. It actively repels experienced engineers. This is probably the controversial point but it holds true among my social group which I would consider to all be A++ engineers both in intellectual capacity but also real world effectiveness (i.e these guys build the stuff you rely on every day). Why is this so? Well it boils down to that bit about mastery no being rewarding. Even in Java which is admittedly probably the most boring language on the planet there is a very rewarding payout for sticking with the language for a decade and getting exceedingly good at it, you have all the primitives at your fingertips, real threads, powerful reflection, metaprogramming and runtime introspection. What does Go offer? M:N coroutine model, pretty basic profiling capabilities, really shitty (and slow) reflection, runtime with almost no knobs to apply workload specific optimisations, etc. In short for all that time investment to fully peak out you are only marginally better than the next mediocre dev. TLDR: The ceiling is low, you end up surrounded my mediocrity, it's hard to effect change in large codebases as a result, Java/.NET/other langs don't suffer anywhere near as badly as such Go is avoided. I could go on but these are the main points. Also I could just be jaded old and grumpy but whatever, this is how I feel about it and everyone is free to be wrong on the Internet.
- 4e530344963049 5y ago"JS is almost never the right tool for the job" Except, you know, in the browser...
- mountainriver 5y agoYeah I didn’t get that part, JS is one of the most used languages because of the browser
- UnpossibleJim 5y agoWeb Assembly is right around the corner... still =P
- jpgvm 5y agoThis is fair. I don't write browser code.
- 7thaccount 5y agoI assume they meant everything, except the browser (like electron apps or NodeJS on the backend).
- yakshaving_jgt 5y agoThat doesn’t mean you need to write JavaScript. You can write code in a reasonable language that compiles to JavaScript.
- fulafel 5y agoSometimes yes but for a lot of situations we have better options, like ClojureScript, TypeScript, etc.
- mountainriver 5y agoGo doesn’t attract mediocrity it attracts pragmatism. I worked on a Scala team for a couple years, had a lot of devs that were “smart”, problem was they wrote really fancy code no one could understand. I then switched to a Go team and it was night and day. I was wildly more productive and the people in the community were not lacking intelligence. Go prioritizes community, it believes that “us” is more impactful than “me”. This is its biggest strength, and is often lost on people looking in from the outside.
- isbvhodnvemrwvn 5y agoI feel like this is something that people who use a certain language repeat to themselves until they believe it. Go is big enough that this certainly doesn't hold for tens of thousands of developers.
- dharmab 5y agoIn my experience Go's relatively constrained language and standard library coupled with gofmt mean Go code written by entirely different people tends to read fairly consistently.
- jpgvm 5y agoStyle wise for sure. Structure? Choices of libraries etc? Definitely not. Not enough consensus for even the simple "I want make MVC style webapp".
- GrandTheftR 5y agoWhen worked on Go projects, I found that I was far more likely to read library code to see how to use it than other languages I used. Cannot be too "fancy" is definitely a strength of Go as a programming language.
- User23 5y agoI don’t dislike Go and have worked with it professionally on and off over the years. It occupies a weird liminal space between low level languages like C and medium level languages like Java. It was built to solve a set of in house problems that Google faced and it does so well. On the other hand if you end up needing to do lower level work the lack of power renders Go unsuitable. And if you need to do higher level work the lack of expressiveness is almost as frustrating.
- ausudhz 5y agoAny turing complete language can do what you need, the rest is just preference. Spring boot is garbage to be
- nphard85 5y agoAnd yet there are hardly any software written in Haskell or Ocaml that are widely used or have any notable positive impact on the modern digital world, compared to those written in languages like Go, C++ or Python. edit: ps: Big fan of OCaml, but have since moved on to Go and Python for getting things done in the real world.
- jpgvm 5y agoOCaml is mostly used in speciality applications. I have a few friends that work on flight control software for satellites and their stuff is all OCaml which is apparently not that uncommon in their field. That said none of them knew OCaml before joining said company and thus none were hired because of it... so that does somewhat invalidate the "right" people argument but I guess if you are doing literal rocket science I think that is pretty self-selecting for smart folk lol.
- ParetoOptimal 5y ago> And yet there are hardly any software written in Haskell or Ocaml that are widely used or have any notable positive impact on the modern digital world, It's used in supply chain management at target. IIRC at Starbucks too. Oh, and ever use Facebook chat? Haskell is running over your messages to filter out spam.
- foldr 5y ago>Go attracts mediocrity and not in a good way, it also actively repels the "right " people if you want to hire for highest intellectual horsepower for a given budget. This is painting with a pretty broad brush. I like Haskell (and first learned it before it was cool, in the early 2000s), but I also enjoy coding in Go. Not everyone is strongly driven by choice of programming language in their job search. If you do hire someone who desperately wants to write Haskell code, you might find that they spend more time tinkering with advanced Haskell features than they do adding business value.
- ForOldHack 5y agoWhat exactly did Dijkstra say about Cobol Programmers? In 1975, Edsgar Dijkstra famously proclaimed that “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence[sic].” This undoubtedly led to the decline of teaching COBOL in universities, but it remained the dominant business language.
- mbrodersen 5y ago> JS is almost never the right tool for the job JS is one of the most successful programming languages in history. Millions of JS programmers solve real world problems every single day. It might not be the right tool for you of course but that has nothing to do with JS itself.
- jamil7 5y agoThe metrics are skewed though because it was all that was available in the browser for a long time.
- AtlasBarfed 5y agoHonest question: If Spring basically "fixed" java development... Why hasn't it been ported to Go? Wouldn't it fix the same problems there?
- jpgvm 5y agoSpring relies heavily on the more powerful features of the Java runtime which aren't available in Go, it wouldn't be possible to port it as-is. You could definitely come up with a set of existing Go libraries that implement all the core functionality of a Spring up in a cohesive way. Almost every large company I have been at has done exactly that however none has caught on in the same way Spring has. Spring hasn't "fixed" Java development however but rather provided a consistent framework that has stood the test of time. It still has flaws but it's been around for long enough that nearly every conceivable issue you could run into already has a well known solution. The end result is you spend very little time fixing Java or Spring problems. In Go land however there isn't much in the way of consistent and/or well integrated ecosystems. You end up stitching everything together yourself and as a result can run into all sorts of combinatorial set of dependencies that can present effectively un-Google-able problems. Thus you spend a lot more time working out how to integrate your HTTP server, router, middlewares, tracing, logging, etc all of which are pre-solved problems with are large framework like Spring. It wouldn't be possible to "fix" the same problems in Go unless either a new framework was developed from scratch that really took off or one of the collections of libraries was able to achieve dominance.
- AtlasBarfed 5y agoWhat runtime does Spring utilize that Go doesn't have from ... say .. the XML conf files era of Spring? I understand annotations and classpath scanning are entirely different animals. I guess AOP magic doesn't exist either. Json/Yaml versions of the xml era should be possible. I guess no xml namespace magic (which I hated)...but a consistent object graph specification would seem useful.
- jpgvm 5y agoYeah I think if you can come up with a good IoC implementation the rest would fall into place.