vacuous article.
Scala vs Go
91–100 of 109 posts
Re: Scala vs Go
#92I'm learning Scala at my new job (previously worked in Ruby, Python, and long ago, Java and enjoy learning about functional programming). It's a fine language with a lot of great things about it...that get tossed the second you touch Java. It's wonderful to not have null. Except that you do anyway! My biggest complaint is that it is so multi-paradigm that different systems in our codebase have completely different st…
You might also want to check out Kotlin. It's basically what everyone wished Java 8 had been, but wasn't because a) backwards compatibility, and b) difference of opinion (looking at you Optional). We have a set of coding conventions we use for our Java code that includes things like using Optional.empty() instead of null and declaring all method parameters (and as many locals and properties as we can get away with) as final. We've found that using Kotlin allows us to write equivalent code in a far more succinct fashion because all those conventions we follow are the default state in Kotlin, and it's deviating from those conventions that requires extra syntax in Kotlin.
Re: Scala vs Go
#93Very similar to the c++ vs c debate. C++ has tons of arguably useful features. But these features also in a way distract from the task at hand - solving a problem. You risk ending up discussing the meta problem too much - how to write and organize code. C on the other hand is very basic, requires a lot of boilerplate and encourages re-implementation. But you are (subjectively) more likely to produce pragmatic code wh…
the hell's wrong with Jersey?
Re: Scala vs Go
#94Earlier quoted context omitted.
Complete tangent, but I must say that since I recently started using pycharm it has really caught most of the obvious typo and uninitialized bugs and my python code is really crashing surprisingly rarely as I prototype to death. Just saying in case there are others who haven't been trying modern python tooling and don't know that you can get real close to a compiled language type safety certainty these days before yo…
Speaking of tangents... I use pycharm too. Do you ever use type annotations in Python? I'm really digging it in Typescript for Javascript.
(I have my own, and I'm probably the only user ;) https://pypi.python.org/pypi/obiwan/ )
Re: Scala vs Go
#95Transportability is an oft under-valued quality when comparing languages. Yes you could write something highly performant/compact/domain-specialized in perl,scala,lisp etc but when the time comes that your product is successful and your team needs to scale or you want to transfer ownership to another team how easy is that transition going to be?
Unless your app is so trivial that syntax and APIs are the dominating factor, I'd wager the team transition will have so much other stuff to deal with. Hopefully, not least of all, the actual program logic. And team transitions are rather rare compared to the day to day dev that goes on. Optimising for them seems misplaced.
As a consultant, transitioning your work to maintainers remains a constant concern
Re: Scala vs Go
#96Earlier quoted context omitted.
> For all my non-trival projects I always fork all my dependencies into their own repos That sounds absolutely terrible. Even worse than having to track down & install libraries and headers for C projects. At least in the case of those libraries, you can enforce a particular version using autoconf or whatever. Vendoring source code for dependencies (especially in separate repos) is fragile and a pain for anyone else…
How so? The project just includes a script that git clones the forks into your Go workspace for the project /foobar/src....
And then you have to maintain a bunch of ad hoc shell scripts separate from your actual build process. Like I said: fragile and a pain.
Re: Scala vs Go
#97Earlier quoted context omitted.
How so? The project just includes a script that git clones the forks into your Go workspace for the project /foobar/src....
And then you have to maintain a bunch of ad hoc shell scripts separate from your actual build process. Like I said: fragile and a pain.
Besides a shell script with a "for each repo. git clone", there is no build process (besides running the go build command)...
Re: Scala vs Go
#98Earlier quoted context omitted.
But do you know who designed the server tech? Was it old mainframe people?
For what it's worth, the initial EJB spec was written by IBM, so I guess the answer to your question could be yes. "The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems" https://en.wikipedia.org/wiki/Enterprise_JavaBeans
Thank you for the link. I looked up Java EE, which according to wikipedia mostly originated from WebLogic. The founders didn't seem that enterprisey though: http://otechmag.com/magazine/2015/summer/michel-schildmeijer...
So IBM does sound likely.
Re: Scala vs Go
#99Earlier quoted context omitted.
But do you know who designed the server tech? Was it old mainframe people?
For what it's worth, the initial EJB spec was written by IBM, so I guess the answer to your question could be yes. "The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems" https://en.wikipedia.org/wiki/Enterprise_JavaBeans
[deleted]
Re: Scala vs Go
#100Very similar to the c++ vs c debate. C++ has tons of arguably useful features. But these features also in a way distract from the task at hand - solving a problem. You risk ending up discussing the meta problem too much - how to write and organize code. C on the other hand is very basic, requires a lot of boilerplate and encourages re-implementation. But you are (subjectively) more likely to produce pragmatic code wh…
the hell's wrong with Jersey?
Nothing! I like Jersey style.