Yes, location is becoming less important but there are differences in locally available talent and money. That’s the main reason incubators are forming in Europe too. If you are in the wrong place you will be starved for money and talent and others can outperform you. That what happened a lot, American companies outperformed European ones and when they needed to expand into Europe they could just buy the companies that are most similar in a few key markets here and expand from there. Being able to grow quickly enough to prevent that is sort of important if we want to own our tech giants.
But if the talent is globally available, thanks to the remote work, what difference does it (location) make? I know that it's still not 100% true, but I think we're moving in this direction
1) you need a systems programming language (but not for OS development) that is safe and not too hard to learn
2) you need to run “scripts” but don’t like the hassle of lugging around the dependencies so you go for binaries instead
3) you work on green field cloud projects that run in/on kubernetes
4) you have a team of people that try to use every feature of a language regardless of it it is sensible and need a language that limits them
5) you need to be able to program something that can run in parallel that you can wrap your mind around
That said, I don’t use golang. If you have a hypothetical use for a language you wont get into it, you need a practical use where it makes sense or you will most likely use your preexisting tools because its more comfortable.
Yea, somewhat disappointing. My mx 3s mouse has problems with the click switches and the mouse isn’t all that old. I’ve also read about others with the problem. I would also like to be able to buy a replacement case for when the rubber starts to come apart. Has not happened on this mouse yet but on all other rubberized mice I’ve had.
Replacement key caps for my keyboards would also be nice.
The bouncing on contact switches becomes excessive over time with corrosion and leads to double clicks. Luckily optical button switches are showing up on a lot of mice, and they don't have have to use debouncing, so the problem is non-existent for them.
Logitech has a couple with optical switches, but most of their line is still traditional. I've been using the wired G502 X, which is pretty decent, and there's also a wireless version.
Roccat is mostly optical, Razer is moving that direction, and Steelseries also has a few under the "Prime" name.
As somebody working in software startups in Europe, what I’ve seen is a pretty broken system. The companies have a wild west attitude towards sales that leads to irregular contracts unpredictable money flow.
I’ve worked on trying to predict our income based on our contracts and because of a couple of sales people a lot of the contracts where basically inscrutable, we brought two different experts in to “fix” my “failing” just for them to give up and do what I did and predict future income based on billing rather that contracts. That made us less interesting to the more risk shy European investors. It didn’t help that we abused a system that was designed to run an IT shop with because that is what the company started at years earlier.
The other thing is that until you make about 25 million revenue a year nobody is interested in you. To risky, not enough early investment and companies are money strapped. At that point a lot of the companies that come in don’t come in to invest but to buy up the company and those companies are usually American. If you do get investors and those investors are Europeans they are often Vulture investors that prop the company up, make it more presentable and just sell it on to the next investor. In one lucky case the IT startup was bought up by a European company that wasn’t in IT and saw the investment as a way to future proof itself.
The investment for startups and in particular IT startups in Europe is very broken and the companies that benefit from it are often American. It is getting better but I think the US can still snap up European companies for its own growth for the next 10 to 20 years.
I think those numbers are probably based on source code contributions. I can believe those statistics, what is missing is the why.
Some people just aren’t good programmers. I knew some of those, one turned out to be great at testing instead. Junior programmers, new programmers (to the project/company or language or field) are slow and they might get better. Then you have burnout. There was a story here about a guy that didn’t contribute much because he mentored and pair programmed and did other tasks to make the life of other programmers easy.
There are a lot of good reasons so before you go optimizing on numbers, check the why.
> those numbers are probably based on source code contributions
The other part of that is a "more senior developers tend to do things outside of things seen with git commit." Meetings, commenting on code reviews, and documentation are the first three "not tracked in git" that come to mind.
Other things like proof of concepts may not find their way to the actual project repos (and thus has little visibility in the report).
That said, there are certainly developers who are at the 0.1x median even when they spend their full time working on solving that problem. They just work really slowly.
I would guess that Ruby and Python programmers generally know at least some c, c++ and maybe even objective-c. That was the case where I worked. It is also normal enough to install gems with native extensions, if you can’t read gcc or clang compiler errors you won’t get very far.
The argumentation in the article isn’t very good but the Ruby community was never good at selling itself and used similar arguments to the article for years.
The syntax is more elegant. Well yes, but that’s also subjective. Also, the argument doesn’t help LISP to be more popular either.
The indentation argument is old and in my opinion hypocritical (yaml, sass, haml). Also, not getting code you copy and paste from the net to work because of syntax errors based on indentation is the least of the problems in copy and pasting code from the internet.
Selling the larger and more diverse library ecosystem of Python as an advantage for Ruby rather funny. Ruby has good libraries for the web and enough for *NIX scripting but I do wish we had some more stuff to keep up with Python when it comes to math, scientific computing and ML.
I have more fun writing Ruby and that is one of the main reasons I use it. And I think it is an easy enough programming language for a somewhat experienced programmer to pick up. DSLs, meta programming and some other advanced concepts are easy enough to pick up in Ruby and you can figure out the pros and cons for your self quickly. We still have a tradition of fun and quirky projects being done in Ruby. There is a gem to create your own card games and a video on YouTube about somebody building an agi upscaler, that code is in ruby.
My sales pitch would be: “Come join us, we are fun and a bit weird, just like our language. We are also fun at parties!”
I am a Ruby programmer that came to Ruby as a Python programmer that had do do work mainly in PHP and JavaScript (no jobs in Python where I lived at the time). I sort of liked JavaScript (I know it so well now that I’m ambivalent about JavaScript) and started to really despise PHP (most of the problems I hated back then are gone now but I can’t go back).
When I searched for a job that wasn’t PHP or Java based I found a Ruby on Rails job and Ruby really did something for me (and with me). I really liked it and was a bit confounded because I’ve looked into it before and it didn’t do anything for me back then.
Since then I’ve returned to Python for some projects and I find that Python made me better at Ruby and Ruby made me better at Python. JavaScript, Ruby and Python are my main goto languages for scripting and web programming and I think Ruby is getting the short end of the three languages. It deserves better and I think more people, especially web developers and people that need a *NIX scripting language should give it a try.
What I don’t really understand is that we (Ruby programmers) still use indentation for block definition as a reason against Python. Especially since yaml, haml and sass are technologies we helped build and popularize and they are all indentation based. I still agree that Python is the less elegant and more importantly the less fun language.
> What I don’t really understand is that we (Ruby programmers) still use indentation for block definition as a reason against Python. Especially since yaml, haml and sass are technologies we helped build and popularize and they are all indentation based.
The article was written by an LLM[1], not a Ruby programmer.
Now I get your point. That would be a good explanation why the arguments are surface level and regurgitated. This is not really something I want to have to look out for.
nobody serious uses indentation as a bad point against Python. Ruby pretty much could work with indentation instead of "end" almost without drawbacks. Maybe irb would be slightly less convenient, and that's it. Whitespace IS significant in ruby too, it's just goes so much along with the programmer's intuition that it rarely bites anyone.
Indentation was seriously being used as a point against Python when I came to Ruby and we had lots of DSLs that where indentation based back then. I always felt that do be BS and I think it is meant seriously here too, in this article.
I do agree that isn’t an argument I have heard used seriously in a long time tough.
The usual argument is that bracketed syntax rather than indentation-based syntax makes it possible/easier to have multi-line anonymous functions (such as with Ruby's block syntax), and especially to use them within more complex expressions.
You can have indentation based syntax and ; for multiple statements in one line, or something even more powerful. But it doesn't matter.
Main power of blocks is not being multiline or being closure-like, many languages have this. But blocks are not just anonymous functions or lambdas, they have ability to return from the outer method (or from the method to which it was passed with break), acting as a powerful tool for creating your own flow control structures if needed, or just replacing "for". Of the languages I know or heard of only smalltalk does the same.
You can live without those, you can live even without early return, but blocks are not a misfeature, it's a great and intuitive tool. And python's rudimentary lambdas make me cry a little.
I would pretty much remove any sex that doesn’t drive the story in some way and keep it short. You are correct that sex doesn’t hit like it used to hit. I would argue the same for violence and special effects. We’ve seen it all and we’ve seen a lot of it. What we haven’t seen a lot of in some time is good story telling that doesn’t rely on gimmicks.
