21–30 of 311 posts
"Where line 9 there just blindly assumes the regex found a match, and causes quite the run-time error message." You blindly assume the regex found a match, because you ignored the part of the docs where they tell you how to check for a match: http://golang.org/pkg/regexp/#Regexp.FindStringSubmatch
If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.
Also, at this point the language syntax itself is basically locked. And from everything I've seen, they are focusing more on the runtime and tooling before they make any serious changes to the code language.
Go isn't bad for writing routine server-side web stuff that has to scale and run fast, which is why Google created it. Go is a modern language with a dated feel. No user-defined objects, just structs. No generics or templates. It was designed by old C programmers, and it looks it. Go has generic objects - maps and channels - and syntax for creating object instances - "Make". Only the built-in generics are available, though; you can't write new ones.
Go's "reflection" package thus tends to be overused to work around the lack of generic. This means doing work for each data item at run time for things that could have been done once at compile time. "interface{}" (Go's answer to type Any from Visual Basic) tends to be over-used.
Go (especially "Effective Go") has a lot of hand-waving about parallelism. Go's mantra is "share by communicating, not by sharing", but all the examples have data shared between threads. The channels are just used as a locking mechanism. Race conditions are possible in Go, and there's an exploit which uses this. (That's why Google AppEngine limits Go programs to single threads.) Go doesn't use immutability much, which is a lack in a shared-data parallel language with garbage collection. If you can make data immutable, you can safely share it, which is a way to avoid copying without introducing race conditions.
Rust, like Erlang, takes a much harder line on enforcing separation and locking. I haven't used Rust myself yet, so I can't say more on what it's like to use it. My hope is that Rust will provide a solution to buffer overflows in production code. After 35 years of C and its discontents, it's time to move on. I really hope the Rust crowd doesn't fuck up.
The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff th…
If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.
There are a lot of comments in that thread, is there anything specific you think stands out? Some of Ian's initial comments were saying that they are being very very careful about what gets added to the language. Also, at this point the language syntax itself is basically locked. And from everything I've seen, they are focusing more on the runtime and tooling before they make any serious changes to the code language.
If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.
For example: I've recently attempted writing a small service in Go and it only took a few hours for me to figure out how weak a language could be without some sort of type-abstraction or generics: I had to implement a FindValueInArray() twice for two different types. This should be a big issue in any respectable language. (I mostly like Go otherwise though!)
How mature is Rust and its compiler actually at this moment? Is it in a state ready to replace C++? Edit: Also, I missed a good overview of features in one language and lacking in the other. In that respect, I find the wikipedia page [1] deeply broken, but that aside. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_langu...
What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works got changed earlier this week.
If you're interested in writing libraries for a new ecosystem, now is the time to get into the language. I've tried to get into Rust a couple times since the 0.4 timeframe and I couldn't keep up with the pace of change. My current attempt started at 0.11 and while there are steady chanes, I've found them to be manageable.
If you want to have idioms and ecosystem relatively settled, hold off until the 1.2 or 1.3 timeframe (6 week cycles). I say this because a lot of the current RFCs are split between things that need to happen before 1.0 and things that need to happen after. This generally means the base functionality in-place for 1.0 with the sugar/convenience stuff to come later. I expect it'll take a few cycles after 1.0 before Rust settles into what most people are thinking when they think stable.
How mature is Rust and its compiler actually at this moment? Is it in a state ready to replace C++? Edit: Also, I missed a good overview of features in one language and lacking in the other. In that respect, I find the wikipedia page [1] deeply broken, but that aside. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_langu...
Nope. That will take many years. But it definitely is in a state where you can start building real things with it, if you don't mind some of the usual costs of being on the bleeding edge, like documentation that's hard to grok, frequent trips to irc, and frequent breaking changes. But breaking changes will be going away very soon, the documentation gets better all the time, and the irc room is far friendlier than others.
I was worried when I saw "I decided to write a little Rust and, because everyone in my world is seems swoony over it, Go." That's a pretty bad reason for using a language and usually leads to some pretty ridiculous criticism. This post was not that, I think they nailed a lot of the good and bad things about Go, in fact, they could have been a lot more harsh. There is a depth lacking in just checking out a language in…
Hmm. Learning a language/framework that is exploding in popularity is probably one of the best things a dev can do to stay relevant (read: employed). Hell, very few of us would be using Javascript if it weren't for it's ubiquity/community/popularity. I sure as hell am not using it because it's a well designed language.
On Javascript you're missing the causality. Some people are learning Javascript because it is popular of course, because they've read on some forum that learning popular things gets them hired, but those people are totally uninteresting in the pool of developers that learned Javascript because they had shit to do and things to build and Javascript was the answer.
There's a big difference between learning X because you want to make your job easier, because you want to build things in a new way, because you want exposure to new ways of thinking, because there isn't an alternative to what you're trying to do, etc... and learning X because that's fashionable. In the former case, it's pretty much a gamble but you might actually get something out of it. In the later case all you're earning is the ability to slap another keyword on a resume that only mediocre HR people care about, being actually a time waist as it's keeping you from learning things that might actually be of interest for the things you're trying to accomplish (other than getting a shitty job of course).
Just as people that learned PHP or Java back in the day found out, learning for the sake of getting a job is a sure way to land you a shitty and boring job in which you are replaceable cog. Managers love popular languages and frameworks, of course they do. And the interesting jobs that are out there, that make people happy and that pay well - well, let me tell you, those companies aren't looking for keywords on your resume, but for things that you've actually built.
And after some years from now, when you'll be over 40, you'll find yourself either a manager that does LinkedIn searches for keywords, or an obsolete developer that can't find a job because everything you've learned is obsolete and you waisted your time in learning syntax, instead of learning new abstractions, algorithms and mathematics - you know, stuff that never gets old.