7 ms·
I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural
by atx42 4y ago
I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural programming great again? I get it, you can compile it and it has concurrency, but there's better alternatives in my mind, unfortunately not as popular.
- pkulak 4y agoI can't think of anything off the top of my head that doesn't require a runtime, but does exclusively use green threads.
- BipolarCapybara 4y agoWhat do you feel is a good alternative to Go?
- bloblaw 4y agoDepends on your requirements. If you want statically compiled (AOT compiled), then I think Nim, Zig, or even Rust are good alternatives. If you like the high-performance backend, then Java, Kotlin, Scala, or C# are great choices.
- sk1pper 4y agoDo you mean for production? Zig isn't production-ready. Nim is extremely niche. I'm kind of puzzled why I see these thrown around so much on HN. Sure, they're fine for a side-project, but they're pretty out there for anything mission critical.
- Xeoncross 4y agoFor a lot of people like me, Go was something of a better scripting language. It wasn't as hard to grok as C or Rust, it wasn't as slow as Ruby, Python or PHP. most of all, it it was designed to make use of multiple cores. Surprisingly, having testing and formatting built into the tooling is also a huge win after spending years debating and changing choices in scripting land. Go is the new PHP/Node.js and Rust is the replacement for everything else. I know this is technically wrong, but that's how it feels.
- crowdyriver 4y agoMy feelings exactly. I love go because of how productive and resilient can be. In months programming in it I've barely had any null pointer exceptions. If it compiles, and passes the linters, it mostly works aswell.
- Xeoncross 4y agoYeah, null pointers and the compiler writing more code for you (overlaps with generics) are pretty high on my wish list. I'm bringing someone up in Go and they forget to initialize some map or struct: `&Foo{data:map[int]int{}}` and crash the app.
- deleted 4y ago[deleted]
- tech_tuna 4y agoAgreed 100%. I've used a bunch of languages over the years: C, C++, C#, VB, Perl, Java/Groovy/Kotlin, Javascript, Lua, Ruby, PHP, Python and Go. All fairly mainstream and I'm not going to start railing on the ones I don't like. . . so let's just say Python was the first language that I loved and Go is my current favorite. For me, readability, simplicity and having compile time checks are wonderful. Go feels like a better Python. I still enjoy using Python but "runtime is funtime" even with type hinting and linting and everything else. I am also a sucker for good tooling and a pleasant dev experience. Go has fantastic tooling. That being said, it has its warts and weak points. If I need to write something quick and dirty, I prefer Python. If I need to parse JSON and I don't have an easy way to generate client code, I prefer Python. There are some quirky bits in Go I don't particularly like e.g. the reversal of parameter type and name in function signatures. . . that just confuses me because I typically am using 2-4 different languages in any given week and Go is the weirdo in this regard. :) I would be thrilled to see Rust become the dominant systems programming language some day. I'm planning to learn it as soon as it looks like the right choice for me - for most of my work, Python + Go + bash (I love and hate bash) are more than sufficient.
- Sohcahtoa82 4y ago
- simonw 4y agoWhat's better than procedural programming?
- tnzk 4y agoI assume he implied functinal programming.
- geodel 4y agoWell those alternatives can be popular if more people find them better. Isn't it?
- umvi 4y agoProcedural programming has always been great and continues to be great for most use cases. There's a time and a place for OOP, and there is a case to be made for functional programming, but it's hard to beat the simplicity of procedural programming. Go is an excellent procedural language that has lots of static guarantees and a super fast compile times (fast at least compared to C++).
- kaba0 4y agoI really would not call it “lots of static guarantees”.. it has some static guarantees at most. It is pretty low in type safety, compared to even C++ and the like, let alone Rust, Haskell, etc.
- coin 4y agoCould not agree more. Using Go is like stepping in a time machine and going back to 2005.
- uhtred 4y agoGo should have died?! didn't Go come out like yesterday? This is why I am hesitant to invest time in new hot thing languages. I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript).
- KronisLV 4y ago> Go should have died?! didn't Go come out like yesterday? This is why I am hesitant to invest time in new hot thing languages. Actually it came out about 10 years ago, in one way or another: https://go.dev/doc/devel/release https://go.dev/doc/devel/release So it largely depends on what timescales you're comfortable with - some people switch stacks or learn new tech every 3-5 years, for others this cycle is slower or faster, also depending on the stuff you're working with. I'd say that web dev moves quickly, embedded moves more slowly, the rest is somewhere in the middle for the most part, maybe AI/ML and certain DevOps aspects rival web dev speeds of innovation/churn. > I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript). Perhaps, i think languages like Rust will be pretty widespread, both in the Linux kernel, as well as many tools and whatnot, albeit in a different and perhaps more conservative fashion than currently (the "rewrite everything in Rust" craze). In contrast, most of the modern web based SaaS solutions will be dead, most certainly the majority of Kubernetes tooling out there. Go might just be boring and useful enough to stick around and join the dreadful bunch of languages used in maintaining legacy code. It's funny, though, because while the languages themselves are more usable than they were 10 years ago, people's sentiments (including mine) are largely influenced by how many bad codebases they have to maintain: https://earthly.dev/blog/brown-green-language/ https://earthly.dev/blog/brown-green-language/ On an unrelated note, it would be pretty cool to have extremely slowly moving and stable languages, projects and tooling out there. To see maybe 3 or 4 releases in my entire lifetime and to have the next generation take over the burden. Then again, seeing how COBOL and FORTRAN are now, perhaps that sense of grandeur isn't worth the effort and old projects should just die.
- uhtred 4y ago> On an unrelated note, it would be pretty cool to have extremely slowly moving and stable languages, projects and tooling out there. To see maybe 3 or 4 releases in my entire lifetime and to have the next generation take over the burden. Then again, seeing how COBOL and FORTRAN are now, perhaps that sense of grandeur isn't worth the effort and old projects should just die. Isn't that Perl?
- hnov 4y agoGo is incredibly productive. Its primitive type system keeps me from bikeshedding, the standard library mostly makes sense, builds are fast, and yes, the builtin asynchronous IO means that I can write a C10K server without even trying. No JVM, no choosing between libuv and libevent, literally just take the simplicity of the fork-per-request model and adapt it to modernity.
- KronisLV 4y agoWhat's wrong with Angular? It being largely "batteries included" seemed pretty nice and I really liked the fact that TypeScript was a first class citizen - React and Vue both feel like it's been kind of tacked on, especially when a lot of additional libraries out there don't really have proper bindings. That said, personally I also think that React kind of went downhill for a bit due to the hooks (after seeing a few projects become really nightmarish to debug due to render loops without clear causes for them, after people sprinkled one too many hooks in there). Oh, and the Vue 2 to 3 migration is also a bit problematic because still many UI component libraries haven't been migrated over - currently actually using PrimeVue on a project because BootstrapVue still doesn't have proper support https://github.com/bootstrap-vue/bootstrap-vue/issues/5196 https://github.com/bootstrap-vue/bootstrap-vue/issues/5196
- gosukiwi 4y agoNo matter how hard I try, I just can't like React. I prefer Angular, Vue, even Ember. React feels like a downgrade to me.
- bloblaw 4y agoGo is successful because it has many appealing features: 1. trivial cross-compilation 2. native multi-threading (eg no GIL or multi-process hacks) that is easy to take advantage of 3. fast. An order of magnitude faster than Python in many cases. 4. easy to deploy. Most often just a single binary I like Go because once I compile it, I can ship that binary anywhere and it will run. I like Python for a great number of tasks and for prototyping, but I prefer Go when I need to run my code on another machine (or it needs to be fast). To put it simply, with Go I ship a binary. With Python I have to ship my entire development environment.
- wiz21c 4y agoHow fast is it compared to rust ? Do you know. I ask because I've started a side project in rust because all of its guarantees were appealing to me (I don't want to spend too much time on bugs, and my code uses some threads). I also need maximum performances. So I've chosen it. But now I have my compilation times that reach 45 seconds, so I'm slowly wondering if the go balance (towards fast compilation) would not be more advantageous; unless of course, performances are real bad...
- snapetom 4y agoAs someone who has started side projects with very technical and opinionated friends, just stick with Rust. Make a decision, stick with it, ship it. If there's a real problem, change it after you have it up and running. There's no point in optimizing for millions of users if you have 0 users now.
- wiz21c 4y agoyeah sure, I have zero user and well, it may be like that until my death :-) that project was an excuse for learning rust. But now I understant rust a bit more, well, I'm a bit scare to wait 45 sec on each build for a side project (ie a project I do on my very limited spare time) :-) but anyway, rust is really cool to work with (I have a python/C++/assembler/R background). The level of checking it does is really mindblowing (and frustrating at times :-))
- josephcsible 4y agoIndeed. My overall complaint about Go is that despite being a very new programming language, it hasn't incorporated a lot of lessons learned long ago (e.g., the billion dollar mistake). One of my favorite articles about Go is http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
- hnov 4y agoAs a PL Golang is very unremarkable and it does have a lot of special casing and a general lack of "orthogonality," in fact it reminds me of PHP in some ways. However, that's completely missing the point: Golang brought CSP into the mainstream when most were still using CPS to scale beyond OS threads. The kind of people who rewrite services to get performance improvements and then write blog posts about it aren't gonna learn your complicated language (just like they're not gonna spend their time messing with gevent and profiling to scale their python): they're makers not PL researchers. Google rightly noticed that there's a huge gap between existing mainstream offerings on the ease of use-performance spectrum and filled it with a DSL for programming network services. It doesn't need to be fancy, it needs to allow someone with CS201 knowledge to set-up the codebase so that people with CS101 knowledge can write sequential code that talks to the network without callbacks, yield/async/await or any of that incidental cruft.
- akira2501 4y agoI have yet to find a language where cross compiling is as easy and simple as it is with Go. It's a first class feature of the language and for my use case, it makes it an obvious choice. Programming is about managing tradeoffs to solve real problems, not building a perfect ideological environment to write code in.