221–230 of 402 posts
Question: who is going to remember all these conversion rules? By the second bullet you lost me. Simply run the command below: go tool fix -diff -force=context state-of-go/tools/gofix.go How is typing 59 characters simple?
How lazy are you?
Earlier quoted context omitted.
Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.
> To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language. Having a GC doesn't forbid that, in very specific cases. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.
Golang really seems to have come a long way. But what holds me back from using it are the dangers of deadlocks and segfaults (due to forgotten error handling) that might be introduced even inadvertedly if applied to industrial-scale projects (say, 1M+ LOC, 10+ developers). That is, I see many small (server/microservice) projects flourish with Golang, and it seems an excellent replacement for certain types of C projec…
Earlier quoted context omitted.
For me Go is the goto language for usecases where Python and Java were used. Python is great for tooling, and Java was the primary language for the backend. So now, whenever i think about tooling or backend, Go is the primary answer, because its good in both paradigms. The other languages i use is C++, and Swift, each one with their own niches. C++ for complex machinery, that requires more control and integration wit…
One nice thing about the "rewrite C++ in Rust" is that oh can do it incrementally; we're taking the same approach for Firefox, for example. Out of curiosity, what are the libraries in C++ that you miss in Rust, or would have to re-write?
The problem is, there's a lot of code in C++ already for all of this. V8, Dart, Java Vm's in C++, Webkit, Chrome, Firefox in C++, great game engines in C++.
Is not that i wouldnt use Rust.. on the contrary. But the problem is, for the usecase i think Rust would be very good, there are a lot of code in C++ already, that would require a effort of years to port in Rust.
For instance i work in Chrome C++ source a lot.. and the codebase is a beast.
Maybe if, in the future, things that are starting now in Rust, will be the the successful cases for this kind of machinery.
But given that, at least i, wouldnt use Rust to make a webserver backend (the same way i wouldnt use C++ for that), because i think its overkill. While i like Rust, i cant see a opportunity to use it, and the great impediment for that, is the C++ codebase legacy, and both languages basically competing for the same paradigm.
But theres a great thing in favor of Rust, because its the only modern real contender to C++. But i think it will be a slow and harsh competition (albeit a necessary one).
Earlier quoted context omitted.
I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.
Perhaps you could help clear up the misconception by fixing Wikipedia's 'System Programming' and 'System Programming Language' entries. It might also be worth commenting on these[0] Stack Exchange answers, too. [0] http://softwareengineering.stackexchange.com/q/151610/54726
"System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers."
Earlier quoted context omitted.
> When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. This is probably more due to the fact that you moved from a dynamically typed language to a statically typed one rather than this new language itself.
But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now. Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back s…
Earlier quoted context omitted.
Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.
> To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language. Having a GC doesn't forbid that, in very specific cases. Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.
Question: who is going to remember all these conversion rules? By the second bullet you lost me. Simply run the command below: go tool fix -diff -force=context state-of-go/tools/gofix.go How is typing 59 characters simple?
`staticcheck` will statically analyze your code and suggest all places where the new conversion rule can be applied. All the other rules are same as the last 7 years, you know them through experience after using Go for a week. Way simpler than most other languages. That go fix command can be typed once and update millions of lines of code. Pretty simple.
You also meant to say the go fix command does a lot (which is great), not that calling it is simple (which is not great).
Earlier quoted context omitted.
Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.
Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageo…
I totally agree that Go is fantastic for services and networked things.