91–100 of 137 posts
If someone is new to programming this in no way does any justice. Programming is way too complex to be fit in 5 minutes intro. https://norvig.com/21-days.html
Earlier quoted context omitted.
I explicitly added the "ps" to avoid the situation where all the replies are fairly empty comment saying "Well we use it!" I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages. That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional ef…
I have used Go in production. I found it roughly takes 2-3x additional time it takes to develop the same functionality in Node.js (with typescript). But it runs faster. If you want to write code that is probably not going to be thrown away it may be wise to invest the additional time in Go. However can't recommend that for building experimental code/APIs etc which are time bound and may/can get replaced (or split int…
No offense to the author here ... but I need to vent some personal frustration. Every tutorial goes through these exact same motions for learning a new language. It sucks! Programmers can figure out what a variable is, or how to use an array or a map. Those things really don't change a whole lot between languages. What about how to import code from different modules? Best practices for organizing code? How your langu…
This is why languages need good documentation.
It seems like it’s a booming industry though. I mean, there are entire sites like udemy where amateurs teach amateurs things they’ll never use in a real job, and that place, and others like it, seems to be doing just fine. Hell, every PACKT book ever written was worth more as blank paper.
Why do I care? I’m an external examiner, sometimes I need to read some of these god awful books to see what students are expected to know. I’m not sure why professors ever stray from the true CS classics, but they unfortunately do. Especially at the academy level.
Earlier quoted context omitted.
I like C but strongly dislike Go. They share nothing other than having a small(ish) feature set.
I agree. Go feels like it's aimed at creating applications that run at a level above where C traditionally runs while keeping the pared down feature set of C, and it just doesn't work well imo. I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names. It's like the simplicity gets in the way of itself.…
You can write any language any which way, but some languages just have a culture of boilerplate vs abstractions. The most popular Python and Java libraries seem to love endless layers of indirection, and when it doesn't fit exactly what you need, you bang your head against the wall monkeypatching it to make it work since your whole app is already written in X mega library.
Go culture seems to be quite a bit more boilerplate-y and uses smaller more composable libraries. It's just refreshing.
Really I just need to buckle down on Rust, but I think it's a fair bet that teams and shops that bring in a lot of young programmers and want to ramp them up fast may cringe a bit at the learning curve of Rust.
That's why for now in terms of a bet on employability, I am prioritizing experience with Go.
Earlier quoted context omitted.
Do Go comments work like syntax? Do you mean that they need to be formatted a certain way like they’re language syntax?
The Go authors have (ab)used comments to extend the language in experimental ways for code generation, build pragmas and recently file embedding. They’ve done this to avoid breaking the language stability guarantee, not sure if there were other reasons. I think it’s a mistake personally to create this sort of metalanguage in comments (now you have two problems!) but it’s easy to avoid using this most of the time as t…
Earlier quoted context omitted.
I like C but I would prefer Rust over Go. Go may be simple but I really hate using conventions like init(), comments working like syntax, captial letter means published etc.
Do Go comments work like syntax? Do you mean that they need to be formatted a certain way like they’re language syntax?
Hiding certain meta-information, like exporting a function with a C-compatible signature when building a shared library is not a great way of doing things, but on the other side, it is a special usage which isn't part of the language itself, so not part of its syntax.
Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.) Go puts essential C idioms directly into the language (pointer/length is formalized as slic…
I thought this sounded familiar https://news.ycombinator.com/item?id=25622389 https://news.ycombinator.com/item?id=25555457 https://news.ycombinator.com/item?id=25531118
Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.) Go puts essential C idioms directly into the language (pointer/length is formalized as slic…
I'd like to chime in and say that I also like C but really dislike Go. C is simple, to what today is nearly an absurd degree, but it at least integrates well with an enormous ecosystem of existing tooling and libraries. Go, by contrast, feels the need to re-invent every possible wheel, often with a seemingly intentional effort to be different just because . C ABIs are rock solid on every platform. Any language or too…
Go straddles an interesting space. Currently I work on a back-end data crunching software, distributed (running on hundreds or sometimes thousands of nodes), each node running 64 or 128 cores with 128 or 256GB RAM. The problem we solve is both IO, CPU, and memory bound. Anyway to look at it, it's a hard problem.
The old version of this program was written in C. Then it was rewritten in Go.
The people who decided to switch to Go was looking for the following features: - Be able to manually lay out memory for performance. So not Java. - Mmap binding to file system, for performance. - More abstractions than C, for adding software features. - Cross platform. The program sometimes runs on Android and IOs. - Easy to learn for beginners. It's not possible to only hire PhDs or C++ gurus. - Easy to dig down into assembly, for performance. - GC doesn't get in the way, for performance as well as adding features.
Maybe these days, C# might work? May Rust? But 6-8 years ago, Go fit the bill and it worked out very well. And the language doesn't feel "limited" in any way. Yeah, I miss generics sometimes. Maybe error handling could be better? Sometimes I need to work around the GC. But day-to-day, I think I focus more on solving actual problems (performance bottlenecks, adding features), instead of pondering if I need to create another AbstractFactory, or tuning GC knobs, or figuring out which pointer type to use.
To me, Go feels very balanced. I can write python or Java like code and get decent performance. If I need more performance, I can dig down pretty deep make CPU work faster. The abstractions are light enough that a new person can figure out what's going on and add features, fix bugs, or improve performance.
I like Go.