311–320 of 384 posts
Any comment on Swift vs Go, potentially for server programming?
Earlier quoted context omitted.
Yeah I suppose at this point the graph falls apart since even the prospect of writing new perl code does not sound fun to me but I am sure could be fun to someone.
Yeah, I wouldn't want to be writing new Perl either. It was actually Ruby's "optimized for developer happiness" mantra that triggered my comment. Sometimes I mumble under my breath that Ruby is Perl for the 21st century - gleefully creative hackers leaving behind overly clever code for far less happy developers to deal with. A culture of optimising the elegance of the API over the simplicity and maintenance of the im…
Source: Maintained a 300 kLOC Perl application for 3 years, now working with legacy and new Rails applications.
Earlier quoted context omitted.
It's not simple when you have to maintain it or debug it. There are many classes of errors that can occur when writing software. Languages with implicit variable creation like python obscure errors like mistyping the name of a new variable (versus an explicit declaration like in C or an ML where the mistyped name will result in an error immediately modulo name conflicts). It looks correct at a glance, but: def foo(a_…
Per your typo point, this has already been solved by linting. If I made a typo like that, any decent editor (Sublime in my case) would draw a big red box and complain at me for using an undeclared variable. In the case of a typo on assignment as in your example, the linter would report a variable declaration without usages. Per your testing point, so what? Doesn't everyone strive for 100% code coverage anyway? One of…
And not everyone is striving for 100% code coverage unless it really matters (e.g. SQLite). A beneficial activity becomes harmful if taken to extremes.
Earlier quoted context omitted.
> When you want to hire developers. When you want to hire good developers pick Erlang, Elixir, Rust, Haskell, ML, LISP. Because chances they went out of their way to learn the language as it is not taught in US universities in depth. They are probably curious, good learners and could probably learn or adapt to other new things thrown at them. I am at shop were we use Erlang and syntax has not phased new people that m…
I've also found though that these languages attract primadonnas who care more about "attractive" code and getting to play with cutting edge technology that might not be ready for prime time yet than they care about providing business value. Edit: fixing typo. Pay -> play
The only languages that don't attract prima donnas are the "not hip" ones like Java, C++, C#, Perl, etc.
Earlier quoted context omitted.
When I used to frequent gonuts, I raised the issue why they didn't went the FFI way as D, Rust, .NET, Delphi, FreePascal do, but sadly they rather use cgo as solution.
I'm pretty sure the problem is Go's use of segmented stacks and runtime, which makes it hard to properly interface with C efficiently.
Earlier quoted context omitted.
All languages require investment. Zero sum game, with some opting for syntactic simplicity that entails a long term investment of "idioms", subtle semantics, post-processing, etc., and others present a high initial investment and subsequent clarity, regularity, and possibly robustness. C/Go/Java/C# are in the former category. Scala, Haskell, Rust, for the latter. (C++ uniquely bites you at both ends :)
It is not a Zero sum game. The moment you actually need to maintain a large codebase for years, strongly typed languages are much more cost-efficient. Finding out, with absolute certainty, which code calls which code under which circumstances is a life-saver. Any modern IDE for JVM languages accomplishes that. It's not enough for your code to be readable. It needs to be statically traceable.
I completely agree with your overall point, but typically reflection will inhibit truly 'absolute' certainty.
Earlier quoted context omitted.
I didn't mean to gloss over the go routine problems. You're absolutely correct, when there exist tools like the race detector it makes it evident that you can write incorrect concurrent programs. Becoming proficient at using the concurrency patterns in Go takes time but it is an advanced topic. Thanks for writing up these common mistakes.
Those aren't common mistakes, just things he dislikes about the language. For example, I don't care whether := sometimes does not introduce a new variable (have never had a bug related to that). I don't find the closure semantics any worse than Java's (sure Java requires captured variables to be final, but it doesn't require them to be immutable). I find append's semantics to be pretty intuitive. But then again, I'm…
And dismissing them just like that won't make them go away :)
Earlier quoted context omitted.
The good programmers I know are not attached to their tools. They prefer to use the right tool for the job. Many other programmers want to solve the problems using tools they know. There is nothing wrong with that. A company with good programmers who could do similar things more efficiently will add to competitive advantage.
Again, we all agree about the motto. If you need to screw something and you have a choice between 1. A screwdriver 2. Electric drill A 3. Electric drill B you will certainly look funny at someone considering the screwdriver over the alternatives. Someone who automatically narrows this choice between the two electric drills is not "attached to their tools", as you say. They are just picking the better tool.
Can anyone convince me to use Rust over Go, or the other way around? My target machines range from i7s with massive amounts of RAM to Raspberry Pi with slightly-less-massive amounts of RAM.
Don't use rust if you're asking that question.
Rust is not a good solution for high level problems; it's a good solution for low level problems where go would be a terrible choice; and it's a good solution for high level problems where other choices are even worse (eg. C++).
They're both good languages, and you'll learn way more from picking up rust than you will from picking up go, so if you're just screwing around and want to learn a language this year, absolutely, pick rust or clojure. Go isn't on the list for 'interesting programming languages'.
...but if you have an actual problem you're trying to solve, I would be hard pressed to enumerate the reasons why you would pick rust if the problem was solvable using go. Maybe because your C dependencies would be easier to call from rust than go? That's all I can think of.
> When writing code, it should be clear how to make the program do what you want. Sometimes this means writing out a loop instead of invoking an obscure function. For example instead of the obscure function a.reverse() you can use the clear for loop for i := len(a)/2-1; i >= 0; i-- { opp := len(a)-1-i a[i], a[opp] = a[opp], a[i] } :(